Summary: Great news! 402 is officially live! This playbook will guide you through how to send “proof of payment” HTTP headers that are compatible with the new x402 v2 flows. You’ll be able to verify everything on-chain (think USDC/EIP-3009) and keep everything secure with RFC 9421 message signatures and RFC 9530 content digests. This means your platform can effortlessly handle pay-per-request APIs without the usual headaches of setting up new accounts, wading through SDK clutter, or dealing with reconciliation issues. Dive into the details here: (docs.cdp.coinbase.com)

Developing “Proof of Payment” Headers for HTTP 402 Compliance

• Alright, so your API gateway is handling rate-limiting and monthly billing pretty well, but it’s having a tough time keeping track of the “$0.004 per inference” for those AI agents calling in from outside your SSO realm. You’ve tried out prepaid keys and webhooks, but ops is still stuck with manual reconciliations, while finance is insisting on receipts for every single response. And let’s not even get started on that time a reverse proxy cached a paid response for the free users--that was a classic blunder! With product aiming for a Q2 launch, the pressure is definitely on.
• What you really need is web-native payments seamlessly integrated into the request/response flow, plus cryptographic receipts. This setup allows your auditors and partner APIs to verify everything without needing to just take your word for it.
• It seems you're facing some missed revenue targets because of that pesky 20-40% leakage with those “trial” keys. Your partner channels aren't budging without those portable receipts, and procurement isn't making any moves either since there's no reliable trace from “402 → paid → 200 OK.” Ship dates keep getting delayed, the GPT cost line is on the rise, and with every unmetered call, your margins are taking a hit.

We’ve got an awesome payment-as-HTTP setup going on, and it’s way more than just another payments microservice. Check out the design below: it’s built using x402 v2 header conventions, EIP‑3009 for gasless USDC settlement, and it sticks to RFC 9421 for signed responses. Plus, we’re keeping everything secure with RFC 9530 digests to ensure content integrity. This setup has been put to the test with Coinbase’s x402 facilitator and plays nicely with neutral routers like P402. And if you’re interested, it can even shoot out PEAC receipts for independent verification. (docs.cdp.coinbase.com)

• What “402 compliance” actually means
  • So, when we talk about HTTP 402, it boils down to using it as the main checkpoint. The server sends over pricing info along with some details in the headers. Then, the client gives it another shot with a signed payment payload. After that, the server does its thing--verifies everything, processes the payment, and then sends back the resource you asked for. If you want to dive deeper, check out Coinbase’s x402 docs, which are already being used by a bunch of facilitators. (docs.cdp.coinbase.com)
  • Jump on the v2 x402 header names for smoother interoperability: you’ll find PAYMENT-REQUIRED (from server to client), PAYMENT-SIGNATURE (from client to server), and PAYMENT-RESPONSE (server to client when it’s a 200 response). Quite a few docs and routers in the ecosystem are now standardizing on these terms. (docs.cdp.coinbase.com)
  • Don’t forget to pinpoint networks using CAIP‑2 strings (like eip155:8453 for Base) and tokens with CAIP‑19. This will help clear up any mix-ups between different L2s and sidechains. (docs.cdp.coinbase.com)
• Why EIP‑3009 Matters
  • Alright, let’s break it down: users or agents kick things off by signing an EIP‑712 "transferWithAuthorization/receiveWithAuthorization" payload. Then, a facilitator comes in to submit it and takes care of the gas fees. The coolest part? You can skip all those annoying allowances and the typical “approve + transfer” process, plus users don’t have to stress over gas costs. This method has really taken off with USDC on major EVM chains, and it even keeps tabs on the on-chain nonce through authorizationState(). Want to dive deeper? Check it out here.
  • Quick security tip: if you’re sending to a contract, it’s way smarter to use receiveWithAuthorization to steer clear of any front-running headaches in the mempool. But no worries--x402 facilitators can handle both options effortlessly. For more info, just click here.
• Proof-of-delivery, not just payment
  • Make sure you connect the content that’s been paid for to the response using RFC 9530 Content‑Digest/Repr‑Digest. Plus, sign the 200 OK response with RFC 9421 HTTP Message Signatures that include the Payment-Response, the digest, and the path/method. This approach makes it super easy for auditors to verify the receipt without having to sift through your entire stack. (rfc-editor.org)
