x402 Gets You the Protocol. Here's What It Doesn't Get You.

Zuplo's guide on MCP payments with x402 nails the transport layer. Agent sends a request, gets a 402, pays, retries — clean. But the guide stops exactly where most production deployments start to hurt.

The real problem isn't the payment itself. It's authorization. When an unknown agent hits your MCP server, you don't know if it can be trusted to spend, how much it should be allowed to spend, or whether it'll disappear after one session without settling. x402 moves money. It doesn't underwrite risk.

Three gaps x402 leaves open:

Spend limits with expiry. x402 has no native concept of a scoped token with a hard cap and a time window. You can enforce this at the API layer, but you're building that logic yourself.

Agent identity across sessions. If the same agent hits you from a different IP tomorrow, x402 gives you no continuity of trust. You're starting from zero again.

The unknown-agent problem. Human SaaS has credit cards and chargeback rails. Agents don't have credit histories. You have no signal on whether to let a first-time caller spend $50 or $50K — so most teams default to either open (risky) or manual whitelist (kills the whole autonomous-payment premise).

MnemoPay ships an Agent-FICO SDK — a 300-850 credit model for agent sessions. An agent builds a score across calls: on-time settlement, spend patterns, session continuity. You gate spend limits to the score. A new agent starts at 300 and earns access; a trusted agent gets a higher ceiling without a human approving it.

672 tests, v1.0.0-beta.1 in production, 1.4K weekly npm downloads. If you're building on x402 and want to add the underwriting layer: https://mnemopay.com