The delegated payment token: an allowance with an expiry, not a card number
In short
A delegated payment token is a single-use reference to a card held in a payment provider's vault, carrying 4 constraints: a maximum amount, one currency, a short expiry, and a binding to one merchant and one checkout session. The agent never holds card data. The constraints, not the cryptography, are what cap the loss.
Key takeaways
- It is a reference to a vaulted credential, not an encrypted card number. Nothing card-shaped reaches the agent.
- 4 constraints bound it: amount, currency, expiry, and a binding to 1 merchant and 1 session.
- Encryption protects it in transit. The allowance makes it near-worthless to whoever holds it.
- Expiry runs in minutes, so a session left open for an hour outlives its own credential.
- You charge it through your existing processor. Settlement, refunds and disputes do not change.
A delegated payment token is a single-use credential an AI agent hands your checkout in place of a card. It is not an encrypted card number, and not a card number at all. It is a reference to a credential vaulted by a payment provider, wrapped in constraints: how much, in which currency, until when, and by whom.
The shape exists because the agent is software you did not write, acting for a shopper you cannot see. Give it a card number and every assistant integration becomes a card-data problem. Give it a constrained reference and it becomes an authorisation problem instead.
Four constraints, and the loss each one caps
| Constraint | What it pins down | The loss it caps | Set by |
|---|---|---|---|
| Maximum amount | The largest total authorisable against it | A basket that moved after approval charging more than agreed | The shopper's provider, from the total the agent showed |
| Currency | The currency the amount is denominated in | A cross-currency charge against a figure nobody saw | The provider, matched to the session's quote |
| Expiry | The window in which authorisation is accepted | A stale credential replayed hours later | The provider, in minutes rather than days |
| Merchant and session binding | Which merchant may present it, and against which session | Reuse at a second store, or a second basket | The provider; verified by you at charge time |
The constraints stack and the narrowest wins. A token good for 1 amount, at 1 merchant, until a moment 12 minutes from now is worth little to whoever intercepts it. The cap comes from the total the agent showed, so it inherits whatever that total was based on — which is why the line drawn in a published feed or a live tool call reaches payments.
Where the card is while the agent is shopping
- The shopper authorises inside the agent surface, seeing a merchant, a currency and a total, and approving that purchase rather than open-ended spending.
- The provider vaults the credential. The card, wallet or bank credential stays where the shopper already banks.
- The provider issues a token scoped to that approval, carrying the 4 constraints and meaningless outside them.
- The agent presents it at completion with the session it belongs to, having never seen card data.
- You charge it through your existing processor. Authorisation succeeds inside the constraints, or is refused.
Step 5 is the one teams underestimate: nothing new appears in your money flow. Reconciliation, refunds and chargebacks stay where they are. What changes is the surface the shopper approved on — an ownership question, argued in who owns the order when an agent placed it.
The allowance is the control, not the cryptography
All of this travels encrypted, and none of that encryption limits the agent, which holds the token by design.
Encryption decides who can read the credential. The allowance decides what the credential is worth to whoever is holding it.
- Amount is enforced at authorisation, not in your code. If the total moved after approval, the charge is refused rather than quietly succeeding at the new figure.
- Expiry is why a session cannot stay completable indefinitely, one reason the agentic checkout session treats expiry as terminal.
- Binding makes the token useless in another basket. Presented against the wrong session it is a bug or an attack, and both should fail identically.
- Single use is worth insisting on. A token surviving 1 authorisation is a reusable credential with extra steps.
What we build here, and what we are not
Payments attract vague claims, so here is a plain one. BuildspaceLabs integrates payment providers. We are not a payment institution, we hold no financial licence, and we hold no PCI, SOC 2 or ISO 27001 certification. Nothing we build stores, transmits or renders card data, and no funds pass through anything we run. We build the merchant side: the endpoint that accepts a token, the check that it matches the session it claims, and the ordering that stops a session completing before authorisation returns — MVP and product build work with payments inside it.
What the token is not, and what it does not settle
It is not a stored payment method: nothing about it survives the purchase, so it cannot back a subscription or a saved card. It is not identity either — it proves somebody with access to a credential approved an amount, not who they are. And it does not fix a line pointing at the wrong product, which is why the identifier each channel keys on matters more here than on your own storefront. An authorisation that fails after the agent has confirmed is traced in the charge fails after the agent confirmed the order.
Nor is it the first thing an agent touches. An agent learns you accept delegated tokens from the capability declaration in the manifest an agent reads before anything else, and reads your products through the boundary in what a catalogue tool server may expose. Both sit in agentic commerce, inside our retail and e-commerce practice.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
How do AI agents pay merchants without holding card details?
They pass a reference, not a card. The shopper's provider keeps the real credential vaulted and issues a token scoped to 1 approved purchase — capped amount, 1 currency, a short expiry, 1 merchant, 1 session. The merchant charges it through its normal processor, and nothing card-shaped reaches the agent.
Can a delegated payment token be reused for a second purchase?
No, and an implementation that allows it has lost the property the token exists for. The credential is bound to 1 checkout session and expected to die on first successful authorisation. Reuse leaves the merchant holding a standing authority the shopper approved once, for one basket.
Do we need new payment infrastructure to accept agent payments?
Usually not. The token goes to your existing processor and settles the way your other transactions settle. The work sits on the commerce side: accepting a token at completion, verifying it belongs to that session, and refusing completion until authorisation returns.
- agentic commerce
- payments
- checkout
- protocols
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- The agentic checkout session: a cart your server ownsA server-side basket the merchant owns and an AI agent only renders. Every create, update or complete call returns the merchant's full current state — the property that makes agent buying safe to allow.definition
- The commerce manifest: the file an agent reads before anything elseA machine-readable declaration of what your store can do, served at a fixed path. It is not marketing, it carries no prices, and 3 serving conditions decide whether an agent can read it at all.definition
- The agent confirmed the order and the charge failed afterwardsAn order exists, the shopper was told it is placed, and no money moved. The cause is almost never the card: it is one of the 4 constraints on the delegated token refusing the charge.diagnostic
- Agents fetch your manifest and still skip your storeA file that loads in your browser can be unreachable, unparseable or disqualifying to an agent. Three verdicts, and the ordered checks that tell them apart.diagnostic
- The agent shows one total and your checkout session returns anotherThe shopper saw one number and your server charged another. Replay the call sequence: the agent is nearly always displaying a response that a later call replaced.diagnostic
- The assistant keeps recommending products you stopped sellingA shopping assistant naming products you withdrew is rarely hallucination. It is a stale index, a missing lifecycle field, an unenforced tool call or a tool returning unpublished rows.diagnostic
Related across the site
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation