---

description: Stablecoin-native HTTP payments are evolving to be more agent-friendly. In this post, we'll dive into how to integrate x402 into your API, allowing AI agents to make payments in USDC for every call. We'll also tackle the multi-chain complexity by using chain abstraction that covers Base, Solana, and more. Plus, you'll find practical code snippets, operational checklists, and compliance tips to keep you on track.

Stablecoin Payment Rails for AI Agents: Bridging x402 and Chain Abstraction

Decision-makers are grappling with the same challenge: how can we enable AI agents to pay for APIs on demand, without the hassle of accounts, keys, or checkouts--and make it work seamlessly across different chains without overwhelming users with complexity? The solution lies in combining x402 (HTTP-native payments) with chain abstraction (a smooth multi-chain experience without the headaches). Here's a straightforward blueprint that your teams can roll out this quarter.

• TL;DR for execs
  • x402 is transforming regular HTTP into a cool payment rail, allowing agents to pay per request using stablecoins like USDC. It works with a 402 round-trip and a signed payment header. Coinbase rolled out the open-source spec on May 6, 2025, collaborating with folks from AWS, Anthropic, Circle, and NEAR. Check it out on Coinbase.
  • Cloudflare and a few others are now integrating x402 features into edge runtimes and agent frameworks. The Solana, Base, and Arbitrum ecosystems are also getting into the game with their first-party tools. Dive into the details at Cloudflare Developers.
  • With chain abstraction--think intents, gas abstraction, USDC CCTP, and facilitators--you won't even have to worry about which chain is in play. It keeps costs down and offers a straightforward "pay with digital dollars" experience for both humans and machines. Learn more over at Blockworks.

---

Why x402 matters now (and what’s actually new in 2025)

• HTTP-native: The x402 is bringing back the 402 Payment Required code and sets up a standard response body called PaymentRequirements, along with a client header (X‑PAYMENT) and a response header (X‑PAYMENT‑RESPONSE). Your API kicks it off by returning a 402 with payment options, the client then retries with a signed payload, and a facilitator steps in to verify and settle everything, leading to a smooth 200 response. Check it out on GitHub.
• Agent-first: If you’re into Cloudflare, their Agents docs show how to wrap fetch with x402 to enable auto-paying right from Workers or agents. This makes life easier for bots and browserless clients since they don’t need API keys. Find more details over at Cloudflare Developers.
• Multi-scheme: The “exact” (fixed price) billing model has gone GA, while “upto” (metered until a cap) is starting to gain traction in third-party stacks--perfect for LLM token-based billing. More info can be found on Thirdweb.
• Low-latency rails: Solana is rocking some seriously fast 400ms finality and costs around $0.00025 in fees, making sub-cent micropayments totally doable. Plus, Base and other EVM L2s keep USDC fees close to a penny and back EIP‑3009 for gasless transfers. Dive deeper at Solana.
• Ecosystem momentum: Coinbase has dropped a launch post and GitHub spec that really formalize the facilitator API (with endpoints like POST /verify and /settle). They’ve got some notable public partners too, including AWS, Anthropic, Circle, and NEAR. You can read more over on Coinbase.

---

Primer: the x402 wire format your teams will ship

A server that charges $0.01 for a GET request to /weather might respond like this:

HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "x402Version": 1,
  "accepts": [
    {
      "scheme": "exact",
      "network": "base",
      "maxAmountRequired": "1000000", // 1e6 = $0.01 in 6‑dec USDC
      "resource": "https://api.example.com/weather",
      "description": "7‑day forecast",
      "mimeType": "application/json",
      "payTo": "0xYourSettlementAddress",
      "maxTimeoutSeconds": 30,
      "asset": "0xaf88...USDC", 
      "extra": { "name": "USD Coin", "version": "2" }
    },
    {
      "scheme": "exact",
      "network": "solana",
      "maxAmountRequired": "10000", // 1e4 = $0.01 in 4‑dec USDC (SPL)
      "resource": "https://api.example.com/weather",
      "description": "7‑day forecast",
      "mimeType": "application/json",
      "payTo": "YourSPLAddress",
      "maxTimeoutSeconds": 30,
      "asset": "USDC" 
    }
  ]
}

The client chooses a route (like Base), builds the signed Payment Payload, and then tries again with:

