Integrate institutional agent payments

Four-step trust boundary

1. A merchant or protected API returns an x402 or MPP payment challenge.
2. The enterprise wallet signs EIP-712 typed data for an ERC-3009 TransferWithAuthorization payload.
3. The institution backend calls /verify to validate the signer, recipient, amount, asset, validity window, nonce, and available USDC balance.
4. Only after approval does the backend call /settle; the Facilitator submits the onchain transfer and returns a transaction hash.

Discover protocol capabilities

curl http://localhost:4020/supported

Use this endpoint during startup to pin the x402 version, scheme, CAIP-2 network identifier, USDC contract, token decimals, and Facilitator signer.

Verify without settlement

curl -X POST http://localhost:4020/verify \
  -H 'Content-Type: application/json' \
  -H 'X-API-Key: <institution-api-key>' \
  -d '{
    "x402Version": 2,
    "paymentPayload": { "...": "wallet signed payload" },
    "paymentRequirements": { "...": "merchant requirements" }
  }'

A valid response includes isValid: true and the recovered payer. Failures return deterministic reasons such as signer_mismatch, recipient_mismatch, authorization_expired, or insufficient_funds.

Execute settlement

curl -X POST http://localhost:4020/settle \
  -H 'Content-Type: application/json' \
  -H 'X-API-Key: <institution-api-key>' \
  -d '{ "paymentPayload": { "...": "verified payload" } }'

A successful response includes success, network, payer, and transaction. Persist these fields with the internal order ID, policy decision, and idempotency key for reconciliation and audit.

AI Agent / MCP

The agent expresses payment intent through MCP tools. The payment service enforces per-transaction and cumulative budgets, selects x402 or MPP, and asks an isolated EVM wallet to sign. The model never receives the private key.

payment_capabilities  → discover supported payment rails
x402_fetch            → policy-controlled x402 request
mpp_fetch             → policy-controlled MPP request