• Real-World Performance and Ecosystem Momentum
  • So, the x402 production docs have some interesting info - it turns out CAIP-2 is all about supporting multiple networks. From what the community's saying, when you’re moving from 402 to 200, the end-to-end times can really vary; we’re talking anywhere from under a second to about 2 seconds, and it all depends on Layer 2 conditions. Plus, routers like the P402 are showing off some seriously impressive stats with a 99.99% uptime and internal routing latencies under 100ms. Just a heads-up, though: these insights come from vendors and the community, so we’ll definitely double-check everything to meet your SLOs when we get to staging. (docs.cdp.coinbase.com)

Who This Is For (and the Keywords You Should Care About)

Hey! If you’re the API Platform Owner, the Head of Monetization, or a Staff Engineer managing gateways that deal with more than 10,000 requests per second from agent traffic, this is just for you.

Here are some keywords you should definitely watch out for:

• CAIP‑2
• CAIP‑19
• EIP‑3009
• EIP‑712
• RFC 9421
• RFC 9530
• RFC 9651 Structured Fields
• Idempotency‑Key (IETF draft)
• KYT/OFAC screening hooks
• p95 end‑to‑end latency
• HTTP/2+H3 intermediaries
• mTLS
• Replay protection

If you want to dive deeper, take a look at the specs on httpwg.org.

---

The header contract we deploy

1. A 402 response (from server to client)

• Required headers
  • Status: 402 Payment Required (just sticking to the HTTP rules here). (datatracker.ietf.org)
  • PAYMENT-REQUIRED: This is a Base64URL-encoded JSON (x402 v2) that gives a deep dive into accepted payment options, resource details, and some anti-replay info. (docs.cdp.coinbase.com)
  • Content-Type: application/problem+json (yep, that one comes from RFC 9457), which provides machine-readable details about the problem. This makes it super easy for generic clients to tackle any issues related to pricing, expiry, or errors. (rfc-editor.org)
• Example (shortened):

HTTP/1.1 402 Payment Required
Content-Type: application/problem+json
PAYMENT-REQUIRED: eyJ4NDAyVmVycyI6MiwgImFjY2VwdHMiOlt7InNjaGVtZSI6ImVpcC0zMDA5IiwgIm5ldHdvcmsiOiJl
aXAxNTU6ODQ1MyIsICJh... (base64url) ...

Decoded PAYMENT-REQUIRED JSON:

Here's what the PAYMENT-REQUIRED JSON looks like once we've decoded it. It gives us a better understanding of the data structure and what to expect.

{
  "error": {
    "code": "PAYMENT_REQUIRED",
    "message": "Payment is required to access this resource.",
    "status": 402
  },
  "details": {
    "transaction_id": "1234567890",
    "amount_due": 50.00,
    "currency": "USD",
    "payment_url": "https://example.com/pay"
  }
}

Breakdown

• error: This section shows there’s a problem.
  • code: It’s saying we need to make a payment.
  • message: A friendly reminder that we need to pay for access.
  • status: This tells us the HTTP status code related to the error.
• details: Here, we can find the specifics.
  • transaction_id: A unique ID for tracking the payment.
  • amount_due: This is how much we owe.
  • currency: The type of currency we're dealing with.
  • payment_url: A link to make the payment.

So, if you run into this response, you'll know payment is needed to move forward. Don’t forget to check the payment URL to clear things up!

{
  "x402Version": 2,
  "resource": "POST /v1/vision/satellite:tile?id=T-918273",
  "accepts": [
    {
      "scheme": "eip-3009",
      "network": "eip155:8453",
      "asset": "eip155:8453/erc20:0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", 
      "amount": "5000",       // in token base units (e.g., 6 decimals USDC)
      "payTo": "0x7B...B1",
      "validForSeconds": 120
    }
  ],
  "requestDigest": "sha-256=:4Jw...=:",
  "session": "402_sess_f7b2b3d1",
  "facilitator": {
    "verify": "https://facilitator.example.com/verify",
    "settle": "https://facilitator.example.com/settle"
  },
  "extensions": {
    "receipt": "peac", 
    "policyUri": "https://api.example.com/.well-known/peac.txt"
  }
}

