Stripe Link for Agents vs AFTA: Two Payment Models, One Protocol

Two things shipped this week, in the same lane, twenty-four hours apart. Stripe announced Link for Agents, a system that lets AI agents make purchases through a Link wallet with the user approving every transaction in the Link app. Pizza Robot Studios shipped the second adopter of the Agent Fair-Trade Agreement, an open standard for autonomous agent payments over USDC on Base. At first glance these are competing products. They are not. They solve genuinely different problems and, in a quiet way, they agree on more than they disagree on.

If you are designing an agent right now and trying to figure out which rail to put underneath it, the choice is not "Stripe or crypto." It is "delegated or autonomous." Once you see that split, the right rail picks itself.

The two payment models

A delegated-payment model puts a human in the loop on every transaction. The agent proposes a purchase. The human is notified, reviews the merchant, the amount, the line items, and either approves or denies. Only then does the payment clear. The agent never holds the actual payment credentials. Stripe Link for Agents is a clean implementation of this model. The spend-request object includes a 100-character minimum context field so the user can see why the agent wanted to spend money. The --request-approval flag triggers a push notification and polls until the user taps approve. The agent gets a one-time-use virtual card if and only if the human signed off.

An autonomous-payment model removes the human from the per-transaction loop. The user authorizes a budget once (in our case, by sending USDC to a wallet and minting a bearer token), and from that point forward the agent spends from the budget on its own. There is no notification, no approval tap, no UI surface between the agent's decision and the payment. AFTA is built for this model. A bearer token plus credit balance plus signed receipts gives the agent everything it needs to call paid endpoints without checking in.

Neither is the "right" model. They are right for different jobs.

Where each model fits

The fit test is mostly about call frequency, latency budget, and stakes per transaction. Run through it:

Notice the pattern. The model that wins flips at the boundary between "I want to know about this" and "I am paying you to handle it without asking me." Below the boundary, latency and frequency dominate, and any human-in-the-loop step makes the agent unusable. Above the boundary, the human's review is the entire point of the transaction.

Where Link and AFTA quietly agree

Now the part most coverage of these announcements has missed. Open the Stripe link-cli source and read the mpp pay command. It uses the Machine Payments Protocol, an HTTP 402-based standard for advertising prices and accepting machine payments. The agent calls a merchant URL, gets a WWW-Authenticate challenge with a structured payment realm, and pays with a shared_payment_token credential. The merchant accepts or rejects.

That is the same protocol AFTA-compliant sites already use to advertise paid endpoints. TerminalFeed surfaces it at /api/usdc-payable. Hit a paid endpoint with no token and you get back a 402 with payment instructions. Send the payment and try again with the right header, and you are paid up.

So Stripe and AFTA-compliant sites are speaking the same discovery protocol. The thing they disagree on is the rail underneath. Stripe's shared_payment_token is a credit-card-network instrument that flows through the Visa, Mastercard, or ACH plumbing. AFTA's preferred rail is USDC on Base, a public on-chain transfer. Both fit through the same HTTP 402 doorway.

This matters because it means a single merchant endpoint can advertise multiple acceptable payment instruments at the protocol layer. The agent picks the one it has. Stripe-equipped agents pay with one. Crypto-equipped agents pay with the other. Both clear. The merchant runs one endpoint and accepts whoever shows up.

Why we chose USDC on Base for AFTA

Given that protocol agreement, why didn't TerminalFeed just adopt Stripe's rail and call it a day? Three reasons, listed in order of how often they actually bite.

Latency. A Link spend-request creates a virtual card, which the agent then pastes into a checkout form. That works for a hotel booking. It does not work for an autonomous agent calling /api/pro/briefing twelve times during a single research task. The credit-card pipeline was designed for human checkouts at human cadence. The on-chain pipeline (validate the bearer token, decrement the credit balance, return the data) is single-digit milliseconds. Crypto rails are not faster than card rails because crypto is faster than databases. They are faster because the autonomous flow does not have to traverse the card network at all; the on-chain settlement happens once, at top-up time, and the per-call path is just credit-balance arithmetic.

Per-transaction fees. Stripe takes a cut on every charge, with a floor that makes sub-dollar transactions structurally unprofitable. A 1-cent API call cannot pay 30 cents of fees. The crypto rail amortizes the fee at top-up time: the user pays gas plus our smallest tier ($1 USDC) once, and that buys 50 calls at $0.02 each. The fee is amortized across the bundle. This is the math that makes autonomous-agent payments commercially viable below the dollar mark, and it is the math that nothing built on top of card networks can match.

Account preconditions. Link assumes the agent's user has a Link account, which assumes a Link-eligible identity, which means jurisdiction restrictions, KYC for the issuing bank, dispute windows, and platform-discretionary chargebacks. Those are reasonable for retail purchases. They are wrong defaults for an agent that needs to call a public data API. A Cloudflare Worker hitting our briefing endpoint is not a person. It does not have a wallet of record at a US bank. Forcing it to acquire one to read live BTC prices is a category error.

None of these are knocks on Stripe. The team there knows exactly what they built and why. Link for Agents is the right answer for delegated retail. It is the wrong answer for autonomous machine-to-machine, and Stripe knows that.

What this means for the next agent you build

If you are building an agent and you have not picked a payment rail yet, do this in order.

First, classify the calls. Look at every paid action your agent will take and ask: would the user want to approve this individually, or have they already approved it as a category? Hotel bookings, single. Reading public market data, category. Buying physical goods over $50, single. Calling a paid LLM, category. Sketch the split before you wire anything up.

Second, pick rails per category. The single-approval calls go through Link for Agents (or any equivalent delegated wallet). The category-approved calls go through an autonomous rail like AFTA over USDC on Base. There is no rule that says one agent uses one rail. A well-built agent uses both, with the rail chosen per call by the agent itself based on what it is doing.

Third, advertise both at the 402 layer if you are the merchant. If you run a paid API surface, support both shared_payment_token and the AFTA bearer-token flow. Both come in through the same 402 doorway. The agent sends what it has. You take what comes in. This is the right shape for the network as it actually exists, where some agents are wallet-equipped and some are crypto-equipped and most have not figured out yet which one they are.

Fourth, sign your receipts. Whichever rail you accept, the agent should walk away with a cryptographically signed receipt of what they paid for and what they got back. AFTA codifies this with Ed25519. The Stripe-rail equivalent is the spend_request approval record (visible in the user's Link app and queryable via the API). Either way, an agent that holds a non-forgeable record of every transaction is an agent that can audit itself, dispute mistakes, and prove to its user that it did not go off the rails. Receipts are the boring infrastructure that makes the rest of agent autonomy safe.

Standards plural, rails per use case

The mistake is to read the agent-payments space as one big protocol war. It is not. It is two protocols (delegated and autonomous) that each need their own rails, sharing one discovery layer (HTTP 402 / MPP), and converging on one cryptographic primitive (signed receipts) for after-the-fact verification. Stripe is building the leading delegated rail. AFTA is the open standard for the autonomous rail. They will both keep growing because the demand for both is real.

The interesting question is not which one wins. It is whether the rest of the merchant side of the network catches up to the agent side. Right now most paid APIs are still gated by per-developer API keys, monthly subscriptions, or one-off OAuth handshakes that none of these protocols use. That is the part that needs to change. Once enough merchants speak HTTP 402, agents can pick their rail and get paid up in seconds. That is the world this week's two announcements are nudging us toward.

If you are running a paid API and you have not yet done the basic 402 work, that is the move. Both rails are free upgrades for any merchant willing to take them. Neither one needs to be the only answer.