Building Agentic Commerce Rails: x402 Patterns for Machine-to-Machine Payments

Quick Overview: So, x402 is bringing back the old HTTP 402 status code and giving it a fresh purpose. Now, it acts as a payment channel that AI agents and services can tap into using good ol' standard HTTP. Pretty cool, right? This guide gives you the lowdown on practical x402 patterns, handy code-level tips, and the freshest best practices to make machine-to-machine payments a breeze. You'll be able to settle transactions in just seconds, regardless of the blockchain you're working with!

---

Why x402 matters for decision‑makers

The agent economy definitely needs a payment method that ticks off a few important boxes:

• It’s gotta be web-native, so we can ditch those annoying custom sockets and avoid getting trapped in any SDK lock-ins.
• It should be set up for machines to handle on their own, so there's no need for a human to step in during the checkout process.
• It should be priced low enough for those small payments. Oh, and we definitely can’t overlook the fact that it needs to be quick enough to keep things running smoothly without any annoying delays.

So, x402 is all about simplifying things by using the 402 Payment Required status for requests over HTTP. It basically makes pay-per-request a whole lot easier to handle! It features a couple of straightforward headers and has a "facilitator" role to manage verification and settlement tasks. The coolest part? It doesn’t care what blockchain you’re using! It works with all kinds of payment systems and can easily slot into your current APIs as middleware. Super convenient, right? Hey, take a look at this on GitHub! It's pretty cool!

---

A 90‑second mental model of x402

• Your API works with good old HTTP/HTTPS. If someone--whether it's a person or a bot--tries to get into a paid endpoint without proving they've paid, your server will respond with a 402 status. It’ll also include some clear payment requirements in a format that machines can easily understand. So, the client goes ahead and makes the payment using any method you’re cool with, like USDC on an EVM L2. Once that’s done, they’ll give it another shot with the request, but this time they’ll toss in an X-PAYMENT header that has the payment proof all neatly encoded. You can either check the payment yourself or contact a facilitator's verify endpoint to get the info you need. Feel free to ask the facilitator to help you out with a quick settle if you need it. In the end, you'll send back a 200 status and toss in an X-PAYMENT-RESPONSE that lays out all the transaction details. (github.com).

Key Protocol Objects and Headers:

• Payment Requirements: Here’s your 402 response payload.
• X-PAYMENT: This is where you’ll find the client’s payment information.
• X-PAYMENT-RESPONSE: This is the signal you get back when everything's in order, and it comes as a 200 response. Feel free to take a closer look over on GitHub!

---

The x402 stack in 2025: what’s real, where to build

• Core Spec and Reference Stacks: So, if you dive into Coinbase’s x402 repository, you’ll find a treasure trove of specs, types, middleware, and a facilitator API. Plus, there are some handy examples in TypeScript, Go, Java, and Python to help you get started! It outlines the current scheme in detail and suggests an "up to" model that comes with usage limits. Take a look at it on GitHub! You might find it interesting!
• Multi-Chain: So, what's their official stance? They're all about being chain and token agnostic! When people talk about “2-second settlement,” they’re actually just pointing to the usual block times you see with L2 or Solana. It’s not set in stone or anything like that. Just picture it like the experience a user really aims for, you know? If you want to dive deeper into the specifics, check out x402.org for more info!
• Solana: We've got an entire page just for the Solana ecosystem! You’ll find starter templates there too, like Next.js stacks, facilitators, and explorers. It’s a great place to kick things off! If you’re looking for those super low fees and fast finality, this option is really heating up! Check out solana.com when you get a chance!
• EVM Gasless: Thanks to Thirdweb’s handy facilitator, you can easily verify and settle x402 payments without stressing over gas fees. How great is that? They can cover gas fees using EIP-7702, which means clients won’t have to worry about using their own native gas. This one's definitely a great pick if you're looking for that classic web2 vibe! More info on portal.thirdweb.com.
• USDC Signatures and Token Oddities: A bunch of transactions rely on EIP-3009 (transferWithAuthorization) and/or ERC-2612 permit.
  It’s really crucial to grasp the differences between chains and tokens. For example, the way “USDC” functions on Polygon PoS doesn’t always match up neatly with what EIP‑3009 outlines. Just something to keep in mind! Check out all the info you need right here: web3-ethereum-defi.readthedocs.io. It’s got everything laid out for you!
