Is there a way to add x402 to an existing API without code? Yes — here is the walkthrough

Payzum is a non-custodial, stablecoin-first crypto payment processor: payments settle directly to wallets the merchant controls. For x402 that means the USDC an agent pays for one call lands at the Base address you configure, not in a Payzum balance. This guide is the click-by-click version of that setup: what you need before you start, the five fields that matter, how to test it for free, and what to check before you charge real money.

Can you add x402 payments to an existing API without writing code?

Yes, if you put a proxy in front of the API instead of changing the API. x402 is an open protocol that gives the HTTP 402 Payment Required status a concrete meaning: the server answers an unpaid request with a price, the client signs a stablecoin payment and retries, and the server returns the data. Someone has to speak that protocol. The question is whether it is your service or a layer in front of it.

With Payzum it is the layer in front. You publish one extra, priced door to the endpoint you already run. Existing customers keep calling your API exactly as before; agents call the x402 URL, get a 402 with your price, pay, and receive your origin's response unchanged. The configuration lives in the merchant dashboard, which is why an API provider can start serving agents the same day. The role split is worth stating plainly, because vendors blur it:

Payzum is not the facilitator. Becoming one is a future ambition, not a claim about today. The x402 docs describe the facilitator as the service that verifies payment payloads and settles them on the blockchain, and they are explicit that it "does not hold funds or act as a custodian" (docs.x402.org, Facilitator page, checked 20 October 2026).

Why adding x402 yourself is still a project

The honest baseline is the official seller quickstart. As of 20 October 2026 it asks you to install the x402 packages for your framework (the Express, Next.js, Hono and Fastify middleware, Go modules for Gin and Echo, or the Python package for FastAPI and Flask), point the middleware at a facilitator, list the routes you want to protect and supply your receiving wallet address. It is good documentation and a reasonable afternoon for a team that owns its codebase. It is also a change to your service, with a deploy, a review and a rollback plan.

Two details in the same docs matter for production. The public x402.org facilitator used in the quickstart works on Base Sepolia and Solana devnet only, and the docs warn that it is for development and testnet workflows, not mainnet. For mainnet you need a production facilitator, your own, or self-facilitation. In practice that means opening an account with a provider and keeping its credentials in your service's configuration. Coinbase's hosted CDP Facilitator, for example, authenticates with your CDP API key ID and secret (CDP docs, checked 20 October 2026).

What it costs you to wait for a code change

The cost is rarely the afternoon. It is the queue. Many of the APIs worth selling to agents sit in places where a middleware change is not a quick edit: a vendor-hosted product you configure but cannot patch, a legacy service nobody wants to redeploy, a monorepo with a release train, an API owned by a different team than the one that wants the revenue. The x402 idea then dies at the first planning meeting, before anyone has learned whether a single agent would pay.

That matters because the demand side is still uncertain. Bitquery's audit of 2026 x402 payments, which we covered in the first x402 audit, found that the median seller on Base earned about $2.50 a month. A small, reversible experiment is the right shape for that market: one route, one price, one toggle to turn it off. A project is the wrong shape.

Why the usual routes are heavier than they look

There are three common ways to get x402 in front of an API, and each carries a cost that is easy to miss.

• Write the middleware in your service. Full control, and it is the reference path in the docs. You own the facilitator integration, the route table, the key handling and every upgrade as the spec moves (x402 has already had a V1 to V2 migration).
• Build your own gateway or edge function. No service change, but you now run, monitor and secure a new component that sits in the money path.
• Use a platform that settles to its own balance. Quick to start, but the revenue sits with the platform until a payout, which is the custody model most API businesses wanted to leave behind.

A configuration-only proxy that settles to your own address removes all three: no code in your service, no gateway for you to operate, and no balance in the middle. If you want the wider picture of who does what in the ecosystem first, read the x402 ecosystem map.

How Payzum adds x402 without touching your API

Payzum keeps a mapping between a public x402 URL and your private endpoint. When an agent calls the public URL without paying, Payzum answers 402 Payment Required with the exact price. When the agent retries with a signed payment, Payzum validates it through the external facilitator, then forwards the request to your origin with your credential attached and returns the response. Your service handles the call like any other request.

# 1 — the agent asks (unpaid)
GET /v1/x402/pzm_yourmerchant/market-data

# 2 — Payzum answers with the challenge
HTTP/1.1 402 Payment Required
→ price: 0.01 USDC · network: base · asset: USDC

# 3 — the agent signs a USDC authorization and retries
GET /v1/x402/pzm_yourmerchant/market-data
(signed payment attached)

# 4 — verified through the facilitator, proxied to your origin
HTTP/1.1 200 OK     ← your origin's response, unchanged

The asset is USDC on Base mainnet, an ERC-20 with six decimals, so a price of 0.01 USDC is exactly one cent and a price of 0.001 USDC is still a real payment. The agent signs an EIP-3009 transfer authorization instead of broadcasting a transaction itself, which is what makes a fraction-of-a-cent call practical. Base confirms in roughly two seconds, and the payment is final once it settles: no chargebacks, no card network deciding whether the money is yours.

How to add x402 to your API, step by step

Everything below is dashboard configuration. Allow about 20 minutes for the first route, most of it spent on the facilitator account if you do not have one yet.

Before you start

• An endpoint reachable over HTTPS from the public internet. This is the "origin": the URL Payzum will forward paid calls to.
• The credential your origin expects, if any: an API key or a bearer token. If the endpoint is currently open, create a key for it first (see step 3).
• A Base address you control that will receive the USDC.
• For mainnet, your own facilitator account. Payzum calls an external facilitator, currently Coinbase's, with credentials you supply. For testing you can skip this and use the free testnet setting.

