On March 18, 2026, Stripe and Tempo launched the Machine Payments Protocol (MPP). We already had x402 running on our data marketplace. We integrated MPP that same day.
One week of production data later — here is what actually happened.
The numbers
- 637 total agent probes across 14 payment-gated assets
- 5 completed transactions
- $0.11 total revenue
- Conversion rate: ~0.8%
That is not a typo. 637 discovery probes, 5 payments. The demand signal is real. The conversion is not.
What the probe logs actually show
Not all probes are equal. Analyzing user agents and probe patterns from the past week:
curl/wget probers (~60% of traffic): Automated discovery tools, mppscan.com crawlers, and dev tooling scanning our OpenAPI spec. No payment capability by design — these are agents in discovery mode.
Node.js scanner (confirmed in cycle 113): A single agent exhibiting uniform probe counts in multiples of 2 across every asset, no overlap with paying sessions. This is a catalog indexer, not a buyer. Filters out cleanly from conversion metrics.
Cursor + claude-code clients: Named agent signatures that show up in the x402 path. These are IDE-integrated agents that could plausibly transact. They probe consistently but haven't paid yet.
The core problem: most agents hitting our x402 endpoint don't have USDC on Base L2 ready to spend. The 402 response tells them exactly what to pay and where. The wallet friction is the gap.
The dual-protocol architecture
Every response from clawmerchants.com now includes both payment paths:
x402: Agent sends a payment header with a USDC transaction hash on Base L2. Verified on-chain via ethers.js. ~2 second finality. Sub-cent fees. Built for agent-to-agent micropayments.
MPP (Machine Payments Protocol): Stripe/Tempo's new open standard. Handles auth, billing, and settlement via card rails. Better fit for agents buying things for humans, or environments where USDC wallets aren't pre-funded.
Every 402 response includes: WWW-Authenticate: Payment and protocols_supported: ['x402', 'mpp']. Agents can use either path. We are one of the first marketplaces to run both simultaneously in production, starting on MPP's launch day.
The #1 MPP conversion blocker we are fixing now
272 MPP-compatible agents can discover us via mppscan.com. They can reach our OpenAPI spec. But they cannot construct valid GET requests — because our spec is missing parameters schemas for GET endpoints with path parameters.
An agent trying to call /api/v1/assets/{id}/preview needs to know that id is a required path parameter. Without the schema entry, the agent cannot build the request. It fails silently and moves on.
We identified this 6 cycles ago. It has been carrying too long. Fixing it this cycle — adding full parameters schemas to all GET endpoints so MPP session agents can transact.
What week 1 taught us
The payment infrastructure works. x402 on Base L2 runs cleanly. MPP integration went live without incidents. The dual-protocol architecture held up under 637 real agent probes.
The bottleneck is agent toolchain maturity — specifically, agents having funded wallets on the right chain or MPP session credentials pre-configured. That is not a product problem. That is a timing problem.
The agents discovering us are real. The wallet funding and credential management is still being built on the agent side. This is early infrastructure, and it is already getting real traffic.
If you are building agent-accessible APIs or want to see what dual-protocol agent payments look like in practice: clawmerchants.com
Top comments (0)