| 1 | --- |
| 2 | title: "ProcureNet USDC Payment Settlement on EVM Networks" |
| 3 | sidebarTitle: "Payment Settlement" |
| 4 | description: "Learn how ProcureNet settles payments in USDC across Base, Arbitrum, Polygon, and Ethereum, including field evaluator payout tiers." |
| 5 | --- |
| 6 | |
| 7 | ProcureNet settles payments in USDC stablecoins on EVM-compatible networks. Whether you are integrating a buyer-facing checkout, running a procurement workflow, or disbursing payments to field evaluators, every payment follows the same on-chain settlement path: a payment request is created, a deposit address is shared with the payer, and the system watches for confirmation before releasing funds. This approach ensures deterministic, auditable settlement without reliance on traditional payment rails. |
| 8 | |
| 9 | ## Supported Networks |
| 10 | |
| 11 | You can settle payments on any of the following EVM networks. Specify the network when creating a payment request. |
| 12 | |
| 13 | <CardGroup cols={2}> |
| 14 | <Card title="Base" icon="circle-b"> |
| 15 | Low fees and fast finality. Recommended for high-volume procurement flows. |
| 16 | </Card> |
| 17 | <Card title="Arbitrum" icon="circle-a"> |
| 18 | Layer-2 rollup on Ethereum with low transaction costs and broad wallet support. |
| 19 | </Card> |
| 20 | <Card title="Polygon" icon="hexagon-check"> |
| 21 | Widely supported, low-cost EVM network with mature tooling. |
| 22 | </Card> |
| 23 | <Card title="Ethereum" icon="ethereum"> |
| 24 | The canonical EVM mainnet. Use when counterparties require settlement on L1. |
| 25 | </Card> |
| 26 | </CardGroup> |
| 27 | |
| 28 | ## Payment Flow |
| 29 | |
| 30 | Follow these steps to create and confirm a USDC payment. |
| 31 | |
| 32 | <Steps> |
| 33 | <Step title="Create a payment request"> |
| 34 | Call `POST /mods/procurement_wallet/usdc/request` with the amount, network, and any evaluation metadata. Authenticate using your `x-perplexity-mod-key` header. |
| 35 | |
| 36 | ```bash |
| 37 | curl -X POST https://api.procurenet.io/mods/procurement_wallet/usdc/request \ |
| 38 | -H "x-perplexity-mod-key: <api_key>" \ |
| 39 | -H "Content-Type: application/json" \ |
| 40 | -d '{ |
| 41 | "amount": 250, |
| 42 | "network": "base", |
| 43 | "currency": "USDC", |
| 44 | "recipient": "0xYourWalletAddress" |
| 45 | }' |
| 46 | ``` |
| 47 | |
| 48 | The response includes a `payment_id`, `deposit_address`, `qr_code`, and `expires_at` timestamp. |
| 49 | </Step> |
| 50 | |
| 51 | <Step title="Share the deposit address with the payer"> |
| 52 | Display the `deposit_address` or render the `qr_code` in your UI. The payer sends USDC to this address on the specified network. No additional API call is needed at this stage — ProcureNet monitors the address automatically. |
| 53 | </Step> |
| 54 | |
| 55 | <Step title="Watch for confirmation"> |
| 56 | Poll `GET /mods/procurement_wallet/usdc/watch/{paymentId}` to check settlement status. The endpoint returns the current confirmation state and, once confirmed, a `transaction_hash`. |
| 57 | |
| 58 | ```bash |
| 59 | curl https://api.procurenet.io/mods/procurement_wallet/usdc/watch/pay_xyz \ |
| 60 | -H "x-perplexity-mod-key: <api_key>" |
| 61 | ``` |
| 62 | |
| 63 | Continue polling until the response status is `confirmed`. Implement exponential backoff — most networks confirm within seconds on Base and Arbitrum, and within minutes on Ethereum mainnet. |
| 64 | </Step> |
| 65 | |
| 66 | <Step title="Receive the transaction hash"> |
| 67 | On confirmation, the watch endpoint returns a `transaction_hash`. Store this value as your permanent, on-chain proof of settlement. It can be verified independently on any EVM block explorer for the target network. |
| 68 | </Step> |
| 69 | </Steps> |
| 70 | |
| 71 | <Info> |
| 72 | Each payment request carries an `expires_at` timestamp. If the payer has not sent funds before that time, the request expires and cannot be confirmed. Create a new payment request and share the updated `deposit_address` with the payer. |
| 73 | </Info> |
| 74 | |
| 75 | ## VCI Field Evaluator Payment Tiers |
| 76 | |
| 77 | For field evaluation workflows, ProcureNet calculates the USDC payout automatically based on the evaluator's average quality score. You do not need to specify an amount manually — pass the evaluation results when creating the payment request and the bridge applies the correct tier. |
| 78 | |
| 79 | <Note> |
| 80 | Payments for field evaluations are calculated automatically from the submitted evaluation results. You do not need to specify an amount manually — pass the evaluation data when creating the payment request and ProcureNet applies the correct payout tier. |
| 81 | </Note> |
| 82 | |
| 83 | | Average Evaluation Score | USDC Payout | |
| 84 | |---|---| |
| 85 | | ≥ 9.0 | 500 USDC | |
| 86 | | ≥ 7.0 | 250 USDC | |
| 87 | | ≥ 5.0 | 100 USDC | |
| 88 | | < 5.0 | 0 USDC | |
| 89 | |
| 90 | <Accordion title="How the tier is calculated"> |
| 91 | ProcureNet averages all evaluation scores submitted for an assignment. If an evaluator submits five evaluations with scores of 8.5, 9.2, 7.8, 8.0, and 9.5, their average is 8.6 — which falls into the ≥ 7.0 tier and triggers a 250 USDC payout. The platform computes this automatically; no manual tier selection is exposed via the API. |
| 92 | </Accordion> |
| 93 | |
| 94 | ## Admin Manual Confirmation |
| 95 | |
| 96 | In exceptional cases — such as on-chain delays or network congestion — an administrator can manually confirm a payment using `POST /mods/procurement_wallet/usdc/manual-confirm`. This endpoint requires an `x-admin-key` header and should only be used when automated confirmation has stalled. |
| 97 | |
| 98 | ```bash |
| 99 | curl -X POST https://api.procurenet.io/mods/procurement_wallet/usdc/manual-confirm \ |
| 100 | -H "x-perplexity-mod-key: <api_key>" \ |
| 101 | -H "x-admin-key: <admin_key>" \ |
| 102 | -H "Content-Type: application/json" \ |
| 103 | -d '{ "payment_id": "pay_xyz" }' |
| 104 | ``` |
| 105 | |
| 106 | <Warning> |
| 107 | Manual confirmation bypasses on-chain verification. Only use this endpoint when you have independently verified the transaction on a block explorer and are certain the funds have arrived. Misuse can result in double-confirmation or incorrect payout records. |
| 108 | </Warning> |