• BNB Gaps: A lot of assets on the BNB Chain don’t actually support EIP‑3009, so that’s where Infra402 comes into play. It wraps assets like xBNB, making it possible to use just signature-only x402 flows. This also helps with settling and analyzing things at the facilitator level. If you're looking to shake things up, having BNB in your market strategy could really be a game changer! Learn more at infra402.com.
• Third-Party Wallets/CLIs: Good news! There are currently x402 wallet command-line interfaces (CLIs) you can use for agent automation. This lets you set up EIP-3009 authorizations and manage transactions on Base, Ethereum, and Base Sepolia. Pretty neat, right? These are really great for headless agents and continuous integration. Take a look at x402-wallet.com! You might find something interesting there.

Related but distinct:

So, you know how Interledger's Open Payments and STREAM work? They're essentially like APIs that help with settling payments directly between accounts. Pretty cool, right? They really do a fantastic job of connecting banks and wallets! You can smoothly combine them for getting money in and out or even for routing across different networks. It's super easy! Take a look at it on GitHub: github.com. You'll find some cool stuff there!

Now, on the flip side, we've got Cloudflare's Pay-Per-Crawl. It's really focused on delivering those 402 responses on a grand scale, and it even gives you the ability to negotiate prices using headers. Pretty neat, right? It's a really good confirmation of the 402 handshake pattern. It's not quite x402, but the ideas are definitely in the same ballpark! Check out all the juicy details right here: (blog.cloudflare.com).

---

The x402 patterns we recommend shipping in 2025

Check out these awesome “rails” we set up for our clients! Just keep in mind that it’s really about picking up on the patterns instead of just focusing on the code itself.

1) 402 Handshake: Reactive vs Intent‑First

• Reactive (discovery-first): Alright, let me break it down for you. When a client tries to access your paid endpoint but doesn't meet the necessary requirements, you hit them back with a 402 error. This little message lets them know what they need to do to get access. Pretty straightforward, right? After they make their payment, they can give it another shot using the X-PAYMENT header. This setup can create a little bit of lag since it involves an extra round trip. It's really awesome for all those different agents who are trying to figure out pricing on the fly. Check it out here.
• Intent-First (precommit): Here’s the other side of the coin--right from the get-go, the client jumps in by either showing proof of payment or letting you know what they’re ready to pay when they make their first request. They base this on the requirements you've already laid out in your ads. If everything looks good, go ahead and send them a 200 response right off the bat. This method takes a page from some interesting 402 patterns that have been used effectively on a larger scale. For example, there's a cool distinction between crawler-max-price and crawler-exact-price. If you want to dive deeper into it, you can check it out here!

Practical Tip:

Feel free to hit that publish button! You can either find the well-known/prices.json file or choose to embed it directly in the OpenAPI x-extension. By doing it this way, agents can snag the data all at once, store it with a max-age limit, and then switch to intent-first mode. This helps them avoid that annoying extra 402 charge!

2) Exact Price Payments (today’s production workhorse)

When you're using the "exact" scheme, just remember to specify a set amount. And hey, if you're working with USDC, don’t forget to get that EIP-3009 authorization. For any other ERC-20 tokens, you'll need the ERC-2612 permit for signature-only transactions. Make sure you’ve got that covered! Hey there! When setting up your PaymentRequirements, make sure to include these key details: the scheme, network, maxAmountRequired (that’s in atomic units), payTo, asset, and maxTimeoutSeconds. This info is super important for everything to work smoothly! Take a look at it on GitHub! You won't want to miss this.

Example PaymentRequirements (excerpt):

Let’s take a quick peek at what you might find in the Payment Requirements section:

{
  "paymentMethod": "Credit Card",
  "required": true,
  "minAmount": 10.00,
  "maxAmount": 500.00,
  "currency": "USD",
  "description": "A valid credit card is required for payments."
}

Key Points:

