For the complete documentation index, see llms.txt. This page is also available as Markdown.

Payment Flow

The x402 flow has three phases: InitiateSignSubmit. There are three integration flows depending on your chain/token combination and how much EIP-712 logic you want to handle yourself.

Flow
Strategy
When to use

A — Client-Side EIP-712

EIP-3009

USDC on Base / Polygon / Lisk — you build the hash locally

B — Facilitator-Assisted

EIP-3009

USDC on Base / Polygon / Lisk — facilitator builds the hash

C — Permit2

Permit2

BSC, Ethereum, or any non-USDC token

Check Supported Assets if you are unsure which applies to your chain/token.


Flow A — Client-Side EIP-712

Use this flow when you are on a USDC EIP-3009 chain (Base, Polygon, Lisk) and want full control over signing without an extra /build call.

What you need before starting

npm install ethers
import { ethers } from 'ethers';

const BASE_URL    = 'https://facilitator.ivorypay.io';
const API_KEY     = process.env.IVORYPAY_API_KEY;
const PRIVATE_KEY = process.env.EVM_PRIVATE_KEY;

Step 1 — Initiate the payment

The response body:


Step 2 — Decode the payment requirement


Step 3 — Build the EIP-712 typed data hash locally


Step 4 — Sign the hash


Step 5 — Build the payment-signature header


Step 6 — Submit the payment


Flow B — Facilitator-Assisted Build

Use this flow for USDC on EIP-3009 chains when you want the facilitator to compute the hash. Steps 1–2 and 4–6 are identical to Flow A; only Step 3 differs.

Step 3 — Call /build to get the typed data hash

Sign and submit exactly as in Flow A Steps 4–6, using validAfter from the /build response.


Flow C — Permit2 Signing

Use this flow for BSC, Ethereum, or any non-USDC token (e.g. USDT on BSC). The server uses Uniswap's Permit2 contract instead of EIP-3009.

One-time prerequisite: Before the first Permit2 payment, the payer wallet must approve the Permit2 contract to spend their tokens. See Permit2 Approval.

What you need before starting


Step 1 — Initiate the payment

Same as the other flows. Pass the correct token and network for your chain.


Step 2 — Decode the payment requirement


Step 3 — Call /build to get the typed data hash and spender

For Permit2, always call /build — you need the spender address (the gas-payer vault EOA) that the server assigns. This must be included in the signed message.


Step 4 — Build the Permit2 typed data hash locally

The Permit2 domain has no version field. The nonce is a uint256 (not bytes32). The signed struct uses deadline instead of validBefore, and there is no validAfter in the signed data.

Important: The hash returned by /build already encodes these parameters server-side. You can use buildBody.typedDataHash directly instead of computing the hash yourself — the result must be identical. If you compute it locally, ensure your domain, types, and message exactly match the above.


Step 5 — Sign the hash

Identical to EIP-3009 signing. Use the hash from /build (or your locally computed one if you verified they match).


Step 6 — Build the payment-signature header and submit

The payment-signature header structure is the same as for EIP-3009.


Verify a Payment Reference

After a successful submit you receive a sessionId. Use the verify endpoint to retrieve on-chain proof:

Last updated