Customer-Facing Agent Payments: A Reference Architecture for Spending on Behalf of Users

_Last updated: 2026-06-10_

When your product's agent spends money on a customer's behalf (booking travel, reordering supplies, paying invoices), you're operating the hardest archetype in agentic commerce. The agent holds delegated authority over someone else's money. Get the architecture wrong and you face disputed charges, regulatory exposure, and reputational damage that's hard to walk back. Get it right and you have a defensible, trustworthy product that customers actually hand control to.

---

Key takeaways

---

What makes customer-facing agent payments different?

Most agent payment discussions assume the agent is spending the company's money: corporate cards, API budgets, SaaS subscriptions. That's hard enough. Customer-facing payments are structurally different in three ways.

First, the authority is delegated, not owned. The agent isn't spending your money with your permission. It's spending the customer's money with theirs. That changes the legal character of every transaction.

Second, the blast radius is asymmetric. If your internal procurement agent overspends, you eat the cost internally. If your customer-facing agent overspends, the customer sees an unauthorized-looking charge, calls their bank, and files a dispute. You're now in a chargeback process, potentially a regulatory complaint, and definitely a trust crisis.

Third, disclosure obligations are real. Several jurisdictions, including the EU under PSD2 (with PSD3 in legislative process) and the US under Regulation E for certain account types, require that consumers can see what was spent on their behalf, dispute it, and get redress. Designing around this after the fact is expensive. For a grounding on why agent payments need their own infrastructure at all, see Why AI Agents Need Their Own Payment Infrastructure.

---

What does "delegated authority" actually mean in practice?

Delegated authority means the customer has explicitly authorized your agent to take payment actions within defined bounds. The key word is explicitly.

Three things must be true for delegation to hold up:

Consent is active and specific. The customer agreed to let the agent spend, on what category, up to what amount, with what frequency. A checkbox buried in your terms of service won't satisfy a card network chargeback review or a regulatory inquiry.

Scope is documented and auditable. The delegation record (what was granted, when, by whom, in what version of the agreement) must be retrievable on demand. If a dispute arises six months later, you need to produce it.

Revocation is immediate. The customer can withdraw delegation at any time, and that revocation must propagate instantly to the payment layer. An agent that keeps spending after a customer revokes consent is a legal exposure, not just a UX problem.

card networks and regulators already treat stored-credential payments as a distinct category. Visa's Stored Credential Transaction Framework requires express, documented cardholder consent before a credential is stored, and requires stored-credential and merchant-initiated transactions to be flagged as such. It doesn't address agent-initiated charges yet, which is exactly why your own consent records need to be airtight.

---

How should you scope payments per customer?

Per-user isolation is the structural answer. Every customer who grants your agent spending authority gets their own dedicated payment instrument: a scoped virtual card with controls bound to that specific user's delegation.

The architecture has four components:

Issuance. When a customer grants delegation, provision a scoped virtual card for that user. The card's spend limits, merchant category restrictions, and expiry match the delegation terms exactly. No card is shared between users.

Policy binding. Attach the customer's specific consent terms as enforceable rules on the card: not application logic that can drift or be bypassed, but real-time controls checked at the authorization moment. If the customer authorized $500/month on travel merchants, the card enforces that in the Visa authorization flow, not in your backend after the charge clears.

Ledger separation. Each customer's spend history is recorded in an isolated ledger. The customer can see their full transaction history; you can produce it for disputes, audits, or regulatory inquiries.

Notification on spend. Every transaction triggers a notification to the customer: not batched, not on request, immediately. This is your first line of defense against disputes. A customer who sees the charge in real time is far less likely to call their bank two weeks later claiming they didn't recognize it.

---

What does the reference architecture look like, step by step?

Here's how a well-built customer-facing agent payment system flows:

Step 1: Delegation enrollment. Customer opens the delegation flow in your product. They select categories, set a per-transaction and monthly limit, and confirm. Your system records the consent event with a timestamp, consent version, and customer identifier.

Step 2: Card provisioning. A scoped virtual card is created for this customer. Its parameters are programmatically set from the delegation record: MCC group restrictions, spend cap, velocity rules, expiry date matching the delegation term.