• Payment Method: You’ll be using a credit card for this one.
• Required: For sure, you’re gonna want to grab this!
• Minimum Amount: You’ll need to spend at least $10.
• Maximum Amount: Just a heads up--make sure you don’t exceed $500, cool?
• Currency: We're dealing with good old USD!
• Description: Just a quick heads-up! You'll need a valid credit card to complete any transactions.

That's pretty much the main point!

{
  "x402Version": 1,
  "accepts": [{
    "scheme": "exact",
    "network": "eip155:8453",            // Base mainnet
    "maxAmountRequired": "10000",        // 0.01 USDC if 6 decimals
    "resource": "https://api.example.com/premium-data",
    "description": "Pay-per-call for premium data",
    "mimeType": "application/json",
    "payTo": "0xMerchantWallet...",
    "maxTimeoutSeconds": 10,
    "asset": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", // example
    "extra": { "name": "USD Coin", "version": "2" }
  }]
}

Contract nuance

Hey there! If you’re diving into EIP‑3009, just a quick tip: be sure to use those authorizations only once by going with receiveWithAuthorization. Happy coding! Oh, and make sure to keep track of the nonce to steer clear of any replay problems. You definitely don't want to run into those! Just a heads-up: if you’re dealing with bridges and tokens that don’t quite meet the standards, you might want to have a backup plan ready. If you want to dive deeper into the details, just click here. Happy exploring!

3) Usage‑Capped “Upto” Payments (emerging)

If you're dealing with metered APIs, like those that track LLM tokens or compute seconds, it's smart to have an "up to" limit in place. This way, you can keep things manageable and avoid any surprises! So basically, the client agrees to let you use their data up to a set limit, and you only bill them for what they actually end up using. It's a pretty fair deal! If you’re looking for more info on this approach, you can check it out in x402. There are some great extensions there! Right from the get-go, make sure you nail down your measurement, idempotency, and partial-fulfillment semantics. It’ll save you a lot of headaches later on! Take a look at this: github.com. It's worth checking out!

Production Tips:

Feel free to authorize up to your session cap, which is around $0. 25). Just remember to charge for what you actually used, and then any leftover amount from that cap should be returned in your X-PAYMENT-RESPONSE. That way, it'll make things easier for your client's accounting! Hey there! Just a quick reminder to include some structured metering in your reply. It would be great if you could break it down into a few key parts: make sure to highlight the billable_units, give the unit_price, and, of course, wrap it up with the total_charged. Thanks!

4) Gasless UX via EIP‑7702 or Paymasters

Two Turnkey Paths

• 7702 Sponsorship (Best Bet if It's Available): If you have regular EOAs, you can totally level them up to “smart EOAs”! Just use session keys and get some help with gas costs. With this approach, agents only have to sign once, which means they won’t need any native gas. You can easily turn this on with just one config flag in thirdweb. Take a look at this: (portal.thirdweb.com). You'll find some cool info there!
• ERC‑4337 + Paymaster for USDC Gas: If you’ve got a wallet that’s already set up for 4337, you should definitely check out Circle’s Paymaster. It’s a solid choice! You can easily grab gas straight from your USDC using an EIP‑2612 permit. This is a pretty cool way to make sure everything runs smoothly and efficiently! If you’re looking for more details, check this out: circle.com.

So, when tokens aren’t compatible with EIP-3009 or EIP-2612, here's what you need to know: You’ve got a couple of options here--like going for a wrap or an upgrade approach, kind of similar to what BNB does. With Infra402, wrapping lets you turn different assets into those cool 3009-style signature flows. Plus, it keeps that user-friendly “signature-only” x402 experience exactly how you love it. Take a look at it here: infra402.com. You might find it interesting!

5) Facilitator‑First Architecture

Think about handing off the verification and settlement tasks to a facilitator microservice. It can be part of your own setup or even something provided by a vendor. So, the specs highlight three main endpoints you should know about: /verify, /settle, and /supported. Make sure your resource server is lightweight and efficient--let the facilitator take care of the heavy lifting for you! On top of that, thirdweb's facilitator is all set to go, with support for more than 170 EVM chains right out of the box. How cool is that? Take a look on GitHub! You'll find some interesting stuff there!

