Arcus
Site
Reference

Verify a payment

Checks a signed payment against the requirements without changing chain state. Call it before doing expensive work, then settle once the work succeeds.

POST/verify

Request

Send the decoded PAYMENT-SIGNATURE header from the client as paymentPayload together with the paymentRequirements your server advertised in its 402. Only x402 version 2 is accepted.

request
http
POST https://facilitator.arcusnetwork.co/verify
Content-Type: application/json

{
  "x402Version": 2,
  "paymentPayload": {
    "x402Version": 2,
    "accepted": { /* the requirement the client chose */ },
    "payload": {
      "authorization": {
        "from": "0xPayer", "to": "0xMerchant",
        "value": "10000",
        "validAfter": "0", "validBefore": "1760000000",
        "nonce": "0x…"
      },
      "signature": "0x…"
    }
  },
  "paymentRequirements": {
    "scheme": "exact",
    "network": "eip155:5042",
    "amount": "10000",
    "asset": "0x3600000000000000000000000000000000000000",
    "payTo": "0xMerchant",
    "maxTimeoutSeconds": 60,
    "extra": { "name": "USDC", "version": "2" }
  }
}
FieldMeaning
x402VersionMust be 2.
paymentPayloadThe client’s signed payload: the requirement it accepted plus the EIP-3009 authorization and signature.
paymentRequirementsScheme exact, an Arc network, the amount in 6-decimal USDC units, the USDC asset, payTo, maxTimeoutSeconds and the EIP-712 domain in extra.

What is checked

Verification runs entirely against the requirements and a read-only RPC call:

  • the signature recovers to the authorization's from address
  • value equals the required amount and to equals payTo
  • the current time is inside validAfter and validBefore
  • the payer's USDC balance covers the amount
  • the network is Arc mainnet or Arc testnet
A valid verify does not reserve funds. The payer could spend the balance before you settle, so keep the window between verify and settle short.

Response

200 OK
json
{ "isValid": true, "payer": "0xPayer" }
200 OK (invalid payment)
json
{
  "isValid": false,
  "invalidReason": "invalid_exact_evm_payload_authorization_value_mismatch",
  "invalidMessage": "authorization value does not match requirements amount"
}

Malformed bodies return 400, rate-limited callers return 429 and RPC failures return 500, each with isValid: false and an invalidReason. The full list is on the Errors and limits page.