How Agents Handle Payment Flows and Checkout Security

Everything an agent does on the web leads up to one moment: the transaction. Browsing products, comparing prices, reading reviews, all of that is preparation. The actual purchase is where things get complicated, because payment flows were specifically designed to verify that a human is making the decision.

Why Payments Are Hard for Agents

Payment flows include multiple layers of verification designed to prevent fraud. Strong Customer Authentication (SCA) under PSD2 requires at least two of three factors: something you know (password), something you have (phone), and something you are (biometrics). An agent acting on behalf of a user typically has none of these.

3D Secure (3DS) is the most common implementation of SCA. When triggered, it redirects the user to their bank's verification page, which might ask for a one-time code sent via SMS, a push notification to a banking app, or biometric confirmation. An agent cannot receive SMS codes or approve push notifications on a user's phone.

This is not a bug. It is a security feature working exactly as intended. The challenge is finding ways to let agents transact legitimately while maintaining the fraud protections that users and merchants depend on.

Current Approaches

Several patterns have emerged for agent-driven payments, each with different security and usability tradeoffs.

Stored Payment Credentials

The simplest approach: the user pre-authorises a payment method within the agent's system. The agent holds a tokenised card reference, not the actual card number, and uses it for purchases. This is similar to how Apple Pay or Google Pay works. The token can only be used by the authorised agent system, and the token provider can add spend limits.

Merchants see a normal card transaction. The 3DS challenge is handled at the token creation stage, when the human user sets up the payment method. Subsequent agent purchases bypass 3DS because they are classified as merchant-initiated transactions or recurring payments.

The risk: if the agent system is compromised, the token can be used for unauthorised purchases. Spend limits and transaction notifications mitigate this, but they do not eliminate it.

Delegated Authority Tokens

A more controlled approach. The user issues a scoped token that authorises the agent to make specific types of purchases. "Buy any item under £50 from stores in my approved list." The token encodes these constraints, and the payment processor enforces them.

This is still an emerging pattern. Some fintech platforms offer APIs for issuing constrained payment tokens, but adoption among mainstream payment processors is limited. The concept is sound: it gives the user fine-grained control over what the agent can spend, with enforcement at the payment infrastructure level rather than relying on the agent to police itself.

Agent-to-Human Handoff

The most common current pattern. The agent completes every step of the checkout except the actual payment. It fills in the shipping address, selects the product, applies any discount codes, and then pauses. It sends the user a summary and a link. The user clicks the link, reviews the pre-filled checkout, and completes the payment themselves.

This approach is secure because the human makes the final payment decision. It is less convenient because it requires the user to be available at the moment the agent is ready to pay. For time-sensitive purchases (limited stock, flash sales), this delay can mean missing the opportunity.

The Checkout Design Factor

How your checkout is designed directly affects whether agents can get to the payment stage at all, even with the handoff approach.

Guest checkout is essential. If the agent needs to create an account, verify an email, set a password, and then proceed to checkout, most agents will abandon the flow. Guest checkout with minimal required fields (email, shipping address, payment) is the agent-friendly path.

Linear checkout flows work better than multi-tab or accordion-style checkouts. Agents can follow a clear sequence: shipping, then delivery method, then payment. A checkout where all three sections are visible simultaneously and can be edited in any order is harder for agents to track.

Clear error messages with field-level specificity help agents recover from mistakes. "Please enter a valid postcode" is actionable. "There was an error with your submission" is not. The agent needs to know exactly which field to fix.

Minimal distractions at checkout matter. Upsell modals, newsletter signups, and loyalty programme popups during checkout confuse agents. Every unexpected element is something the agent needs to evaluate and dismiss. Some sticky header elements can overlap checkout forms and block interaction.

Security Considerations

There are legitimate concerns about agents holding payment information. If an agent can make purchases autonomously, who is liable for fraudulent transactions? If an agent is tricked by a phishing site into entering payment details, who bears the loss?

Current liability frameworks were not designed for agent-mediated payments. Card network rules assume a human cardholder is making or authorising each transaction. As agent commerce grows, these rules will need updating.

For merchants, the practical advice is straightforward. Do not try to detect and block agent traffic at checkout. Instead, rely on your existing fraud prevention systems (3DS, address verification, velocity checks) to catch genuinely fraudulent transactions. An agent making a legitimate purchase on behalf of a verified user should be treated exactly like any other customer.

Looking Ahead

The payment industry is actively working on agent-compatible authentication. Proposals include pre-authorised spending sessions (the user authenticates once, the agent transacts within set limits for a defined period), agent identity certificates (cryptographic proof that the agent is operating on behalf of a specific user), and payment APIs designed specifically for machine-to-machine transactions.

These solutions are not widely deployed yet. For now, the most practical approach is the handoff model: let the agent do everything it can, and bring the human in for the final payment step. Design your checkout to make this handoff as smooth as possible. Pre-filled forms, clear summaries, and stable checkout URLs that do not expire go a long way.