Accept X402 Payments Direct
How vendors accept direct, verifiable payments
As a vendor, you actively generate the payment reference (nonce), verify the on-chain event, and fulfill the order once the payment is confirmed.
Payment flow from the vendor’s perspective
You generate a nonce for each order and verify the payment on-chain before fulfillment.
Flow option 1: customer submits the transaction
VENDOR CUSTOMER CONTRACT VENDOR | | | | | 1) Generate nonce | | | |-------------------->| | | | | 2) Submit payment | | | | with nonce | | | |--------------------->| | | | 3) Return tx ID | | | |<---------------------| | | 4) Customer sends | | | | tx ID + nonce | | | |<--------------------| | | | 5) Check contract events | | |-------------------------------------------->| | | 6) Verify hash(nonce) matches event | | |<--------------------------------------------| | | 7) Fulfill order | | | |-------------------->| | |
- You generate a nonce for the order or invoice.
- The customer submits the payment with that nonce.
- The contract emits PaymentExecuted(nonceHash).
- The customer sends you the transaction ID and the nonce.
- You verify that keccak256(nonce) matches the event.
- Once verified, you fulfill the order.
Flow option 2: vendor submits the transaction (gasless for customer)
VENDOR CUSTOMER CONTRACT | | | | 1) Generate nonce | | | + payment details| | |-------------------->| | | 2) Customer signs | | | payment (EIP-712)| | |<--------------------| | | 3) Vendor submits | | | signed payment | | |-------------------->| | | 4) Verify event, | | | fulfill order | |
- You generate the nonce and payment details.
- The customer signs off-chain (no gas required).
- You submit the signed payment and cover gas.
- You verify the event and fulfill the order.
Fee flexibility
You control who pays the transaction fee using feeTarget.
| feeTarget | Who pays | Use case |
|---|---|---|
| 0 | Customer | Standard flow |
| 1 | Vendor | Premium UX, vendor absorbs fees |
Verification checklist
- Get the nonce you issued.
- Compute keccak256(nonce).
- Find the transaction on-chain.
- Confirm the event contains your nonce hash.
- Fulfill the order once verified.
Recipient verification
Depending on the customer’s wallet configuration, you may need to be on a verified list.
| Proof type | Requirement |
|---|---|
| 0 (All) | No restriction |
| 1 (Verified) | Must be on global verified list |
| 2 (Custom) | Must be on customer’s allowlist |
| 3 (Verified or Custom) | Budget allows either verified or custom |
Vendor responsibilities
- Generate a unique nonce per order.
- Provide payment details (amount, token, address, nonce).
- Choose fee handling.
- Optionally submit transactions for gasless UX.
- Verify the on-chain event.
- Fulfill the order after verification.
Nonce rules
- Vendor-generated nonces must be unique per payee + payor.
- Signed payments use this nonce uniqueness on-chain.
- Direct payments also enforce a 24-hour reuse lock per payor/budget/token.
Referral fees
If a payor has a referrer configured, a portion of the fee (up to 30%) can be routed to the referrer for up to two years. The remainder goes to the fee wallet.
Why vendors like this flow
- Cryptographic proof of payment tied to your nonce.
- Privacy-preserving on-chain events.
- Flexibility to pass or absorb fees.
- Option to offer gasless payments.
- Budget-backed payments reduce failed transactions.