Agentic payments: how to delegate payment and limit authority
A customer asks an agent to order their usual supplies, but the price and delivery terms change during the search. Who authorised the new amount to be charged? Agentic payments should start with an answer to that question, not a payment button in a chat. For an online store, the key decision is to define the limits of delegation: a specific seller, currency, amount, time limit and conditions for renewed confirmation.
This is a scenario in which a software agent initiates payment on behalf of a user within the authority granted to it. It is not permission for a model to control a card. The relevant infrastructure executes the payment, while the store checks the order and the transaction outcome. Below, we explain how to design this process, distinguish it from a conventional checkout and test it before launch.
Where shopping assistance ends and delegation begins
An assistant can compare products, build a cart and open a payment page. If the customer always performs the final action in a standard checkout, this is not yet autonomous payment delegation. The next level is when a user authorises an agent in advance to complete a specific purchase on agreed terms. This requires a separate permission record, a validity check and a clear way to stop execution.
Three things should be kept separate: the intention to buy a product, authority to initiate payment and the actual processing outcome. A message saying “buy the cheapest” does not specify an authorised seller, the total including delivery or an acceptable substitution. Even successful bank authorisation does not mean that the warehouse has confirmed the goods or that the order is ready to ship.
General dialogue and catalogue capabilities are a separate topic covered in our article on an AI assistant for an online store. In a payment project, acceptance is based not on the quality of the bot’s response but on whether every financial action complies with the agreed parameters.
Compare modes by their controls, not their level of autonomy
A starting point can be a cart prepared by an agent, followed by ordinary customer confirmation. Expand the agent’s authority if the frequency of repeat purchases justifies the additional support complexity.
| Criterion | The agent prepares, the human pays | The agent acts under limited permission |
|---|---|---|
| Final decision | The customer checks the cart at checkout | The service checks the action against recorded conditions |
| Change in the total amount | Visible before confirmation | Requires limits to be checked and, where necessary, renewed consent |
| Payment access | The provider’s standard process | Compatible, restricted payment authority |
| Exception or uncertainty | The customer decides in the interface | Automatic action stops and is handed over to a human |
| Operational readiness | A stable checkout and cart | Additionally: revocation, audit and state reconciliation |
For expensive purchases or bespoke delivery arrangements, the simpler mode is often easier to understand. Limit the pilot to one type of purchase rather than the entire product range.
What a payment token restricts — and what it does not prove
One specific implementation is Stripe’s Shared Payment Tokens, or SPTs. According to the official SPT documentation, an agent gives a designated seller restricted access to the customer’s payment method. A currency, maximum amount and expiry time are set for that access. This is an example of a mechanism, not a universal requirement for all agentic payments.
A token’s lifetime is not the same as the permission’s validity period
Delegated payments need their own business rules. A customer may authorise a purchase until the end of the working day, while the issued payment token has a shorter lifetime. A valid token does not extend an expired approval, and a valid approval does not make an expired token usable. Check both conditions independently before taking action.
The permission service must link the transaction to a cart version and substitution rules. If the instruction covers several purchases, an explicitly defined policy is needed; do not turn one-off permission into a subscription by default.
Do not describe every token as single-use
Stripe describes non-recurring and recurring SPTs: the label “token” does not mean exactly one charge. For a one-off purchase, check the selected mode and ensure that no unintended recurring payments are enabled. Record the parameters based on the documentation for the actual version of the integration.
As of 11 November 2026, Stripe lists the countries supported for SPTs; Ukraine is not on that list. This is not a conclusion about all other payment products or all customers with Ukrainian cards. Availability must be checked for the specific participants, accounts, methods and markets involved. Access to conventional acquiring does not confirm access to an agentic product.
A hypothetical example: the price changes after approval
A hypothetical example in a supported environment: a user authorises the purchase of a set of supplies from an agreed seller. The permission covers the product codes, the total including delivery, the currency and a time limit. This is not a GL.ua case study or a claim that the service is available in Ukraine.
The agent obtains a current offer, and the store’s server saves its version. After approval, the delivery terms change and the total exceeds the authorised limit. The correct response is not to round it or add an explanation in the chat after charging the customer, but to stop execution and show the new terms. New payment access is arranged only after the change in permission has been properly confirmed.
If the amount remains within the limit but the product is replaced with another one, the check must also catch this. A monetary limit does not replace a check of the purchase contents. To do this, the server compares the cart version, seller and permitted substitutions; the model merely proposes an action rather than rewriting the approval rules.
An additional exception is a requirement for further customer confirmation. In Stripe, an SPT can enter the requires_action state, including when 3D Secure authentication is required. The flow must be able to pause, hand the required step over to a human and resume correctly. A promise of “payments without customer involvement under any circumstances” is therefore inaccurate.
Build a controlled path from permission to order
Set up a dedicated approval-checking service before calling the payment provider. The language model must not receive unrestricted secret keys or card details. Its payment tool should accept only the minimum parameters of the authorised transaction.
This chain needs a shared link between the permission, cart version, order and payment transaction. Payment authority controls mean that these relationships can be verified after a failure rather than reconstructed from the conversation. A repeat request with the same intent must not create a second purchase just because the first response was lost.
The AP2 protocol describes cryptographically signed mandates for checkout and payment. The specification makes authority verifiable, but it does not automatically provide acquiring. Supported versions and participant roles should be agreed before development.
The store manages stock reservations separately. If payment is confirmed after a reservation expires, shipment must not be promised automatically. A fresh check and a defined exception-handling route are needed. This related process is covered in our article on confirming available-to-promise stock (ATP).
How to test the solution before launch
Start in the provider’s test environment with a matrix of permitted and prohibited actions. Each test needs expected order and payment states and a person responsible for handling exceptions.
- Confirm product availability for the required participants and payment methods. Record the integration version and the limits of test access.
- Reproduce a valid purchase, an amount above the limit, a different currency, a different seller, a product substitution and expiry of the permission. Unauthorised changes must stop the action.
- Test an expired and a revoked token separately from a revoked business permission. Do not rely solely on a message in the conversation.
- Simulate a lost response after a request and redelivery of a message. Ensure that a repeat does not create a new order or an unnecessary payment attempt.
- Work through additional authentication, a decline, cancellation and a refund. Reconcile states in the store and at the provider, including late events.
- Test disabling the agentic channel, the standard checkout and support operations. The team must be able to see why the action stopped and have instructions for the customer.
The log must explain events without secrets or unnecessary personal data. Verify the authenticity of provider messages and the transaction state before taking an irreversible action. These are acceptance criteria, not a guarantee against fraud.
Pilot risks, timelines and costs
The main risks are misinterpreted permission, tampered terms, repeated execution, leaked access and mismatches between payment and order states. Tokens, server-side checks and logs reduce these risks but do not eliminate them. An external product description or an agent’s message cannot change the payment policy.
Timelines depend on readiness across the chain
Plan the stages: availability checks, permission definitions, a prototype, integration with order states, exception testing and a limited launch. Timelines depend on product access, API readiness, reservations, refunds and support. Provide a calendar-based estimate after these checks.
Separate business analysis, the approval interface, the permission service, payment integration, the event log, testing and operational instructions in the budget. Calculate infrastructure, model usage, provider fees, monitoring and support for API changes separately. Clarify payment-processing terms and the parties’ responsibilities with the provider and qualified professionals; this article is not financial or legal advice.
Start with verifiable limits on authority, and keep conventional checkout as a working alternative. If the store has not yet aligned payment and order states, fix that process first. For a concrete next step, share a diagram of your current payment flow and one delegation scenario with GL.ua (Glyanets) as part of online store development and integrations: this provides a basis for assessing the pilot’s architecture, limitations and scope of work.
Just one step to your perfect website