• Notes
  • So, CAIP‑19 is the unique identifier for the USDC contract on Base. You can check it out here.
  • The requestDigest is crafted according to RFC 9530, which creates a digest from specific parts of the original request intent, including the method, path, query, and any body fields we need to sign. For all the nitty-gritty details, take a look at this link.

2) Retry with Proof of Payment (Client → Server)

When a client makes a payment, it’s crucial for the server to confirm that the transaction was successful. Here’s the scoop on managing retries with proof of payment:

1. Client Initiates Payment: The client kicks things off by sending a payment request to the server.
2. Payment Processing: The server jumps in to process the payment. If all goes well, it whips up a proof of payment.
3. Send Proof Back to Client: The server then zips this proof back over to the client, which can include handy details like transaction ID, amount, timestamp, and more.
4. Client Acknowledges Receipt: It's super important for the client to let the server know they received the proof of payment. This little step helps clear up any potential confusion later on.
5. Retry Logic: In case the client doesn’t get a green light from the server (maybe due to a little network hiccup), they should have a backup plan to resend the proof of payment.
6. Final Confirmation: Once the server gets that proof again, it can give the thumbs up for the payment and wrap up the transaction.

This way, both the client and the server are in sync, which helps cut down on any headaches when it comes to payment confirmations!

• Required headers
  • PAYMENT-SIGNATURE: This is a Base64URL-encoded JSON that contains the EIP‑712 authorization (EIP‑3009). You'll need it to properly connect with the PAYMENT-REQUIRED fields. For all the nitty-gritty details, check it out here.
  • Idempotency-Key: Make sure to generate a UUID on your end to keep your POST/patch requests idempotent. This way, if you have to retry, you won’t accidentally create any chaos. You can find more info here.

Example payload (decoded):

{
  "scheme": "eip-3009",
  "network": "eip155:8453",
  "asset": "eip155:8453/erc20:0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
  "authorization": {
    "from": "0xA1...CE",
    "to": "0x7B...B1",
    "value": "5000",
    "validAfter": 0,
    "validBefore": 1739200000,
    "nonce": "0x9f2c...e1",
    "signature": "0x{r}{s}{v}"
  },
  "bind": {
    "requestDigest": "sha-256=:4Jw...=:",
    "session": "402_sess_f7b2b3d1"
  }
}

200 OK with Cryptographic Receipt (Server → Client)

When a server replies with a "200 OK" response along with a cryptographic receipt, it's like giving a thumbs up that everything went well with the request. This receipt is a clever way for the client to check that the response hasn’t been tampered with. Let’s break down how it all works:

1. Server processes the request: So, the server gets the request that’s come in, does its magic, and gets ready to send back a response.
2. Generate a cryptographic receipt: Once the server has finished processing, it whips up a receipt using some smart cryptographic techniques. Typically, this means it generates a hash of the response data, which is super handy for making sure that the response hasn’t been messed with.
3. Response sent to client: The server responds with a "200 OK" status, along with the original response data and the cryptographic receipt.
4. Client verifies the receipt: After the client gets the response, they can use the cryptographic receipt to make sure that the data is both intact and legit.

This process not only gives clients confidence that the data they’ve received is legit, but it also provides a crucial layer of security. It’s definitely a smart move for building trust between the server and the client!

• Required headers on success
  • PAYMENT-RESPONSE: This is a Base64URL JSON that includes the txHash or facilitator receipt, the final amount, and the same session info. You can dive deeper into it over at p402.io.
  • Content-Digest/Repr-Digest: This one ensures that the representation you get is all in one piece (check out RFC 9530 for the details). Read more about it here: (rfc-editor.org).
  • Signature-Input, Signature: These are the message signatures from RFC 9421 that cover: @method, @path, payment-response, content-digest, and date. If you need more info, check this out: (rfc-editor.org).
  • Optional: PEAC-Receipt: Think of this as a compact JWS receipt that shows “who paid what under which policy.” It’s super handy for portable verification. For the full scoop, head to (x402.peacprotocol.org).

Example (headers only):

HTTP/1.1 200 OK
Content-Type: application/json
PAYMENT-RESPONSE: eyJ0eEhhc2giOiIweGIxYy4uIiwic2Vzc2lvbiI6IjQwMl9zZXNzX2Y3YiIsImFtb3VudCI6IjUwMDAifQ
Repr-Digest: sha-256=:s8m5o5Hh8n5uC1...=:
Signature-Input: sig1=("@method" "@path" "payment-response" "repr-digest");created=1739189000;keyid="api-gw-key-2026"
Signature: sig1=:kVbC.../==:

---

Implementation patterns (fast, safe, verifiable)

• Express Middleware (Server Side)
  • When you hit a snag, send back a 402 status with PAYMENT-REQUIRED. If you’re trying again, don’t forget to double-check that PAYMENT-SIGNATURE:
    • Make sure the network and CAIP-19 are in sync.
    • Recalculate the requestDigest and session binding.
    • Verify the EIP-712 signature off-chain; just ensure that the nonce is still fresh and hasn’t been used with token.authorizationState(). After that, you can either reach out to the facilitator for /verify and /settle, or use eth_call to simulate receiveWithAuthorization before you hit submit. (eips.ethereum.org)

// Pseudocode: payment middleware
app.post("/v1/vision/satellite:tile", async (req, res, next) => {
  const price = 5000n; // 0.005 USDC, 6 decimals
  const wantsProof = req.headers["payment-signature"];

  if (!wantsProof) {
    return res
      .status(402)
      .set("PAYMENT-REQUIRED", base64url(JSON.stringify(makePaymentRequired(req, price))))
      .type("application/problem+json")
      .send(makeProblemDetails(req, price));
  }

  const proof = decodePaymentSignature(req.headers["payment-signature"]);
  assertCAIP2Network(proof.network, "eip155:8453");
  assertCAIP19Asset(proof.asset, USDC_BASE_CAIP19);
  assertDigestBind(proof.bind.requestDigest, req);

  // Verify EIP-712 auth off-chain
  const okSig = verifyEIP3009TypedData(proof.authorization, USDC_DOMAIN);
  if (!okSig) return res.status(402).send(problem("invalid-signature"));

  // Check nonce unused on-chain
  const used = await usdc.authorizationState(proof.authorization.from, proof.authorization.nonce);
  if (used) return res.status(402).send(problem("nonce-used"));

  // Settle via facilitator (or submit tx directly)
  const vr = await facilitator.verify(proof);
  if (!vr.valid) return res.status(402).send(problem("insufficient-funds"));
  const settle = await facilitator.settle(proof);

  // Produce content and attach receipts/digests/signature
  const body = await renderTile(req.query.id);
  const reprDigest = makeReprDigest(body);
  const payResp = { txHash: settle.txHash, amount: price.toString(), session: proof.bind.session };

  res
    .set("PAYMENT-RESPONSE", base64url(JSON.stringify(payResp)))
    .set("Repr-Digest", reprDigest) // RFC 9530
    .set(makeHttpMessageSignatureHeaders(req, reprDigest, payResp)) // RFC 9421
    .status(200)
    .json(body);
});

• Client pattern (agent or backend service)
  • When you make the call, if you run into a 402 error, take a look at the PAYMENT-REQUIRED message. From there, you’ll want to create the EIP‑3009 typed data, sign it up, and send the PAYMENT-SIGNATURE over. Oh, and make sure to include an Idempotency-Key for any of those POST or PATCH replays. (docs.cdp.coinbase.com)
• Caching and intermediaries
  • When you're working with paid resources, make sure every 200 OK response has Cache-Control: no-store and no-transform included. This step helps stop any accidental cache leakage or changes by CDNs. If you're fine with caching on private edges, consider throwing in Vary: Payment-Signature to keep your cache keys distinct. You can dive deeper into the specifics here.
  • When you're adding new headers, it’s a good idea to go with RFC 9651 Structured Fields. This method really helps boost resilience when your data passes through proxies. And if you absolutely need to send JSON, make sure to base64url-encode it--this is pretty standard practice in the ecosystem nowadays. For more details, check out this link.
• Idempotency and retries
  • Go ahead and implement the Idempotency-Key draft. It'll make those non-idempotent methods way safer when clients or networks attempt to retry. This is super important for processes like 402 → pay → 200. You can check it out here: (ietf.org)
• Tamper resistance across hops
  • Ensure you sign your successful responses (and even the 402 ones if you feel like it) using RFC 9421 HTTP Message Signatures. Remember to include @method, @path, payment headers, and the content digest. Setting up mTLS between your API gateway and facilitator adds that extra layer of security against replay attacks. For all the nitty-gritty, take a look here: (rfc-editor.org)
