Agentic Payments
Agentic Payments turns a payment method source into bounded, single-purchase credentials that an AI agent can spend. Rather than sharing the source itself, your application records a mandate the customer approved, and Basis Theory issues a credential scoped to that mandate at the moment the agent is ready to pay.
Agent-initiated purchases break the assumptions payments were designed around. There is no customer present at checkout, there is no way for the merchant to tell an authorized agent from a stolen credential, and a raw credential carries no record of what the customer actually agreed to. Basis Theory answered with a feature that binds a credential to an approved amount, merchant, and expiration, and that, on rails that require it, has the customer prove presence before releasing one.
How Agentic Payments Works with Basis Theory Enterprise
Basis Theory provisions a payment method source across every agentic payment mechanism it supports, then exposes those mechanisms as interchangeable rails behind one mandate model. You record what the customer approved once and choose how to express it at checkout.
A source typically supports more than one rail at the same time, and the differences between rails are real: who holds the mandate, whether the customer must verify, and the credential shape each one produces. Basis Theory does not hide those differences, it reports them. A payment method tells you which rails provisioned successfully. An allowance tells you which rails are ready to mint from and which are waiting on verification. Each rail advertises the credential formats it can produce, so an agent can pick a representation without knowing anything about the source underneath.
Rails, providers, credential formats, and source types are data on the resources rather than fixed vocabulary, so an integration that reads them off the resource instead of assuming them is never coupled to a particular provider.
Supported Rails and Providers
The API reference lists every supported rail, provider, and the credential formats each combination produces. Two kinds of provider back the rails:
Card network agentic programs. Visa Intelligent Commerce and Mastercard Agent Pay are the networks' own agentic commerce programs. Both bind a credential to a mandate held inside the network, and both require the cardholder to approve that mandate with a passkey or one-time code before a credential can be issued. Basis Theory holds the network relationships, so you do not need your own agreements with Visa or Mastercard, and the cardholder-facing ceremonies run inside your application rather than on a page Basis Theory hosts. Because the network holds the mandate, a credential minted under it is bound to that mandate rather than being a general-purpose card number.
Processor shared payment tokens. Stripe Shared Payment Tokens solve the same problem at the processor layer instead of the network layer. Stripe issues a token scoped to a single recipient business, and no customer ceremony is required. This is the faster path to a working agentic checkout, at the cost of the network-level mandate enforcement the agentic programs provide.
What the Customer Approves
An allowance is the record of the mandate, and it is deliberately readable by a human: an amount, a named merchant, a plain-language description of what the spending is for, and a time it expires. It contains nothing provider-specific — no card numbers, no network or processor artifacts — which is what makes it usable as the thing you show a customer for approval.
Basis Theory propagates that mandate to every rail on the allowance and tracks its balance as credentials are minted. Concurrent mint requests cannot take an allowance past its total.
Customer Verification
Whether the customer must prove presence before a credential can be issued is a property of the rail. On rails that require it, the customer approves the mandate through a ceremony the provider owns — on the card network programs, for instance, the cardholder approves with a passkey or a one-time code, while Stripe Shared Payment Tokens require no ceremony at all. Verification is scoped to one rail on one allowance, so approving a mandate does not grant open-ended agentic access to the source.
You own the surface the ceremony runs in; Basis Theory owns the state machine and confirms every transition with the provider server to server, so nothing your client reports can activate a rail by itself.
Spend Controls and What They Do Not Cover
Every credential permanently draws its amount from the allowance when it is minted. There is no void or release operation, and the amount is consumed even if the agent never presents the credential or the merchant declines it.
This is a deliberate limitation rather than a missing feature. Basis Theory issues the credential and then stops being part of the transaction. Merchant authorization, capture, settlement, and refunds all happen downstream on rails Basis Theory does not observe, so a credential's status never becomes approved, declined, or settled, and a client asserting that a credential went unused could not be verified.
Operational Visibility
Rails fail independently, and Agentic Payments is built so a third-party failure is recoverable rather than destructive. A payment method is persisted even when every rail fails at its provider, so the failure stays readable and each rail can be retried in place. Conclusive provisioning and setup failures can be retried without consuming allowance capacity. The exception is a credential whose outcome is unknown after dispatch: Basis Theory consumes the requested amount, because it cannot prove no spendable credential was issued. Every payment method and allowance exposes a paginated history of sanitized provider failures, each with a stable error code, a display-safe summary, and a support correlation ID. Raw provider responses, sensitive source data, and credential values never appear in it.
FAQ
Which sources are supported?
The supported source type is a vaulted card. Visa and Mastercard cards can use the network agentic programs, and either brand can back a Stripe Shared Payment Token. Which rails a specific source gets depends on what each provider accepts for it, so read the rails on the payment method rather than inferring support from the brand.
Do I need my own relationships with the providers?
No. Basis Theory holds the provider relationships — including the network agreements and token requestor registrations behind Visa Intelligent Commerce and Mastercard Agent Pay — so you integrate once against Basis Theory rather than negotiating with each provider.
Which rails are live for your tenant is settled during onboarding, and depends on the source, the region, and the provider's own program eligibility.
Does the agent ever see the underlying source?
No. Your application references the source by its Basis Theory token ID, and the agent receives only a minted credential. For the network agentic programs the credential is network-issued and is not the customer's card number.
Can one customer have several allowances at once?
Yes. A payment method is reusable and carries no spending authority, so a single source can back many concurrent allowances, each with its own merchant, amount, expiration, and verification state.
Can I raise an allowance after the customer approved it?
You can change the amount, description, and expiration while the allowance is active, and the change is propagated to any provider-held mandate before it is committed locally. The amount is locked once a credential has been minted from the allowance. Expiration is terminal: after an allowance expires you create a new one rather than extending it.
What happens when the customer removes a source?
Deleting a payment method cancels every allowance backed by it, including any mandates held at the providers, and no further verification or minting is possible on any of them. Treat it as the customer revoking agentic access to that source.
Can I see whether a credential was actually charged?
No. Basis Theory has no settlement visibility, so credential status stays created. Diagnose declines with the merchant, its acquirer, or your processor first, since they hold the authorization response.
How is this different from issuing a virtual card?
Card issuing creates a new card that you fund and control. Agentic Payments works with the customer's existing card and the existing issuer relationship, and it uses the card networks' own agentic mandates instead of a separately issued card. If you want to issue your own cards, see Card Issuing.
How do I get access?
Agentic Payments requires onboarding. Reach out and we will walk through provider availability, tenant configuration, and production readiness. You can build and rehearse the entire flow in a test tenant against deterministic mocks before any of that completes.
Start Building
Read the Agentic Payments overview for the resource model, then follow the implementation guide.