When an AI agent buys from your business: the finance questions behind the sale
AI agent purchases create new questions about order evidence, authorisation, refunds, and reconciliation for ecommerce finance teams.
Maebh Collins FCA7 min read
Published 1 October 2026
When a customer’s AI agent places an order, finance still needs to understand the transaction. Who instructed the purchase, which amount was authorised, what was supplied, and how a later refund connects to the original payment all matter.
On 29 September, Stripe announced additions to Link’s wallet for agents, including incremental authorisation, checkout assistance, and purchase protection. These features make agent purchasing a practical subject for a merchant’s finance team. The announcement does not establish how material that channel is for an individual business.
I would begin with the order record. My experience of running international product businesses makes me interested in what happens after a channel generates demand: fulfilment, margin, cash, and the work needed when an order goes wrong. Agent purchasing belongs in that same operational conversation, connecting AI in finance strategy with ecommerce and digital operations.
Separate the roles in the transaction
The customer’s agent, the merchant’s systems, and the payment provider perform different functions. A customer might instruct an agent to find a product within a budget. The agent might choose a merchant and submit a purchase through a supported payment route.
The merchant then receives an order and payment information through its own integration. Finance should establish which fields actually arrive. The governed data access article explains why the connection and access scope need their own review. Do not assume that the customer instruction, the agent’s reasoning, or every intermediate approval is visible to the seller.
An agent’s ability to complete a checkout does not answer the merchant’s questions about the order. Check the delivery address, stock reservation, payment status, and order acceptance process in the systems your business uses. Identify which checks are automated and which exceptions reach a person.
This is also where country and product availability matter. Confirm the supported route for your account and customer market before adding agent sales to a forecast. A product announcement is evidence of a feature, not evidence that every merchant can use it under identical terms.
Follow one fictional order through the systems
Consider a fictional customer who asks an agent to buy a desk lamp. The product costs €80 and delivery costs €8, giving a €88 checkout total. These illustrative amounts are customer-facing prices; they do not attempt to model tax or margin.
Suppose the initial customer instruction set an €85 budget. The extra €3 needs to be handled through the payment route’s authorisation process. Finance should not infer that the customer’s first instruction authorised any final price the checkout happens to produce.
Stripe describes incremental authorisation as a way for an agent to request a higher approved amount when the final price changes. Its technical documentation explains the agent-wallet payment flow. The precise evidence available to a merchant depends on the integration.
| Stage | Evidence the merchant should establish | Finance question |
|---|---|---|
| Order received | Order ID, product, quantity, delivery details, and total | Does the order contain the information needed to fulfil it? |
| Payment processed | Payment ID, amount, currency, and current status | Is this an authorisation, a captured payment, or another state? |
| Goods dispatched | Fulfilment record linked to the order | Can the business show what it sent and when? |
| Customer query | Query linked to the order and customer record | Can service staff retrieve the relevant evidence? |
| Refund or dispute | Refund or dispute ID linked to the original payment | Can finance trace the movement through to settlement? |
This table is a proposed review structure. It is not a statement that every agent platform exposes all these records in one place. Missing fields are something to resolve with the integration owner before the channel grows.
Payment status needs its own vocabulary
For the internal review, distinguish the order’s commercial status from the payment’s processing status. An accepted order and an authorised payment describe different events. A finance team should use the statuses supplied by its payment provider and understand their consequences for its own workflow.
Document which event allows fulfilment to proceed and which event creates the records used in reconciliation. Check how expired authorisations, failed capture, or a revised amount are handled. The answer should be visible in a process rule, rather than dependent on someone recognising an unusual order.
Ask the integration team to demonstrate a failed purchase and a changed total as well as a successful one. Follow the records into the ecommerce platform and finance export. A checkout demonstration that ends at success leaves the finance work unfinished.
If a request is retried, establish how the system identifies the existing order or payment. A customer may see one purchase intention while the merchant sees multiple attempts. Your review should show how the integration prevents or identifies an unintended duplicate.
Work out what happens when the customer disagrees
The most revealing test is a disputed outcome. Suppose the lamp arrives in the wrong colour and the customer says the agent selected an option they did not want. The service team needs a route to establish what was ordered and what was delivered.
The merchant may not have access to the original conversation between the customer and the agent. It should not promise that it can reconstruct that conversation from its own order record. Make the limit of the available evidence clear internally.
Stripe’s announcement includes purchase protection for eligible agent mistakes. Finance should check the current protection terms, exclusions, and geographical scope before treating that feature as relevant to a particular case. Consumer protection provided by a platform does not, by itself, establish what the merchant receives or owes.
For any refund, keep the decision, amount, and original payment reference together. Check whether delivery charges, partial fulfilment, or a split payment require separate handling. Obtain the applicable legal and contractual position for the market concerned rather than applying one channel’s policy to every sale.
The wider cost of returns is covered in my existing returns article. The additional question here is whether an agent-initiated order leaves enough evidence for the team to resolve the case promptly.
Reconcile the channel before judging its growth
Give agent-related transactions a reliable identifier if the integration supports one. If it does not, document the limitation. Do not label orders as agent purchases because their browsing behaviour looks unusual.
Take a small sample through order, payment, settlement, and any refund. Record where the identifiers remain connected and where a manual lookup is required. This will expose operational work that a successful checkout count does not measure.
Use the same finance definitions you use for other channels. Count completed orders consistently, distinguish gross sales from refunds, and include processing and service costs in the appropriate analysis. The ecommerce P&L remains the place to understand how the channel contributes financially.
Compare the exceptions as well as the sales. Are service queries harder to resolve? Do changed totals or repeated attempts create more reconciliation work? These are proposed questions to measure, not claims that agent purchases already cause higher costs.
Give the channel an operational owner
I would put finance, ecommerce operations, customer service, and the integration owner in the same review. Each sees a different part of the transaction. One named person should own resolution when those records disagree. The finance leader’s guide to systems integration covers the underlying discipline.
Set an initial review scope that the team can actually complete. Trace a modest number of purchases and every exception during the first review period. Record the missing evidence, the corrective action, and the person responsible.
You do not need a prediction about the future of shopping to begin this work. You need a supported payment route and a transaction you can follow. That is enough to test whether the business can handle the channel properly.
Before scaling, ask the team to demonstrate one purchase, one failed attempt, and one refund from beginning to end. If those records hold together, the commercial discussion has a firmer foundation. If you need finance and ecommerce leadership to connect those systems and decisions, get in touch.
Maebh Collins is a Fellow Chartered Accountant (FCA, ICAEW) with Big 4 training and twenty years of operational experience as a founder and senior finance leader.