• Deterministic Nonces (Advanced)
  • Want to connect authorizations to a specific request without storing any state? You can derive the EIP‑3009 nonce by hashing together (method, path, query, requestDigest, session). This method is pretty similar to what a lot of audited systems do for gasless deposits. It not only boosts idempotency but also simplifies reconciliation quite a bit. Check out more about it on openzeppelin.com.

---

• Example: Coinbase x402 on Base with CAIP‑2
  • With the x402 v2 update, network identifiers like eip155:8453 are now front and center. Be sure your Payment‑Required is showcasing these identifiers, and remind your buyer to verify that the facilitator is settling on the right chain. (docs.cdp.coinbase.com)
• Example: Rust types for EIP‑3009 payloads
  • If you’re diving into Rust, it’s super important to recreate TransferWithAuthorization exactly as it is to avoid any EIP‑712 domain mismatches. Good news though, there are community crates out there that have already shared the struct along with the serde derives. You can take a look at it on (docs.rs).
• Example: Receipts you can rely on even after vendors are gone
  • PEAC provides a JWS receipt (PEAC‑Receipt) that connects the SHA‑256 of the paid content to a policy snapshot and the settlement reference. This means it’s portable and you can verify it on your own. Your 200 OK response can include both the PAYMENT-RESPONSE and the PEAC-Receipt. (x402.peacprotocol.org)
• Example: ZK/Private Receipts Roadmap
  • If you want to keep the details of who paid and how much under wraps while still letting people know that a payment was made, zk receipts are the way to go! These nifty proofs confirm that a legitimate payment took place without spilling any personal details. We'll stick with our existing header contract and just throw in a zk receipt reference in the Payment-Response whenever it’s needed. Take a look at all the info right here: (zkverge.gitbook.io)
• Example: Confidential facilitators
  • If you want to build trust in your facilitator, consider verifying it using a TEE (like Oasis ROFL). You can attest its public key on-chain and share the digest of the enclave build. This approach allows your PAYMENT-RESPONSE to include a reference to the TEE attestation. (docs.oasis.io)

---

Security checklist we enforce in delivery

• Replay and binding
  • Link the EIP‑3009 nonce to the exact request intent using requestDigest/session. If there's any mismatch, simply reject it. It's also a good idea to keep those validity windows short--aim for around 120 seconds or less when it comes to authorizations.
• Front-running
  • If the payee is a contract, use receiveWithAuthorization. For externally owned accounts (EOAs), ensure that the settlement is completed on the server side before you send them a 200 OK. (eips.ethereum.org)
• Keeping it secure, both at rest and in transit
  • Be sure to sign your responses using RFC 9421, and don’t forget to add some digest checks with RFC 9530. You’ll want to be on TLS 1.2 or higher, and it wouldn’t hurt to think about using mTLS for those facilitator links. (rfc-editor.org)
• Interoperability
  • When it comes to identifying networks and assets, lean on CAIP‑2/CAIP‑19. Make sure to use x402 v2 header names, and if you're planning to include any custom headers, go for Structured Fields. You can find more details here.
• Caching
  • Make sure to set Cache-Control: no-store, no-transform on your paid responses. If your private edge caches really need to keep results sorted by payer, consider using Vary: Payment-Signature. (httpwg.org)
• Compliance hooks
  • Remember to include KYT/OFAC hooks in the facilitator /verify function. Make sure to keep PII emissions as low as possible, and don't forget to use receipts like PEAC or something similar for your audits.

---

Emerging best practices (Jan 2026)

• Let’s update to the x402 v2 header names and CAIP‑2 identifiers, and treat those old X‑ headers as just legacy stuff now. (docs.cdp.coinbase.com)
• When we send out a 402 response, let’s stick with application/problem+json bodies. It’ll help keep things consistent for clients, according to RFC 9457. (rfc-editor.org)
• Remember to add PAYMENT-RESPONSE and Repr‑Digest to the RFC 9421 signatures; this is super important for making sure that receipts are preserved across CDNs and logs. (rfc-editor.org)
• It would be awesome to create a public /.well-known/… for discovery--think pricing, policies, keys; PEAC has set up peac.txt and JWS receipts that are easy to verify offline. (x402.peacprotocol.org)
• Don’t forget to cover the use of Idempotency-Key and TTLs (IETF draft), especially for those POST endpoints that throw a 402 response. (ietf.org)

