x402 Payment
Concepts

x402 Payment Concepts

The Mflo platform implements the x402 HTTP Payment Required standard combined with EIP-3009 meta-transactions to enable seamless micro-payments for data access.

Glossary

  • x402 (opens in a new tab) is an HTTP standard based on the 402 "Payment Required" status code. The 402 code was reserved in the HTTP specification but not defined. x402 uses it to create a clear protocol for pay-per-request web services: when you request a protected resource, the server shows the payment required, and after payment, you get access to the data or service.

  • EIP-3009 (opens in a new tab) defines a method for off-chain authorization of ERC-20 token transfers.
    Instead of sending on-chain approval transactions, users sign messages that authorize token transfers. These signed messages can be executed by third parties, allowing seamless transfers while eliminating gas fees for the end user.

How It Works

  1. Client makes request to protected resource
  2. Server responds with 402 including payment requirements
  3. Client processes payment using the specified method
  4. Client retries request with payment proof
  5. Server validates payment and serves the resource

Payment Requirements Format

When a resource requires payment, the server responds with:

{
  "error": "Payment required",
  "paymentRequired": {
    "paymentRequirements": [
      {
        "scheme": "exact",
        "network": "localhost",
        "payTo": "0x70997970C51812dc3A010C7d01b50e0d17dc79C8",
        "maxAmountRequired": "50000000"
      }
    ]
  }
}

EIP-3009 Meta-Transactions

EIP-3009 enables off-chain authorization of token transfers that can be executed by third parties.

Key Benefits

  • No gas fees for users — Facilitator pays transaction costs
  • Offline signing — Users sign messages, not transactions
  • Replay protection — Nonces prevent duplicate authorizations
  • Time bounds — Authorizations can have validity windows

Authorization Flow

Security Considerations

Nonce Management

  • Each authorization uses a unique nonce
  • Prevents replay attacks
  • Tracked on-chain in authorizationState mapping

Time Bounds

  • validAfter - Authorization not valid before this timestamp
  • validBefore - Authorization expires after this timestamp
  • Prevents indefinite authorization reuse

Signature Verification

  • EIP-712 structured data signing
  • Domain separation prevents cross-contract attacks
  • Cryptographic proof of user intent

Error Handling

Common payment errors and their meanings:

  • "not yet valid" — Current time < validAfter
  • "authorization expired" — Current time > validBefore
  • "authorization used" — Nonce already consumed
  • "invalid signature" — Signature verification failed
  • "insufficient funds" — User balance too low
FAQsTestnet Tokens