GET /weather HTTP/1.1
Host: api.example.com
X-PAYMENT: eyJ4NDAyVmVyc2lvbiI6MSwic2NoZW1lIjoiZXhhY3QiLCJuZXR3b3JrIjoiYmFzZSIsInBheWxvYWQiOnsKICAiZXJjXzMwMDkiOiB7IC4uLiB9CiB9fQ==

Your server either handles verification and settlement locally or through a facilitator:

• Hit the endpoint POST /verify with your original PaymentRequirements and the base64 X‑PAYMENT header. If everything checks out, you can get down to business.
• Next, use POST /settle to submit it on‑chain. You’ll get a 200 response back which includes the X‑PAYMENT‑RESPONSE with the tx hash and networkId. Check it out here: (github.com)

Tip: Check out EIP‑3009 on EVM! This way, the client can sign an authorization, and your facilitator takes care of the gas--so no ETH is needed in the user wallet. If you're on Solana, just go for SPL transfers--no need for EIP‑712. (eips.ethereum.org)

---

From demo to design: a reference architecture that bridges x402 and chain abstraction

Your goal is to allow any buyer--whether it's a person, an agent, or a service--to make payments using “digital dollars,” while you keep the flexibility to manage the chains, fees, and latency behind the scenes.

• Components
  • x402 Resource Server: This is basically your API or where you keep your content. It’s set up to send out 402 errors and accept X‑PAYMENT (think Node/Express, Hono, or Cloudflare Workers). You can read more about it here.
  • Facilitator: This service checks signatures and wraps up transactions. You’ve got the option to run your own using Coinbase’s guidelines, or you can go with a managed facilitator like thirdweb, which supports EIP‑3009, ERC‑2612, and EIP‑7702 for those gasless submissions. Check it out here.
  • Chain Selector: This acts as a policy layer that figures out which network to use in PaymentRequirements (think Base, Solana, Arbitrum) depending on things like cost, latency, and availability.
  • Chain Abstraction Rails:
    • USDC CCTP: This feature lets you burn and mint native USDC across different chains with Fast Transfer, helping keep your treasury all in one place. Learn more here.
    • Intents layer (optional): You can use intents and fillers (like ERC‑7683) to handle swaps and bridges without complicating things for the agent. Get the scoop here.
    • Gas abstraction: Think of ERC‑4337 smart accounts combined with Paymasters that cover gas fees for agent wallets. You can dive deeper here.
  • Observability: Make sure to stash the X‑PAYMENT‑RESPONSE along with the transaction hash and networkId; then send that info off to your SIEM and finance systems.

Why This Works:

• x402 keeps the client API super straightforward, and the chain abstraction makes your treasury and user experience a breeze. You can promote multiple accepted entries (think Base + Solana) and let the client choose what they want. Plus, your facilitator and CCTP pull everything together in the back office. Check it out here: (github.com)

---

Concrete implementation paths (copy‑paste ready)

1) Minimal Hono/Workers Server with Coinbase x402 Primitives

Setting up a minimal Hono/Workers server with Coinbase's x402 primitives is a straightforward process if you follow these steps:

Step 1: Install Dependencies

Before diving into code, ensure you have the necessary dependencies installed. You can do this by running:

npm install --save hono@latest @cloudflare/workers-types@latest @codair/cs-react@latest

Step 2: Create Your Server

Next up, let's create a simple server using Hono. Here’s a basic example:

import { Hono } from 'hono';

const app = new Hono();

app.get('/', (c) => c.text('Welcome to the Hono/Workers server with Coinbase x402!'));

export default app;

Step 3: Integrate with Coinbase x402

To work with Coinbase x402 primitives, you need to include them in your application code. Here’s a simple way to do that:

import { x402 } from 'coinbase-sdk';

app.get('/api/x402', async (c) => {
  const response = await x402.getTransactions();
  return c.json(response);
});

Step 4: Deploy Your Server

Once everything is set up, you can deploy your server to Cloudflare Workers. Just run:

wrangler publish

Final Thoughts

That’s it! You've got a minimal Hono/Workers server running with Coinbase x402 primitives. Feel free to customize and expand upon this basic setup as your project evolves!

For more detailed info, don't forget to check out the official Hono documentation and the Coinbase x402 API docs.

• Make sure to wrap your route with a payment middleware and a facilitator call (verify → work → settle). You can find some handy reference implementations in Cloudflare’s Agents docs and the examples from Coinbase. Check it out here: (developers.cloudflare.com)