---

What you get with 7Block Labs (technical + business outcomes)

• Architecture and Implementation
  • We’ve got an awesome 402 PoP flow all set for production. It comes packed with tools to measure p95 latency and keep track of decision traces. This is your go-to solution, featuring gateway middleware, facilitator integration, on-chain settlement adapters, plus the perks of RFC 9421 signing, RFC 9530 digests, and optional PEAC receipts.
  • Need something a bit different? If you’re after custom rails or looking to branch out across chains, we’re here for you! We can roll out CAIP‑2/19 across various chains and set up routing policies tailored just for you, including Base primary and fallback options.
• Security and Audits
  • We’re diving deep into checking out EIP‑712 domains, nonce derivation, and replay boundaries. And just for kicks, we're looking at beefing up facilitators with TEEs (you totally saw that coming, right? 😂) and validating everything on-chain.
  • Curious for more? Our security audit services cover smart contracts and HTTP signature surfaces all wrapped up in one solid threat model.
• Key Integration and GTM Metrics to Keep an Eye On
  • Time-to-first-revenue: You’re looking at about 3-6 weeks to kick off a pilot, depending on which gateway you go with (Kong, Envoy, or API GW). On top of that, you’ll need an extra 1-2 weeks to integrate the x402 facilitator and sort through those receipts.
  • Latency: Latency is a fascinating topic right now. We’re seeing numbers that range from under a second to about 2 seconds for the whole process (that’s 402 → settle → 200), and it all depends on the load at L2. We’ll make sure to map out SLOs and retries clearly in your Statement of Work. (oasis.net)
  • Evidence of adoption: The data coming from x402 organizations and community reports is pretty impressive--think tens of millions of transactions getting processed, along with multi-facilitator tools like routers and MCP payments. No worries, we’ll benchmark your flows against these baselines during staging. (x402.org)
• Easy-to-get deliverables
  • A user-friendly “one-pager” layout that highlights RFC references (9421, 9530, 9651), a header matrix, and straightforward, measurable SLOs.
  • Reconciliation pack: this is basically an exported ledger that covers PAYMENT-RESPONSE + txHash + Content-Digest + signature--finance teams can carry out sample verifications on their own, no engineering help required.
  • Risk controls: we’ve got KYT hook points, spending limits, and policy-driven pathways in facilitator/routers.
• Where our services fit in
  • Complete build-out: Check out our custom blockchain development services and web3 development services to get started.
  • Gateway + ERP/RevRec integration: We’ve got you covered with our blockchain integration services.
  • Multi-rail expansion or create your own facilitator: Explore our cross-chain solutions development to see how we can help you out.
  • Token and settlement contracts (for those not using USDC): Don’t miss our smart contract development for all your needs!

---

Appendix: Minimal client example (Node, EIP‑3009 on Base/USDC)

import { ethers } from "ethers";
import fetch from "node-fetch";
import base64url from "base64url";

const USDC_BASE = "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913";
const DOMAIN = { name: "USD Coin", version: "2", chainId: 8453, verifyingContract: USDC_BASE };
const TYPES = {
  EIP712Domain: [
    {name:"name",type:"string"},
    {name:"version",type:"string"},
    {name:"chainId",type:"uint256"},
    {name:"verifyingContract",type:"address"},
  ],
  TransferWithAuthorization: [
    {name:"from",type:"address"},
    {name:"to",type:"address"},
    {name:"value",type:"uint256"},
    {name:"validAfter",type:"uint256"},
    {name:"validBefore",type:"uint256"},
    {name:"nonce",type:"bytes32"},
  ]
};