Step 3: Agent operates. The agent identifies a purchase opportunity. Before initiating payment, it checks the delegation record: is this merchant category covered? Is there budget remaining? If both pass, the agent proceeds using the customer's scoped card.

Step 4: Authorization intercept. The card network authorization request is checked against the card's policy in real time. If the merchant, amount, or velocity is out of scope, the authorization is declined before money moves. The agent receives a structured decline response and can surface this to the customer.

Step 5: Spend notification. On approval, an immediate push/email notification goes to the customer: what was spent, where, for how much, and which agent action triggered it.

Step 6: Recourse path. The customer can dispute any transaction directly from your product, without calling support. The dispute flow contacts the merchant and, if needed, initiates a chargeback. The delegation can be paused or revoked from the same interface.

Step 7: Audit trail. Every authorization attempt, approval, decline, notification, and dispute event is written to an immutable log keyed to the customer ID and delegation version.

---

What's the reputational blast radius, and how do you bound it?

When an agent makes an unauthorized-feeling purchase, the customer's first reaction isn't "I should check my delegation settings." It's "fraud." They call their bank. The bank files a dispute. The merchant gets a chargeback. You get a chargeback fee and a dispute record. If it happens enough times, your card program gets flagged by the network.

Worse: one customer's bad experience becomes a social post, a review, a forum thread. The blast radius spreads.

Bounding it comes down to four practices:

For more on the general mechanics of safe agent authorization, see [Let AI Agents Pay Safely](/blog/let-ai-agents-pay-safely).

---

Pre-ship control checklist

Before you go live with customer-facing agent payments, confirm each of these:

| Control | Ready? |

|---|---|

| Active, specific consent captured with timestamp and version | ☐ |

| Per-customer scoped card (no shared pools) | ☐ |

| Policy enforced at authorization (not post-hoc in app logic) | ☐ |

| Delegation scope stored and auditable for 12+ months | ☐ |

| Immediate spend notification on every transaction | ☐ |

| In-product dispute and revocation flow (no support ticket required) | ☐ |

| Immutable audit trail keyed to customer ID and delegation version | ☐ |

| Delegation revocation propagates to card in <1 second | ☐ |

| Spend-limit headroom alerts before agent hits cap | ☐ |

| Chargeback and dispute SLA defined and documented | ☐ |

---

Frequently asked questions

Can I use a shared corporate card for customer-facing agent payments?

No. A shared card complicates attribution, makes per-customer dispute resolution nearly impossible, and fails the isolation requirement most enterprise buyers will ask about. Every customer needs their own scoped instrument. If card-level isolation feels operationally heavy, that's a sign you need a platform that makes issuance programmatic rather than building it manually.

What consent language is actually required?

At minimum: what the agent is authorized to spend on, the per-transaction and periodic limits, how the customer can revoke, and how disputes work. Jurisdictions vary (PSD2 and Regulation E have specific disclosure requirements), but designing for the strictest standard gives you a portable baseline. Have legal review the consent language before launch.

How do I handle an agent that tries to spend outside the delegation scope?

The card should decline the authorization before money moves. That's the point of real-time policy enforcement at the authorization moment rather than application-layer checks. The agent receives a structured decline, logs it, and surfaces the boundary to the customer if relevant.

Who is liable when a customer-facing agent makes an unauthorized charge?

Liability allocation is still being worked out, but in current chargeback and consumer-protection frameworks the operator of the agent (you) is the most exposed party. That's why authorization-moment controls aren't optional: they reduce the probability of an out-of-scope charge reaching settlement.

Do I need to display individual line items or just the total?

Best practice is individual transaction disclosure: merchant name, amount, timestamp, and agent action context. Aggregate summaries after the fact are not sufficient for dispute resolution and often don't meet PSD2 transaction reference requirements.

---

Shatale issues per-user scoped cards, enforces delegation-matched policy at the authorization moment, and writes every decision to an immutable audit trail, free for publishers right now. [Apply for early access.](https://shatale.com/early-access)