Pattern: Here's how the process flows: you start with the resource, then move on to facilitator.verify(), followed by fulfill, and then facilitator.settle(). Finally, you wrap it all up with respond.

• Resilience: If the settlement doesn’t go as planned after it’s fulfilled, make sure to keep track of the “debt.” Then, start a new settlement process to make things right, and don't forget to set up alerts to remind you along the way!

6) Dual‑Network Acceptance

Hey there! Just a heads up, you can now use a bunch of different accepted entries, like USDC on Base and SOL on Solana. It’s a great way to diversify your options! Hey, just a heads up--when you're working on this, remember to encode the chain in both the requirement and the proof. Also, take a moment to double-check the chain ID. It’ll help you avoid any cross-chain replay headaches down the road! Hey there! If you’re diving into building on Solana, you should really take a look at the x402 Solana starter and facilitator. It's a great way to keep everything aligned with the handshake. Trust me, you won't regret it! (github.com).

7) Receipts and Attestations

Don't forget to include the X-PAYMENT-RESPONSE along with the settlement details, like the txHash and networkId. It's important to have all that info together! Make sure to sync this up with your analytics warehouse too! Your agents can pick up this header as structured data, which is super helpful for tracking expenses and dealing with retries. These are the main points you should definitely remember. Take a look at this: github.com. You might find it interesting!

8) Idempotency and Replays

Hey there! Just a quick reminder: whenever you're working with any paid endpoints, don’t forget to include an Idempotency-Key. It’s super important for keeping things organized and making sure you’re handling deduplication on your side. Thanks! So, when it comes to EIP-3009, it's really crucial to make sure you're using unique nonces and establishing those validity windows, like validAfter and validBefore. Just a heads up: because different chains and tokens can behave in unique ways, make sure you give replays a good test on each chain you’re working with. It's worth the extra effort! If you want to dive deeper into the details, just click here. Happy exploring!

9) Refunds and Disputes

Implement a /refunds Endpoint

So, you’re going to have to set up a /refunds endpoint. Just make sure it’s linked to the original X-PAYMENT and the txHash. Just a heads up, once settlements are made on-chain, they’re pretty much set in stone. So, when you're processing refunds, you can think of it as starting a whole new on-chain payment. Hey, just a quick reminder: make sure to add your own receipt header!

Oh, and we should definitely talk about how crucial it is to have a solid “reason” code taxonomy for reconciliations! Staying organized is super important for making sure everything goes off without a hitch.

Alright, let me give you a quick rundown of what you should include:

• Endpoint: /refunds
• Keying: Make sure to use X-PAYMENT along with the txHash.
• Settlement: Final on-chain
• Refund Process: You’ll get a fresh on-chain payment along with a personalized receipt header.
• Reason Code Taxonomy: This is for handling reconciliations.

Just make sure you get everything sorted out, okay?

10) Pricing Discovery and Caching

Don't forget to share machine-readable prices for every endpoint and be sure to throw in some cache control info too!

• Save the 402 status code for situations where we’re negotiating without any churn involved. So, big crawlers that work on a massive scale are already tapping into intent negotiation. They’re using headers like max-price and exact-price to get things done. It’s pretty cool to see how they’re managing these negotiations! It would be awesome to see that same easy-to-use vibe in the x402 clients! (blog.cloudflare.com).

---

Code: minimal Express server with a facilitator

Check out this quick sketch I threw together! It highlights the main x402 flow on an EVM L2, plus it includes a facilitator. Hope it gives you a clear picture! We've decided to keep things straightforward, so we left out those complicated authorization edge cases, logging details, and retry mechanisms. This way, we can keep it brief and to the point!

import express from "express";
import { encodePaymentHeader, verifyWithFacilitator, settleWithFacilitator } from "./x402-kit"; // your wrapper
import { toAtomic } from "./pricing";

const app = express();
const payTo = process.env.MERCHANT!;            // 0x...
const asset = process.env.USDC!;                // ERC-20 address
const network = "eip155:8453";                  // Base mainnet