async function buy(url: string, wallet: ethers.Wallet) {
  // 1) Attempt
  const r1 = await fetch(url, { method: "POST", body: JSON.stringify({id:"T-918273"}) });
  if (r1.status !== 402) throw new Error(`Expected 402, got ${r1.status}`);
  const pr = JSON.parse(base64url.decode(r1.headers.get("payment-required")!)); // x402 v2

  // 2) Build EIP-3009 auth
  const msg = {
    from: wallet.address,
    to: pr.accepts[0].payTo,
    value: pr.accepts[0].amount,
    validAfter: 0,
    validBefore: Math.floor(Date.now()/1000)+120,
    nonce: ethers.hexlify(ethers.randomBytes(32))
  };
  const sig = await wallet._signTypedData(DOMAIN, { TransferWithAuthorization: TYPES.TransferWithAuthorization }, msg);

  const proof = {
    scheme: "eip-3009",
    network: pr.accepts[0].network,
    asset: pr.accepts[0].asset,
    authorization: { ...msg, signature: sig },
    bind: { requestDigest: pr.requestDigest, session: pr.session }
  };

  // 3) Retry with PAYMENT-SIGNATURE + Idempotency-Key
  const r2 = await fetch(url, {
    method: "POST",
    headers: {
      "Payment-Signature": base64url.encode(JSON.stringify(proof)),
      "Idempotency-Key": crypto.randomUUID(),
      "Content-Type": "application/json"
    },
    body: JSON.stringify({id:"T-918273"})
  });

  if (r2.status !== 200) throw new Error(`Payment failed: ${await r2.text()}`);
  const payResp = JSON.parse(base64url.decode(r2.headers.get("payment-response")!));
  console.log("txHash", payResp.txHash, "digest", r2.headers.get("repr-digest"));
}

Here’s a list of the references for the standards and flows we talked about earlier:

• HTTP 402 Semantics
• x402 v2 Headers and CAIP‑2
• EIP‑3009 Authorization Types and Security Considerations
• RFC 9421 HTTP Message Signatures
• RFC 9530 Digests
• RFC 9651 Structured Fields
• Idempotency-Key IETF Draft

If you want to dive deeper, take a look at this link: datatracker.ietf.org.

---

Prove -- GTM Metrics We’ve Got on the Roadmap

• We're aiming for a pilot launch in around 3 to 6 weeks. Once we have your facilitator credentials all set up, we can look forward to seeing our first paid 200 OK in less than 10 business days!
• When it comes to baseline performance, our ecosystem references indicate that we're targeting claims processing in under a second and a total end-to-end time of about 2 seconds, even during L2 congestion. We’ll tweak the retry backoffs and validity windows to match your SLOs. For more details, head over to oasis.net.
• When it comes to interoperability, we're supporting CAIP‑2 networks such as Base, Ethereum, and Solana where it makes sense. We also have EIP‑3009 support for USDC and we're sticking to the RFC standards for signatures and digests. If you're looking for policy routing or Discovery (“Bazaar”) metadata, routers like P402 are up to the task. You can check out more info at docs.cdp.coinbase.com.
• When it comes to receipts, we’ve got optional PEAC JWS receipts that are super handy for offline verification. They can really help out with policy binding, especially during procurement and legal reviews. If you want to dive deeper into this, just check out x402.peacprotocol.org.

---

7Block Labs | How We Engage

• First up, we dive into the discovery phase. This is where we whip up a design document that lays out the headers, signature coverage, and a plan for facilitators. After that, we jump into the pilot phase, and once that’s all set, we gear up for the production hardening. No worries--we’ve got your back on both the HTTP and on-chain layers.
• Ready to jump in? Take a look at our custom blockchain development services. If you want to enhance your finance systems, be sure to check out our blockchain integration options. Plus, we’ve got your back when it comes to securing your stack with our security audit services.
• If you're considering going multi-chain, we’ve got you covered with our cross-chain solutions development and tailor-made smart contract development.

CTA -- Let's Chat This Week!

Hey! If you're managing the API Gateway or handling the Monetization setup for a Base-first AI SaaS and you're aiming for a “pay-per-inference” model by Q2 2026, with a p95 under 1.5 seconds, let’s chat!

Let’s take 45 minutes to explore a broad design that includes PAYMENT-REQUIRED, SIGNATURE, and RESPONSE elements. We’ll also check out an RFC 9421 signature set that your auditors can easily verify. Plus, we’ll walk you through a step-by-step rollout on your gateway and initiate a two-week pilot that provides genuine 200 OKs along with receipts you can verify.

Just let us know which gateway you’re using--Kong, Envoy, or CloudFront--and what your target chain looks like. We'll whip up a tailored plan for you, complete with a working PoP demo that meets your SLOs and keeps your CFO happy with their reconciliation needs. Can’t wait to hear back from you!