How to Get Started Accepting Agent Payments

If you were to post a sticker on your wall for every payment method you accept, how many stickers would you have?

Now flip the question: how many stickers would you need to accept payments from AI agents? Every network, wallet and processor is publishing its own way for an agent to pay, each with its own credential, agentic protocol, and rules. To be reachable by any agent, a merchant would need all of them.

That’s a lot of stickers.

Accepting agent payments is the latest hurdle within the payments industry as it adopts agentic commerce. Protocols are being released, and payments are moving faster than ever, via real-time, same-day, stablecoins and crypto.

But the infrastructure to accept agent payments safely is still in its infancy.

What questions should I ask before accepting agent payments? 

It's worth being precise about what agent payments actually are. Tempting as it is to picture a chatbot buying a product, the boundaries are broader because agent-initiated payments are already in production today.

Small usage-triggered transactions like an agent paying for an API call, back-office payments where an agent settles invoices with no storefront involved, and outright data purchases where an agent pays for access to information rather than a good. And most machine-to-machine payment volume right now is not AI-driven at all; it is B2B stablecoin settlement.

The plumbing is already carrying money at scale. Agents are the catalyst for what comes next, and while volumes are still low for merchants selling to consumers, the wave is approaching fast.

Before enabling agent payments, ask these questions if you can (or stop and consider these if you’re mid-implementation:)

• Which rails and protocols will agents use to pay me? Card networks, wallets, processors, and crypto protocols have each shipped one. They deliver different credentials to your checkout, and some of them look exactly like a human paying.

• How do I know the person was actually authorized to make this purchase, and by whom? An agent can be manipulated by a prompt injection or hallucinate a detail. Either way the payment goes through, you get paid, and then the dispute arrives.

• Who is liable when the cardholder says, "I didn't authorize that"?

• What if the agent's credentials are stolen? Agent identity and cardholder identity are not the same thing.

• Is this order compliant in the market it came from? An agent acting for a consumer in Europe carries different regulatory and currency obligations than one acting for a consumer in the United States.
• Do I know the risk profile of each rail I accept? A card transaction comes with network dispute rules. A stablecoin settlement is final the moment it lands.

Return to Top

How does an agent get permission to pay? 

Every serious agentic protocol answers the authorization question the same way, under different names. The human does not approve each purchase. The human approves a mandate once, and every credential the agent later presents is bound to it.

• A ceiling, not a price. The consumer authorizes up to an amount, in a currency, for a period. The networks call it a purchase instruction; within the Basis Theory API it is an allowance on a payment method.
• A merchant, or a policy about merchants. Most mandates name where the money can go. Some let the agent choose within limits, which is what makes an open-ended shopping task possible.
• A ceremony the consumer completes. A passkey, a one-time code, a hosted authentication step, or an approval in the wallet's own app. The agent cannot do this on the consumer's behalf, which is the whole point.
• A credential scoped to the mandate. Once approved, each credential the agent presents is minted against it and burns it down as it is spent. Present it twice and the second attempt fails at the network, not at your fraud rules.

Here is the part that matters for a merchant. Depending on the rail, that credential can be a network token with an agent indicator on it, or it can be an ordinary-looking one-time card the agent types into your existing form. In the second case your checkout sees a human. Nothing on the order says an agent placed it. You will find out when the cardholder disputes it, and at that moment the only thing that helps you is the record of the consumer completing the ceremony that approved a mandate covering this purchase.

That record is the human's signature on the agent's purchase. It is created by the network or the wallet, not by the agent, which is what makes it worth something.

Return to Top

Who is liable when it goes wrong? 

This is the question that keeps merchants from turning agent payments on, so it deserves a straight answer.

For card rails, the rules that apply to a tokenized card transaction apply to an agent-initiated one too. An agent payment over a card network is a card transaction with an extra authorization step behind it. When the cardholder disputes it, the evidence you bring is the same class you bring today, plus one thing you did not have before: the consumer's approval of the mandate, recorded by the network.

For stablecoin rails, there is no dispute process. Settlement is final. The mandate lives on the agent's side, so ask what it was before you accept.

Merchant of Record rules for traditional e-commerce are well understood. Nobody has fully written them for agents, and the honest position is that the networks are defining liability rail by rail as volume arrives. Keep the mandate reference on every order, and you will be holding the evidence, whatever the rules turn out to be.

Return to Top

How do I get started accepting agent payments? 

Ask your processor what it does with an agent-presented credential today. Some flag tokenized transactions that carry agent indicators. Some pass wallet tokens straight through. Some decline an unfamiliar token type. You need to know which you are, because it decides whether your first agent order succeeds, fails, or succeeds silently with no marker at all.

Store the mandate reference with the order. When an agent presents a credential, it can also present the identifiers behind it: the mandate, the transaction reference, and the consumer identity the mandate was granted for. Capture them the way you capture an authorization code.

Decide your policy for agent orders before the first one lands. Do you accept them at all? Only under a certain amount? Only from mandates that name your store? A policy written in advance is one your risk team can enforce. One written after the first chargeback is a guess.

Rehearse the dispute. Take a test order through a sandbox, then pretend the cardholder disputed it. Can you produce the mandate, the approval record and the credential reference from your own systems, without calling anyone? If not, go back to step two.

IMPORTANT: Don't let one processor own your tokens. If you're on a single processor that doesn't support agent payment protocols, you're stuck. And the protocols are fragmenting, not converging: networks, wallets, processors and crypto rails are all live and none will be going away any time soon.

An independent vault keeps your payment credentials portable, and an orchestration layer manages compliance, transaction risk and payment operations across whichever rail an order arrives on.

This cuts both ways. Agents face the same fragmentation merchants do, mirrored: to pay anyone, anywhere, they need to reach whatever rail a merchant requires. A layer that consolidates credentials, rails and protocols is what both sides will end up building on.

Basis Theory is that layer.

Card credentials are tokenized once within a vault, and stay portable across processors. Our agentic API turns a vaulted card, or a consumer's connected wallet, into one payment method with an allowance on it: an amount, a merchant policy, an expiry, and the ceremony that makes the consumer's approval real.

From that one allowance the agent mints whichever credential the order needs, and every credential carries references back to the allowance, so the evidence in step two is on the order from the start.

Agent payments are already in production, and the protocol wars are happening. Building on agnostic infrastructure lets you adopt whatever agentic protocol wins. The vault is the hedge: own your tokens, stay processor-agnostic, keep the mandate on every order, and plug into whatever standard emerges.

Return to Top