Verify payments.
Settle on-chain.

Live networks & assets

X Pay provides x402 v2 exact-payment verification and settlement for USDC on Base mainnet and BNB Smart Chain mainnet. Base uses Circle USDC; BNB uses Binance-Peg USDC. The two assets have different contracts, decimals and authorization methods.

Amounts are positive integer strings in token atomic units. Convert decimal USDC prices using the selected token’s decimals, without floating-point rounding. Select the chain-specific API URL and query its /supported response before preparing payment requirements.

Mainnet payments transfer real USDC. Dashboard Test mode is a separate simulation; it does not turn these facilitator URLs into testnets.

Facilitator access & authentication

1. Open Facilitator Access in the dashboard and sign in or create your account.
2. Verify your email if requested, select your project and refresh access. Workspace owners and admins manage facilitator keys.
3. Enter a key name and your public EVM receiving wallet. The wallet is fixed for the project after registration; never enter a private key or seed phrase.
4. Generate and securely save the full key when it is shown. It is shown once. Up to five active keys can be held per project.
5. Keep the key on your resource server. Rotate by creating a replacement, updating your server and revoking the old key.

Use the key generated under Facilitator Access, not a dashboard merchant payment key. A shared xp_live_ prefix does not make the two credentials interchangeable. Public health, supported and status endpoints need no key.

Authorization: Bearer $XPAY_FACILITATOR_KEY
# Or use: X-API-Key: $XPAY_FACILITATOR_KEY
Content-Type: application/json

Use one authentication header. Keep credentials out of browser bundles, URLs and logs. A missing, invalid or revoked key returns HTTP 401; disabled merchant access returns HTTP 403.

From HTTP 402 to confirmed access

1. The resource server sets trusted payment terms: network, asset, exact atomic amount, receiving wallet and timeout. It returns HTTP 402 with an x402 v2 PAYMENT-REQUIRED header and an accepts entry.
2. The payer chooses a supported entry and signs its authorization. On BNB, the payer must first authorize the USDC token allowance to Permit2; this initial on-chain approval may cost BNB gas.
3. The payer retries the resource request with the base64-encoded x402 payment payload in PAYMENT-SIGNATURE.
4. The resource server calls the selected facilitator’s /verify. Check the JSON isValid value, not just HTTP 200.
5. The resource server calls the same network’s /settle with that payment payload and the same trusted payment requirements.
6. Deliver the paid resource only after success: true and a confirmed transaction. Save the chain, hash and order reference. Return the x402 settlement response in PAYMENT-RESPONSE.

The resource server creates the 402 challenge; /verify and /settle are authenticated facilitator operations, not public paid-resource discovery routes. Customer USDC moves to the receiving merchant, rather than being deposited into a facilitator balance.

Verify & settle request contract

Send JSON to POST /verify or POST /settle on the chosen network’s API base URL. Both use the same envelope. The signed payload comes from the payer; the resource server supplies its own trusted payment requirements.

Do not accept a payer’s price or receiving address as trusted server configuration. Amount, recipient, asset and chain must match the authorization and your paid resource.

Base · EIP-3009 authorization

Base USDC signs TransferWithAuthorization typed data with domain name USD Coin, version 2, chain ID 8453 and verifying contract 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913.

Use an x402 EVM client to generate the signature and payload. The signature must authorize exactly the resource server’s terms. Verification does not transfer funds; settlement submits USDC’s transferWithAuthorization.

BNB · Permit2 authorization

Binance-Peg USDC on BNB uses Permit2 instead of Base’s EIP-3009 format. Requirements must include extra.assetTransferMethod: "permit2" and use 18-decimal USDC atomic amounts.

Use a compatible x402 EVM exact client to create the Permit2 witness typed data; do not reuse a Base signature. The payer’s USDC allowance must cover the amount and target Permit2. A first-time token approval is separate from the off-chain payment signature. The facilitator pays BNB for the settlement transaction.

Read the result, not just the status code

These fields describe the live API contract. A successful HTTP response alone is not confirmation. The Base and BNB responses are not identical: inspect invalidReason, failureReason or errorReason as applicable.

Confirm receipts & prevent duplicate delivery

Store the payment payload reference, trusted terms, network, order ID and transaction hash. Check a receipt on the same chain as the payment: successful execution and the expected USDC transfer recipient and amount must match the order.

For Base settlement, send a stable Idempotency-Key for the same order attempt; duplicate payment/idempotency references return the existing result. The BNB route does not provide the same application-level idempotency header behavior. Use your own durable order lock and receipt reconciliation for both chains. On-chain authorization nonces prevent authorization reuse; they do not replace your fulfillment lock.

On a timeout, reconcile any known transaction hash before retrying. Never deliver twice because a caller retried or a network response was lost.

Errors & recovery

Structured infrastructure errors use success: false and an error object with code, message and requestId. Verification and settlement business failures use the fields in the result table above. Preserve the request ID for support; never send your key or private signing material.

Service details & operational checks

Public signer on both networks: 0x589a2314a2e05f45e40c4823da3ba58d421db3d8. Public status endpoints expose the current signer, chain, native gas balance and settlement-enabled flag. Capability endpoints expose the current supported scheme, asset and signing method; use those responses as the live contract.

/health confirms reachability. healthy: true in status indicates a positive native gas balance, not a guaranteed transaction capacity or uptime SLA. Gas conditions and RPC availability can change. BNB capabilities also advertise the builder-code extension with code xpay.

Base historical settlement evidence is available through the public signer’s BaseScan history. BNB activity is available through BscScan. Explorer activity is transaction evidence; it does not imply any directory endorsement.

Current integration scope: Base USDC and BNB Binance-Peg USDC mainnet. Additional networks, other assets and dashboard test simulations are separate from this live facilitator service.