2) Dynamic, Metered AI Pricing with “Upto”

When it comes to AI pricing, the term "upto" can really catch your eye. This pricing model is dynamic and metered, which means you’re not just paying a flat fee. Instead, you get charged based on how much you actually use the AI services.

What Does This Mean?

• Flexibility: You’re only paying for what you need. If your usage varies from month to month, your bill can reflect that.
• Scalability: If your needs grow, you won’t hit a wall. You can scale your use up or down, and your costs adjust accordingly.
• Cost Efficiency: You can save money if you don’t use the service as much, making it a smart choice for varying workloads.

How It Works

In a typical “upto” pricing model, you might see something like this:

• Base Rate: You start with a base cost for the first tier of usage.
• Usage Tiers: As you use more, the cost might go up at certain thresholds.
• Cap: There’s usually a limit to keep your costs from spiraling out of control, which gives you peace of mind.

Example

Let’s say you’re using an AI tool for data analysis. The pricing might look something like this:

• First 100 queries: $0.10 per query
• 100-500 queries: $0.08 per query
• Over 500 queries: $0.05 per query

So, if you end up using 450 queries in a month, your total cost would be:

(100 * 0.10) + (400 * 0.08) = $8.00

This way, you can strategize your usage and keep tabs on your spending while still getting the benefits of AI when you need it.

Dynamic, metered pricing is all about making your budget work for you while you harness the power of AI!

• Check out thirdweb’s “upto” scheme:
  • You start with verifyPayment(max) → then run inference → finally settlePayment(actual_used) up to the cap.
  • This is especially handy for LLM pricing, which changes based on the number of tokens in your prompt and response. (portal.thirdweb.com)

3) Gasless EVM Payments with USDC (EIP‑3009)

Gasless transactions are a game-changer, and with EIP-3009, using USDC has never been easier. This proposal allows users to make payments on the Ethereum network without the burden of gas fees, which can sometimes be a pain point for both users and developers alike.

How It Works

With EIP-3009, you can send USDC via transactions that are sponsored by a relayer. Essentially, this means that someone else (the relayer) covers the gas fees for the transaction. Here’s a quick rundown of how it works:

1. User initiates a transaction.
2. Relayer picks up the transaction and pays the gas fees.
3. Transaction gets executed on the Ethereum network, and the sender can focus on what really matters--getting their USDC!

This model not only simplifies user interactions but also opens up new avenues for dApps to enhance user experiences without the gas fee barrier.

Benefits of Gasless Payments

• User-Friendly: No more worries about gas fees keeping users from engaging with apps.
• Wider Adoption: Makes it easier for newcomers to jump into the world of crypto without needing to figure out gas prices.
• Incentivizes Developers: Encourages developers to create more engaging applications when users don’t have to stress about fees.

Conclusion

EIP-3009 focuses on smoothing the user journey in the Ethereum ecosystem, especially when dealing with USDC transactions. The potential for gasless payments could significantly affect how we think about transactions in the crypto space moving forward.

• The client kicks things off by signing an EIP‑712 authorization for transferWithAuthorization. Then, the facilitator goes ahead and submits receiveWithAuthorization on your contract to steer clear of front-running. Don't forget to add in validAfter, validBefore, and a unique nonce. Check out the details here: (eips.ethereum.org)

4) Multi-chain Acceptance and Back-office Unification

• Advertise accepts payments in Base (EIP‑3009) and Solana (SPL USDC).
• Combine everything into one USDC treasury address using CCTP Fast Transfer (takes just seconds!). This process burns the tokens at the source and mints them at the destination, all backed by Circle’s attestation and Fast Transfer Allowance. Check it out here: developers.circle.com

---

Agent integration patterns that just work

• MCP Tool Servers for x402
  • Anthropic’s Model Context Protocol (MCP) is here to help agents find tools more easily. By publishing an MCP server that connects to your x402 endpoints, Claude-class agents can handle pricing, payments, and data fetching without needing API keys. Just a heads-up: make sure to check the MCP security setup before you enable any write actions. (anthropic.com)
• Edge-Agent Fetch
  • You can wrap fetch with x402 in Workers or serverless agents, allowing you to use the same code for both testing and live environments. Cloudflare has some great examples of fetch wrappers and server middleware. Check it out! (developers.cloudflare.com)