const price = toAtomic("0.01", 6);              // 0.01 USDC

function paymentRequirements() {
  return {
    x402Version: 1,
    accepts: [{
      scheme: "exact",
      network,
      maxAmountRequired: price.toString(),
      resource: "https://api.example.com/premium-data",
      description: "Premium dataset, per-request",
      mimeType: "application/json",
      payTo: payTo,
      maxTimeoutSeconds: 10,
      asset,
      extra: { name: "USD Coin", version: "2" }
    }]
  };
}

app.get("/premium-data", async (req, res) => {
  const paymentHeader = req.header("X-PAYMENT");

  if (!paymentHeader) {
    res.status(402).json(paymentRequirements());
    return;
  }

  // Verify payment intent & payload
  const ver = await verifyWithFacilitator({
    x402Version: 1,
    paymentHeader,
    paymentRequirements: paymentRequirements().accepts[0],
  });

  if (!ver.isValid) {
    res.setHeader("X-PAYMENT-RESPONSE", encodePaymentHeader({ error: ver.invalidReason }));
    res.status(402).json(paymentRequirements());
    return;
  }

  // Fulfill work and try to settle
  const body = { data: "your premium JSON goes here" };

  const settle = await settleWithFacilitator({
    x402Version: 1,
    paymentHeader,
    paymentRequirements: paymentRequirements().accepts[0],
  });

  res.setHeader("X-PAYMENT-RESPONSE", encodePaymentHeader(settle));
  res.status(200).json(body);
});

app.listen(3000);

• Get yourself a legit facilitator: thirdweb has a facilitator that provides /verify and /settle endpoints. Plus, they can help with gas fees thanks to EIP-7702! (portal.thirdweb.com). If you’re diving into Solana, definitely check out the Solana x402 template and its facilitator. The HTTP process is pretty much the same, but just a heads-up--the payloads are a bit different, so make sure you keep that in mind! (solana.com).

---

Security checklist that actually catches bugs

• Replay resistance:
• EIP‑3009: Just a heads up--don’t forget to enforce those unique authorization nonces on the server side, and make sure to use receiveWithAuthorization. Make sure to watch out for any unique quirks related to the chain, particularly the historical issues on Polygon PoS. Check it out here.
• Non‑EVM: Make the most of the built-in replay guards offered by your network. A great example of this is Solana's memo and nonces that you can use via your facilitator.
• Header tampering: Make sure to double-check the on-chain proof. It's always a good idea! Take a moment to double-check those client-declared amounts and receivers before you just accept them as they are. It's always a good idea to verify!
• Stick to HTTPS: Don't forget to turn away any x402 requests that come in without encryption. Think of X-PAYMENT as just another step in verifying your identity. It's like an essential part of the whole authentication process.
• Timeboxes: Make sure you stick to the maxTimeoutSeconds that you've set for your needs and what your business SLA calls for. If things take longer than expected, you can either deliver part of the order or go ahead and give a refund.
• Dealing with settlement failures: So, if you've double-checked everything and the settlement still doesn't go through, just send back a 200 status since you've done your part. But don’t stop there! Make sure to set up a compensating settlement job and flag an alert to keep everyone in the loop. Make sure you pay attention if a facilitator marks something as "success: false." It’s important not to let that slip by. If you want to dive deeper into the details, you can check it out here.
• Multi-tenant separation: If you're running a platform for several merchants, it's super important to keep those signer keys separated. Don't forget to take a close look at all your /settle paths and make sure everything's in order! Just to give you an example, when you’re using thirdweb’s facilitator, it actually relies on your server wallet for incoming transactions. So, it’s a really good idea to keep those keys backed by a hardware security module (HSM). It just adds that extra layer of security you definitely want to have! If you're looking for more details, just click here. It’ll take you to a page with all the info you need!

---

Architecture blueprints

1) “Stripe‑for‑Agents” Aggregator