1. Create the route

In the merchant dashboard open API for Agents and add a new endpoint. Give it a path: the last segment of the public URL agents will call, such as market-data. One merchant can run many routes, so name them by what they sell.

2. Point it at the API you already run

Enter the API URL, the HTTPS endpoint Payzum should forward paid calls to. This is your existing service, unchanged. Payzum does not move your API; it publishes an additional, priced door to it.

3. Store your origin credential

If your API authenticates callers, add the API key or bearer token against the route. It is stored encrypted and injected when Payzum forwards a paid call, so your service authenticates the request exactly as it does today and the agent never sees the secret. If your endpoint is open today, this is the moment to put a key on it. Otherwise anyone who knows the origin URL can skip the paywall by calling it directly.

4. Set the price per call

Enter the price in USDC for one call. You can set different prices on different routes, so a cheap lookup and an expensive screening can sit side by side. Price against the value of the answer to the caller, and keep the fixed cost of each payment in mind: our analysis of the price floor for machine-to-machine payments explains why a route priced below the cost of settling it cannot work.

5. Set the Base address that receives the money

Enter the Base address where USDC should land. Payments settle to this address through your own facilitator account. Payzum verifies and proxies; it never takes custody, never batches your revenue and runs no payout schedule you have to wait on.

6. Choose how it settles: testnet first, then mainnet

Open the settlement settings. The testnet option settles on Base Sepolia through a public facilitator, for free: same handshake, same wiring, no real USDC. The mainnet option connects your own Coinbase Developer Platform key, so real USDC settles on Base and the per-transaction cost and gas are billed to that same account, the one that receives the money. Start on testnet.

7. Flip the route live and copy the URL

Switch the route to Live. Payzum publishes the public x402 URL, and that string is the whole integration on the buyer's side. Call it without paying and confirm that you get a 402 that shows your price, network and asset. Then run one paid call from an x402-capable client against testnet and confirm your origin returns its normal response.

8. Optional: make it discoverable

Mark the endpoint as discoverable to list it in the discovery catalog. When you settle through the Coinbase facilitator, that metadata is also published to the x402 Bazaar. Keep expectations calibrated: the x402 docs describe the Bazaar as being in early development, "more like Yahoo search" than Google, with features and APIs that may change (docs.x402.org, Bazaar page, checked 20 October 2026).

What to check before you charge real money

• The origin refuses unauthenticated calls. Call the origin URL directly with no key. If it answers 200, the paywall can be bypassed.
• The price covers the cost of a payment. The facilitator charges per on-chain transaction after a free tier (see the numbers section below), and gas is paid on Base.
• The response is the same on both doors. Compare a direct call and a proxied one. They should match, apart from the payment step.
• You can turn it off. Toggle the route off and confirm agents get a clean failure while your direct customers see nothing change.

Who adds x402 this way: use cases

The pattern is a bounded answer, valuable at the moment it is requested, sold by someone who would rather not rebuild their billing stack to find out whether agents will pay.

• A compliance-data vendor with a closed codebase. The sanctions-screening API runs on infrastructure the team configures but does not patch. They expose one route at ten cents, keep their existing key on the origin and leave their enterprise contracts alone.
• An enrichment API with a free tier that gets scraped. Geo and IP lookups are sub-cent answers. A per-call route gives high-volume machine callers a way to pay without a signup, while human developers keep using the keyed plans.
• A small team with an MCP server or tool endpoint. Any HTTP-reachable endpoint can sit behind a route. See how to monetize an MCP server with x402 for the tool-specific version.
• An agency running several client APIs. One merchant, several routes at different prices, each with its own origin credential. A client's price change is an edit, not a release.

Add x402 with Payzum vs build it yourself — comparison

The numbers to know before you start

Three dated facts frame the economics. First, the facilitator side: the first 1,000 on-chain transactions each month on the CDP Facilitator are free, then each additional on-chain transaction costs $0.001, and payment verification is always free (CDP docs, checked 20 October 2026). Second, the track record: the same page says the facilitator has processed more than 100 million transactions and $28 million in payment volume across Base and Solana. Third, the buyer side is young: in the Bitquery audit mentioned above, the median Base seller earned about $2.50 a month, so treat the first route as an experiment with a cap on effort, not a revenue line.

On the Payzum side, the facilitator cost and gas are billed to the facilitator account you connect, the same account that receives the USDC. For Payzum's own pricing on x402 routes, confirm the current figures on a call rather than relying on any number in a blog post. For the full pay-per-call picture, including how it compares with API-key billing, see x402 pay per API call and the x402 product page.

Common objections

"I don't want a proxy in front of my API."

You are not moving your API. You are adding a second, priced door to it. Your existing traffic never touches Payzum, and turning the x402 route off is a toggle, not a rollback.

"What stops someone from calling my origin directly?"

Your origin's own authentication, which is why step 3 matters. The x402 route is the only place an agent can buy a call without an account. Everything else still needs the key, exactly as before.

"I'd have to hold crypto."

You receive USDC, which tracks the dollar, at an address you control on Base. What you do with it afterwards is your decision, and nothing is held by Payzum in the meantime. That is the non-custodial model described in our guide to non-custodial processors.

"There aren't enough agents paying yet."

Possibly true for your niche today. The cost of finding out is one dashboard entry and no code, and the endpoint you already run keeps serving its existing customers as before.