• Trusted Agent Checkout
  • When it comes to consumer checkout, Visa’s Trusted Agent Protocol paired with Cloudflare Web Bot Auth helps confirm that agents are legit, making it easier to integrate with x402 for payment settlements. This results in a clearer distinction between real agents and bots, in line with the latest card-network standards. (corporate.visa.com)

---

Best‑in‑class engineering practices (learned the hard way)

Security and Correctness

• When you're working inside contracts, it's better to use receiveWithAuthorization instead of transferWithAuthorization. This approach ties the payee to the transaction and helps reduce the risk of mempool front-running. Also, make sure to enforce unique nonces for each payment and keep those validity windows tight. You can read more about it here.
• Don't just check the amounts--make sure to validate the asset and network being advertised in the accepts. If you come across unknown tokens or spoofed networks, just reject them. You can find more details here.
• It's a good practice to log and return the X-PAYMENT-RESPONSE along with the txHash. For building idempotency, consider using a hash that combines resourceUrl, nonce, and client id. More info can be found here.
• For the MCP attack surface, run the MCPSafetyScanner on your MCP servers. It’s wise to sandbox tool execution and implement allow-lists to enhance security. Check out the research here.

Reliability and Latency

• Consider using Solana for those super cheap and speedy micro-calls, while Base or Arbitrum can be great for EVM compatibility. It's a good idea to highlight both options in your accepts so clients (or your agent policy) can pick what works for them based on latency and cost SLAs. (solana.com)
• If you’re dealing with strict P99 latency budgets, don't forget to pre-warm your facilitators and keep the maxTimeoutSeconds conservative (maybe around 5-10 seconds). If things are running slow, make sure to return an error field when settlement takes too long. (github.com)
• For those times when usage spikes, try queuing "up to" payments and batch settling in one transaction where the facilitator allows it. This will help cut down on that on-chain overhead. (portal.thirdweb.com)

Treasury and Chain Abstraction

• Keep your treasury nice and tidy in native USDC with CCTP V2. Thanks to Fast Transfer, you can settle transactions in just seconds, which means you can easily rebalance to your primary chain whenever you need. Check out the details here.
• If you’re handling user funds, it’s definitely worth thinking about custodial segregation versus using omnibus accounts. Plus, you’ll want to make sure you’re doing proper reconciliation with tx hashes from X‑PAYMENT‑RESPONSE. For more on this, visit this link.
• When it comes to cross‑chain orchestration, consider using intents. If an agent needs a token that you don’t usually accept, ERC‑7683 intent flows can work their magic in the background, letting you source USDC on the right chain. You can read more about it here.

Gas and Wallet UX

• Go for smart accounts (ERC‑4337) along with Paymasters to cover gas fees. Make sure to publish whether gasSponsored is true so clients can skip those pesky ETH-balance checks. (docs.erc4337.io)
• Quick heads up: if you’re using bridged Polygon PoS USDC, it’s not EIP‑3009 compatible. It's better to stick with native USDC (on Base, Ethereum, etc.) or set up your token-specific EIP‑712 domains correctly. (web3-ethereum-defi.readthedocs.io)

Governance and Vendor Choice

• Steer clear of single-facilitator lock-in: The spec’s GET /supported lets you check out what (scheme, network) your facilitator supports on the fly. It's a good idea to have a backup facilitator just in case, and you might even want to think about running your own for those high-value routes. You can dive deeper into this here.

---

Compliance and risk: what CISOs and GCs will ask you

• U.S. Stablecoin Regime
  • The GENIUS Act, which got signed into law on July 18, 2025, outlines federal requirements for payment stablecoins. This means we can expect some serious bank-like AML and sanctions obligations, plus monthly reserve attestations for issuers. Even if you're not the issuer yourself, it's important to have solid procurement and screening policies when you're dealing with USDC on a large scale. (en.wikipedia.org)
• Sanctions Controls
  • It's crucial to screen your counterparties and the originating funds. Use OFAC SLS data feeds along with your facilitator's AML tools to help out. Remember to keep those blocklists handy and stay alert for any high-risk geographies. (home.treasury.gov)
• Programmatic Guardrails
  • Implement daily caps for each agent and set price ceilings at the route level. A lot of managed gateways let you tweak buyer policies and even provide CSV audit exports with blockchain proofs, which is super helpful for audits and compliance. (g402.ai)
