Why architecture matters here
Agent payments architecture matters because agents that spend money magnify every risk in the platform. A prompt injection that convinces an agent to send money to attacker@evil is a five-figure mistake. A misunderstood user request that books the wrong hotel is a refund case with reputational cost. A missing consent trail is a regulatory violation. The architecture is what bounds each of these.
Consent is the first-order concern. Users must approve specific payments, not blanket "spend money on my behalf" authorizations. AP2 formalizes this via payment intents that require per-transaction confirmation for most cases. The architecture enforces consent; the LLM cannot decide to skip it.
Regulation is the second. KYC, AML, PSD2 Strong Customer Authentication, PCI DSS, tax reporting, and data localization all apply. Building for one payment rail isn't enough; you need the architecture that supports the regulatory surface of every rail you touch.
The architecture: every piece explained
Walk the diagram from top to bottom.
Agent (buyer). The LLM-driven agent acting on a user's behalf. It has a task that requires payment: buy a ticket, subscribe to a service, pay a bill.
Payment Intent. A structured payment description: amount, currency, merchant, product/memo, deadline. Not yet authorized — a proposal. The intent is what the user approves.
User Approval. Human confirmation. Push notification, in-app dialog, secondary channel confirmation. For low-value repeat payments, users may pre-authorize (with limits) via prior consent. For high-value or novel payments, explicit per-transaction approval.
Wallet / Payment Method. Per-agent scoped credentials to a payment method. The agent has a token that lets it initiate payment but doesn't hold the raw card. Scoping limits: max per-transaction amount, allowed merchants, allowed countries.
Fraud + Policy Layer. Velocity checks (this many transactions in this many minutes?), amount limits, merchant category codes, geo constraints, risk scoring. All applied server-side; the LLM cannot bypass.
Payment Rail. Stripe, ACH, card networks, wire, crypto. Each has different settlement times, chargeback rules, and fees. The rail is chosen based on merchant support and user preference.
Merchant Acceptance. The merchant confirms the order: inventory available, price matches, terms accepted. Depending on the rail, this may be synchronous (card auth) or asynchronous (ACH).
Receipt. Immutable record of the transaction: signed receipt, tax details, merchant confirmation ID. Delivered to user and stored in audit log.
Dispute + Refund. When the agent bought the wrong thing, or fraud slipped through, or the merchant didn't deliver, the user needs a path to resolution. Chargeback (cards), refund (Stripe), or reversal (ACH). Consumer protection paths must exist.
Ledger + Reconciliation. Double-entry accounting across the user, agent platform, payment provider, and merchant. Every party sees consistent numbers. Reconciliation batches match at end of day.
Regulatory. KYC identifies the user; AML monitors for suspicious patterns; PSD2 SCA adds two-factor for European users; PCI DSS scopes cardholder data; data localization keeps regulated data in-region.
End-to-end payment flow
Trace a payment. The user asks the agent to "book a business class ticket to Munich next Tuesday."
The agent researches, finds a $1,800 fare with Lufthansa. It constructs a payment intent: $1,800, Lufthansa, business class MUC next Tuesday. It presents the intent to the user with confirmation dialog.
The user reviews details, confirms. Approval flows to the wallet layer. The wallet checks scope: is $1,800 under the per-transaction cap? Is the merchant allowed? Are we in an allowed geo? All pass.
Fraud checks: velocity is normal, merchant category is airline (typically low fraud), amount is within the user's normal spending. No block. PSD2 SCA fires for European card; user does 3DS challenge.
Payment sent via card rail. Lufthansa's payment processor authorizes. Merchant confirms availability and creates the reservation. Receipt returned.
The receipt is signed, delivered to the user, and stored. The ledger records the debit on the user's wallet and credit to Lufthansa. Reconciliation matches at end of day.
The next day the user realizes it's the wrong date. They initiate refund via the agent. The agent contacts Lufthansa, negotiates the refund per airline policy (business class typically refundable with a fee). Refund flows back to the user's card. Ledger updates.