• Who: We’re diving into platforms that offer tons of developers the opportunity to sell their APIs, computing services, or data straight to agents.
• What: It's basically a platform that combines a multi-tenant facilitator with a marketplace, all in one. So here's the deal: they charge a platform fee, which is often called a "developer fee" at a rate of x402, but only when it’s applicable. If that’s not the case, they go with a second-line settlement rule instead. They’ve also got you sorted with 7702 right from the start, making it super easy to get onboarded. Take a look at this! You can find all the details right here: blog.thirdweb.com. Enjoy!

2) DePIN & Robotics Payments

How about we use x402 as the money rail and throw in an agent trust/identity layer? I mean, just look at ERC‑8004: Trustless Agents--it’s a solid way to help reduce fraud among all those devices like docks, drones, and sensors. It could really streamline things! Projects like M402 are all about syncing up identity and reputation with the x402 settlement. It’s pretty cool how they’re looking to bring those elements together! Check it out here for more info!

3) Enterprise Hybrid: x402 + Interledger/Open Payments

• Go ahead and roll out x402 at the edge--it makes monetizing your APIs super easy whenever you need it! Oh, and guess what? You can easily move merchant balances into your bank accounts every day by using Open Payments over ILP. It's super convenient! This approach lets your treasury team manage ACH and SCT transactions while staying on top of those pesky KYC requirements for counterparties. Hey, take a look at this on GitHub!

---

Tooling snapshot: what to evaluate this quarter

Hey, have you seen the Coinbase x402 reference implementation? It's got pretty much everything you need, like the specs, TypeScript SDKs, and even some handy examples. Definitely worth a look! You can check it out on GitHub at this link: github.com.

• If you’re ready to explore the x402 ecosystem, definitely check out x402.org! It's the go-to spot. Check out their site! They've got a bunch of resources for learners, along with some handy tools and server options. You can find it all at x402.org.

Hey there! Interested in checking out the thirdweb x402 facilitator? They’re offering a whopping 7,702 sponsorship and session keys for more than 170 EVM chains. It’s definitely worth a look! Dive in here: (portal.thirdweb.com).

If you're into Solana, definitely check out their x402 templates and facilitator options--they're super useful! You can find more info right here: (solana.com).

Hey, make sure you check out the h402 protocol variant! It’s pretty cool because it supports both EVM and Solana. Plus, there's an exciting roadmap ahead for features like "upto," streamed content, and subscriptions. You won’t want to miss this! "Check out this awesome resource for exploring different header and settlement designs: (github.com). You'll find some really interesting options there!"

Hey! If you’re bringing a team on board, definitely take a look at the Proxy402 docs. They’re super helpful! If you’re curious about what x402 really is, they’ve got a pretty cool introductory guide over here: (docs.proxy402.com). It breaks things down nicely!

If you're in the BNB scene, you'll be excited to hear that Infra402 is breaking new ground with a wrapping process that opens up signature-only flows. For more info, check this out: (infra402.com).

• And hey, before I forget, if you’re interested in how reference 402 works on a larger scale, definitely check out the Cloudflare PPC docs. Here’s the link: developers.cloudflare.com. It's worth a look!

---

Pricing and UX: patterns that convert

Alright, so here's the deal: we're sticking to stablecoins like USDC on Base and Solana as our go-to option. But for those of you who are looking to spice things up a bit, we’ll also toss in some more volatile assets for that extra thrill. When it comes to latency, let’s try to keep it below 500 ms for both verification and settlement.
We can have the facilitator check things out while processing, and if the network is a bit bogged down, we can settle things later on.

• When it comes to partial refunds, especially for those "up to" session deals, we should definitely include the unspent cap in the X-PAYMENT-RESPONSE. This way, agents can easily monitor their budgets without any hassle. What do you think about a “try it before you buy it” approach? We could keep the high-end final results under wraps and tease users with some previews or low-res samples for free. That way, we can get them excited about what’s coming! Alright, developers, let’s come up with a client helper that takes care of all the heavy lifting for us! This little gem will handle 402 errors, take care of signing, manage payments, retry when things go south, and even lay out those typed errors for us. How great would that be? So, that's basically what the x402 client examples are all about--the way they're set up really captures the whole concept. Take a look at it over on github.com! It's worth checking out!

---

Compliance and risk notes (what legal will ask)