• Record-Keeping
  • Make sure you keep track of the 402 accepts payload, the X-PAYMENT request header, and the receipts from your facilitator's verify/settle process. Also, record the X-PAYMENT-RESPONSE for each transaction so you have an auditable trail.

---

1. Pay-per-request API on Base + Solana featuring automatic best-path selection

• Policy:
  • If the request is under $0.02 and the latency budget is less than 600ms, let's promote Solana first, then Base.
  • If the client is using an EVM-only wallet, we'll prioritize advertising Base first.
• Treasury:
  • We’ll do a weekly CCTP sweep to Base for consolidation. (developers.circle.com)

1. LLM API charges "up to $0.05" per call

• The server sends an acceptance message with the scheme: "up to", and maxAmountRequired is set at $0.05.
• Here’s the flow: verifyPayment($0.05) → run the model → settlePayment(actual_used=$0.031). (portal.thirdweb.com)

3) Consumer Agent Checkout with Visa TAP + x402

• The agent kicks things off by browsing the retail catalog. Once they find what they want, they show the TAP intent proof. The merchant recognizes the trusted agent, and for something like a downloadable asset (think dataset), the merchant responds with a 402 status. The agent then makes the payment using USDC via x402, and after that, they get a fulfillment link that sends back a 200 status. Just to clarify, TAP holds the agent’s identity, while x402 manages the payment process. (corporate.visa.com)

---

Selecting your facilitator: decision matrix

• Coinbase x402 Facilitator
  • Pros: It’s a solid reference implementation with good alignment to specs, plus a pretty straightforward verify/settle API.
  • Cons: You’ll have to manage your own infrastructure, and keep in mind that the roadmap changes as the spec evolves. (docs.cdp.coinbase.com)
• Thirdweb Facilitator
  • Pros: This one’s great because it supports over 170 EVM chains and includes features like ERC‑2612/3009, EIP‑7702 gasless, and dynamic “up to” pricing. Plus, their dashboards are pretty much ready to go.
  • Cons: Just a heads-up, there’s a platform fee, and you’ll want to make sure it fits your service level agreement (SLA). (portal.thirdweb.com)
• Roll-your-own
  • Pros: You get complete control here, which is a big plus if you want to integrate CCTP and manage your internal risk engines.
  • Cons: Be prepared for an on-call burden and some compliance engineering hurdles.

Emerging

Circle is diving into a “deferred” scheme and looking into Gateway-based micropayments for x402. Keep an eye on this if you're after instant experiences with post-facto net settlement. You can check out more details here.

---

KPIs to track from day one

• Payment Success Rate: Check that verify pass to settle success percentage.
• P95 End-to-End Latency: Measure the time from request to 200 OK by network. Keep an eye on how Solana and Base compare as fees and traffic change. (solana.com)
• Chargeback Analogs: Look at disputed or refunded transactions against revenue; let’s create some clear playbooks for handling internal refunds.
• Treasury Fragmentation: Keep track of the percentage of USDC that’s off the primary chain. We’re aiming to get that below 10% before the CCTP sweep. (developers.circle.com)
• Agent Budget Violations: Make sure our policy engine is preventing any budget violations.

---

Common pitfalls and how to avoid them

• “Why did my signed EIP‑3009 transaction fail on Polygon PoS USDC?” Well, it turns out that the bridged USDC in that chain doesn’t match the standard EIP‑3009 domains. Your best bet is to either stick with native USDC or tweak your EIP‑712 fields a bit. Check out more here.
• “We noticed some double-spend attempts.” To tackle that, you might want to tighten up those validBefore windows. Also, consider binding nonces to the resource, doing some verification on the facilitator before jumping into work, and including a resourceUrl hash in your settlement memo for audit purposes. You can dive deeper into this over at GitHub.
• “Agents can’t pay gas.” A couple of ways to handle this: you can use Paymasters and set gasSponsored: true in your payment requirements. Alternatively, you could reroute those transactions to Solana, where only the token balances come into play. More details are available here.
• “Our finance team is having trouble reconciling.” To make their lives easier, try storing the full 402/headers and mapping txHash to invoice ID. It could also help to export a daily CSV with on-chain proofs--most managed gateways can handle this. For further insights, head over to g402.ai.

---

Build sheet: your first 30-60-90 days

