x402 or a card: picking a rail for your agent

x402 is a good idea and I want to say that up front because I built the thing that competes with it. The pitch is simple, a server answers a request with HTTP 402, the agent pays in USDC, the server delivers. Pay per request, no accounts, no invoices, settlement on-chain. For machines paying machines it's about as clean a protocol as you could draw on a whiteboard.

The catch is in the word USDC. Every agent in the system has to hold a stablecoin, which means every operator behind those agents has to acquire one, custody it, and explain it to their finance team. If you're already living on-chain that's nothing. If your business runs in dollars, euros and pounds through a bank, it's a whole new department.

The same idea, funded by a card

txn.dev is the same shape with a different floor under it. Agents get wallets, wallets get funded by card through Stripe, transfers between wallets are a single database transaction on a double-entry ledger. Sub-cent amounts work because the ledger stores eight decimal places. Retries are safe because every transfer carries an idempotency key. Nobody holds a token, and money leaves the system the way it came in, to a bank account.

That last part is where the two really diverge. On x402 the value is already on-chain and stays there. On txn.dev, txn.dev is the merchant of record, the card payments sit in a Stripe balance, and the ledger is the record of whose money that is. It's a custodial model, and I'm not going to dress that up. You're trusting a company to keep the ledger and the balance in agreement, which is exactly what you do with every marketplace you've ever sold on.

When I'd pick which

If both sides of a payment already hold USDC and you want an open protocol with no company in the middle, x402. Genuinely. It's the better fit and pretending otherwise would be silly.

If either side is a normal business with a bank account, or if the thing being paid for is a person rather than an API, a card-funded ledger is the one that doesn't require anyone to learn anything. Hiring a human is the clearest case, a notary in Lisbon wants euros in her account, not a token she has to swap.

There's also the boring case, which is most cases. An agent paying another agent inside the same company, or between two companies that already invoice each other. Nobody there is asking for a chain, they're asking for it to be fast, correct, and to show up on a statement.

Both, eventually

The SDK is deliberately shaped so that the rail underneath can change. A transfer is pay({ from, to, amount, idempotency_key }) and nothing in that call knows whether the settlement is a Postgres row or an on-chain transfer. Routing the same call over x402 when both wallets have USDC is on the roadmap, so one integration could settle either way depending on what the counterparty holds.

Until then the choice is mostly about who's on the other end. If it's a machine holding crypto, use the protocol built for that. If it's anyone else, use the one that ends in a bank account.