Skip to main content
This page describes the self-hosted AIFP-1 gate flow. It is a protocol explanation, not a signing workaround for an unsupported client deployment. Check current payment support first.
  1. Read the merchant origin’s /.well-known/x402.json and API parameter catalog.
  2. Request a protected resource. HTTP 402 describes its merchant, resource, tier, price, minimum batch and receipt scope.
  3. Request a fresh quote from the advertised quote endpoint. Inspect the amount, asset, chain, expiry and deployment against independently trusted client configuration and the owner’s budget.
  4. Use a supported, verified executor for that deployment. Do not construct a transaction solely from untrusted quote calldata or an old ABI example.
  5. Submit the transaction reference and the required wallet-bound payment authorization to the pay endpoint. Wait for successful verification and a quota receipt.
  6. Verify the receipt, then retry the resource with AIFP-Receipt: <receipt>.
  7. Reuse that receipt for subsequent requests within its scope and remaining quota.
Contract generations have different ABIs and guarantees. Legacy payMatic examples are not instructions for a v1.2 payNative deployment, and a v1.3 executor cannot be pointed at either by changing an address. A protocol label such as AIFP-1 does not make the contract generations interchangeable.

​
What each artifact proves

Wallet creation, an invoice, or a funded address is not a completed payment. The MCP tool reference says which preparation tools are actually available in the published server. See the public agent-flow document for implementation context and the installed package’s versioned documentation for supported executors. Keep transaction recovery state private; never put raw signing material or bearer receipts in logs or recordings.