• Days 1-30
  • Choose two networks--Base and Solana. Then, add x402 middleware and publish accepts for both. Make sure to wrap the agent fetch with x402. You can find more info here.
  • Set up a facilitator, whether managed or self-hosted, and connect verify/settle. Check out the details here.
  • Create a CCTP Fast Transfer job to regularly sweep the treasury each week. More on that can be found here.
• Days 31-60
  • Transition LLM endpoints to “upto” pricing and set budget caps for each buyer. Get a glimpse of this here.
  • Integrate a Paymaster to cover gas for EVM agents and run some A/B tests to check for any improvements in acceptance. Details are available here.
  • Launch an MCP server that showcases your paid routes and do a pentest using MCPSafetyScanner. You can find out more about this here.
• Days 61-90
  • Implement Visa TAP/Web Bot Auth at your consumer checkout to allow verified agents without compromising bot defenses. Also, make sure to document how TAP and x402 work together in your SRE runbooks. More information can be found here.
  • Expand accepts to Arbitrum as a backup for EVM, and test intent-based routing for token swaps using ERC-7683-compatible relayers. Info is available here.

---

What 7Block Labs recommends right now

• Kick things off with a dual-rail acceptance policy (Base + Solana) and allow agents to choose their preferred chain. Don’t forget to track latency and error modes for each chain every week. (solana.com)
• For AI inference, let’s switch to “upto” billing right away; this aligns perfectly with per-token spending and helps clear up any overcharge disputes. (portal.thirdweb.com)
• Keep your treasury “USDC-native” and synced up with CCTP V2; it’s honestly the best chain abstraction you can get right now. (developers.circle.com)
• Strengthen your MCP surface and use Visa TAP wherever consumer agents show up, so we can ensure that security and payments work seamlessly together. (arxiv.org)

---

The bigger picture

We're seeing the convergence of two key standards: x402 for machine-readable, HTTP-native payments and TAP/Web Bot Auth for building trust with agents at checkout. When you throw in chain abstraction (like CCTP, intents, and gas abstraction), it paves the way for a “clickless” commerce experience. This means agents can purchase data, compute, and content in just seconds--without your users needing to choose a blockchain or deal with gas fees at all.

x402 is already out there in open source (check out the specs and facilitator APIs)! Cloudflare and Solana have got their own first-party docs ready to go. Plus, we’re seeing a solid uptick in daily transaction counts and more facilitators joining the game. Those go-to patterns like “upto” are solidifying really quickly. If you get on board now, you'll be able to convert more agent traffic, accurately meter costs, and finally stop offering premium APIs for free. Check it out here: (github.com)

---

Footnotes and sources worth bookmarking

• Coinbase just rolled out their x402 launch on May 6, 2025, along with some cool partners. They also shared an open-source spec complete with headers and a verify/settle API. Check it out on their site! (coinbase.com)
• Cloudflare has introduced Agents paired with x402 wrappers for Workers. Want to learn more? Head over to their dev site! (developers.cloudflare.com)
• If you’re diving into Solana, they’ve put together a handy guide on x402 that breaks down finality, costs, and the ecosystem's momentum. Don't miss it! (solana.com)
• Thirdweb is stepping up the game with a facilitator and a dynamic “upto” scheme for AI billing. You can find all the details here. (portal.thirdweb.com)
• Ever heard of ERC‑4337? It’s all about Paymasters (gas abstraction) and smart accounts. Get the lowdown through their docs. (docs.erc4337.io)
• EIP‑3009 is here, focusing on USDC authorizations and some implementation quirks you might want to be aware of. Check out the details. (eips.ethereum.org)
• Circle’s CCTP V2 is super cool with Fast Transfer and hooks that make USDC moves happen in just seconds. Learn more about it! (developers.circle.com)
• Looking into cross-chain functionality? ERC‑7683 is the standard for cross-chain intents that handles the behind-the-scenes routing. Get the scoop from Uniswap's blog. (blog.uniswap.org)
• Lastly, Visa’s rolled out their Trusted Agent Protocol with Cloudflare’s Web Bot Auth and is working on interoperability with x402. Check out the announcement! (corporate.visa.com)

Need a little extra support? 7Block Labs can get you set up with a dual-rail x402 gateway, connect CCTP and an intents router, and have your first paid agent call up and running in less than two weeks. After that, we'll make sure everything's solid for scaling and auditing.