• With x402, you can keep your personal info super low-key! It processes requests without needing you to create an account, so you won’t have to share more than what you want. Let’s stick with that for now, unless you need to tackle any KYC thresholds. Hey there! Just a quick note about the tax stuff: it’s a good idea to go ahead and issue on-chain receipts along with those monthly summaries. It'll make things a lot clearer when you’re keeping track of everything! The X-PAYMENT-RESPONSE headers, along with the ledger tables, should cover what most auditors need. Just make sure everything lines up with your bank statements when you're going through Open Payments, ILP, or any exchanges. If you want to dive deeper into the details, just click here. You'll find all the information you need! Chargebacks? Nah, not when you’re on-chain! Just ensure your refund policy is super clear, set up to run automatically, and make sure to keep everything documented. That way, you’re covered!

---

Appendix: client ergonomics and header design inspiration

So, when it comes to navigating the vastness of the internet, crawlers have a bit of a task on their hands. They need to determine pricing by sending out headers and going through a whopping 402 round-trips, comparing max-price and exact-price. It’s a bit of a back-and-forth dance until they finally receive a 200 response that comes with a “charged” confirmation header. Quite the journey, right? Hey there! So, if your agents are pulling in paid content, here's a little tip: try to stick with the x402 method and focus on intent first whenever possible. If that doesn’t work out for some reason, you can always fall back on just using 402. Hope that helps! (blog.cloudflare.com).

So, if you check out the line-level developer docs about the 402 status, you'll find that MDN mentions it's been “reserved” for quite a while now. The x402 status really puts a clear label on things, especially when it comes to payments. Feel free to take a look at it here: developer.mozilla.org.

---

Where 7Block Labs helps

• Discovery workshop: pick your chains, decide on the schemes, and figure out if you’d like a build/run approach or prefer a partner facilitator model. Hey there! Just wanted to give you a heads-up about our reference implementation. We’re planning to roll out a top-notch x402 gateway that’s going to come packed with some cool features. You can expect it to support 7702 gasless transactions, handle idempotency, and have built-in retries, alerts, analytics, and even refund processes. We’re aiming to have everything ready in about 4 to 6 weeks, so stay tuned! Alright, here's the deal: when it comes to Marketplace and DePIN blueprints, think of mixing x402 with ERC-8004 trust signals along with Open Payments. This combo really helps make bank sweeps super seamless.

If you want to start charging agents for your APIs in under a second and skip all the hassle of them creating accounts, x402 is definitely the fastest way to go from "We should monetize this" to actually bringing in some cash.

---

References and further reading

Take a look at the x402 protocol specs along with some helpful examples! They’ll give you a better idea of how everything works. (github.com).

• Dive into the lowdown on x402.org and check out its whole ecosystem!
  (x402.org).
• Check out the thirdweb x402 facilitator and learn how the EIP‑7702 gas sponsorship actually works! (portal.thirdweb.com).
• Check out the Solana x402 builders page! And hey, while you're there, don’t forget to snag some templates too! (solana.com). Let’s take a closer look at the ins and outs of EIP-3009 when it comes to USDC. We can’t forget about the Polygon PoS details and some handy tools that can help out along the way! (web3-ethereum-defi.readthedocs.io). Hey, if you're looking to manage some 4337 gas with USDC, definitely take a look at Circle's Paymaster! It’s worth checking out! (circle.com). Check out Infra402! It's all about putting BNB first when it comes to wrapping for x402. (infra402.com). Hey there! Have you heard about the h402 variant? It's this really cool blend of EVM and Solana. If you want to dive into it, there's a lot to discover! (github.com). Diving into Interledger Open Payments and the STREAM protocol can be really exciting! They’re both pretty cool concepts that open up a world of possibilities in the payment space. Just think about how they're designed to make transactions smoother and more interconnected across different platforms. If you're curious to learn more, I'm here to help! (github.com).
• Check out Cloudflare's Pay-Per-Crawl and see how it can help you get 402 working efficiently on a larger scale! (blog.cloudflare.com).
• Check out the draft for ERC‑8004 Trustless Agents! (eips.ethereum.org).

---