Agentic Pay: What Problem Does It Solve?
Part IV · Adding Agentic Pay (Chapters 11–12) Builds on: Payment Systems, Chapter 30 (three failed assumptions, scoped credentials and x402), Chapter 8 (3DS, tokenization and liability shift); Chapter 8 of this course (real-time issuing controls), Chapter 6 (acquiring) New concepts in this chapter: four parties' problems, delegated-spending loop, three scoped credential forms, machine-readable checkout
(Products and protocols in this and the next chapter reflect public information available by mid-2026. This area changes even faster than stablecoins. Focus on the structure rather than the list of names.)
1. The question from the previous chapter¶
The model now supports fiat and stablecoin assets, but a person has initiated every payment. From 2025, AI agents — AI programs carrying out tasks for someone — began comparing offers, ordering and paying. Should an agent receive a card number or balance access? How much may it spend? Who answers for an error?
Agentic Payments explains three assumptions this challenges: the operator is no longer the account holder, permission may be an intent with limits rather than approval of each payment, and existing liability rules have no settled place for the agent. That chapter surveys the industry. Here we take the PSP's perspective.
Start with a StarMap purchase.
2. StarMap asks an agent to buy something¶
Finance tells a procurement agent: subscribe the design team to a tool's team plan for three months, stay within €2,000, and choose annual billing if the discount makes it worthwhile.
The agent compares offers, finds an annual team plan for €1,680 and opens checkout. Then three problems appear.
What can it pay with? Finance has a company card number to give it, but that grants broad payment capability. Finance intended permission for this task, category and budget, rather than unrestricted use of a general-purpose credential.
The merchant blocks it. Checkout expects human behavior: CAPTCHAs, device fingerprints and interaction patterns. A data-center IP and automated navigation resemble fraud or scraping, as Agentic Payments explains. Fraud controls may block an agent carrying a real customer's budget.
Who answers for the wrong purchase? The agent might select an individual plan instead of a team plan, or follow a malicious instruction embedded in a merchant page to a more expensive seller. Finance disputes the result, but the PSP sees technically valid payment checks. Existing card dispute rules do not automatically classify an agent's purchasing error.
These problems affect the payer, merchant and PSP. Add the person reconciling the outcome, and all four perspectives become visible.
3. Four parties, four problems¶
| Party | Problem | Result of forcing it through existing tools |
|---|---|---|
| Payer, business or individual | No task-specific permission boundary; only broad card or account access | A partly unpredictable program receives general spending power |
| Merchant | Cannot reliably distinguish a trusted agent from a malicious bot; checkout, prices and stock information may be designed only for people | Block valid customers or accept more risk |
| PSP and issuing side | Familiar authorization signals become less informative; responsibility for agent errors is unclear | Reject agent transactions or absorb uncertain losses |
| Reviewer, such as finance or the individual user | Payment success does not prove task completion; the original authorization boundary may not be recorded | Disputes, refunds and reconciliation lack a common evidence base |
The shared cause is that payment systems authorize a specific payment, while the person delegates an intent with boundaries. The agent must turn that intent into a specific transaction. A layer connecting the two is missing.
4. A six-step loop from mandate to evidence¶
With that layer, StarMap's purchase works as follows:
| Step | Action | StarMap's example |
|---|---|---|
| 1 · Mandate | Set the task, spending cap, merchant category, expiry and human-escalation conditions | Software subscription, at most €2,000, within 30 days; notify finance above €1,500 |
| 2 · Candidate spend | Agent compares options and proposes a specific payee, amount and purchase | Annual team plan from a named merchant for €1,680 |
| 3 · Policy decision | Compare the proposal with the mandate: approve, reject or escalate | Within the overall cap but above €1,500, so finance reviews and approves |
| 4 · Scoped credential | Turn the approved proposal into a credential restricted to that payment | Single-use virtual card, named merchant, €1,680 cap, 24-hour expiry |
| 5 · Existing payment execution | Submit the credential through an existing rail | Merchant uses normal card acquiring; StarMap's balance is reserved and deducted |
| 6 · Evidence | Link task, mandate, proposal, approval, credential, payment and invoice | Finance can identify the task, mandate version, approver and invoice behind the €1,680 |
We call this the delegated-spending loop. Steps 1–4 form the added layer. Step 5 uses the architecture already covered. Step 6 connects the decision to the result.
The scoped credential in step 4 is central. Agentic Payments describes it as a further restriction of tokenization: merchant- or device-bound network tokens narrow card-number use, and scoped credentials add amount, time and single-use limits. Three existing PSP capabilities can implement this:
| Credential form | Rail | Issuing component | Suitable use |
|---|---|---|---|
| Single-use virtual card | Card | Issuing, with merchant, amount and expiry controls | Purchases at card-accepting merchants |
| Scoped payout instruction | Bank or local rail | Payout endpoint, limited to a beneficiary, amount and time | Supplier and invoice payments |
| Scoped on-chain transfer | Blockchain | On-chain payout endpoint, with address and amount restrictions | Frequent, small machine-to-machine payments |
The shared feature is an enforceable boundary attached to the credential. Use outside that boundary is rejected at execution.
Three judgments must remain separate:
- Approving a proposal does not complete a payment. Step 3 permits credential creation. Step 5 may still fail.
- Completing a payment does not complete the task. The merchant may fail to activate service or activate the wrong plan. Fulfillment needs its own check.
- Revoking a mandate cannot reverse a completed payment. Revocation can stop future credential issuance and invalidate unused credentials, but money already paid requires the appropriate refund process.
5. Which products are only parts of the loop?¶
The six steps help identify incomplete combinations:
| Product | Missing steps |
|---|---|
| Scheduled debit or deterministic payment script | No agent-formed candidate in step 2; a person predetermined the payment |
| An agent given a company card number or general API key | No task-specific policy-to-credential boundary in steps 3–4 |
| An agent that compares prices and drafts a payment for a person to make | No credential generation and execution by the delegated workflow in steps 4–5 |
| A payment API an agent can call | Supplies only step 5 |
| A payment fully specified by a person but settled in stablecoins | No agent delegation process in steps 1–4; stablecoins are simply the asset |
A complete loop requires machine-enforceable delegation boundaries, scoped rather than general credentials, and evidence joining payment to task outcome. Merely including AI or automating a payment does not establish those relationships.
6. Where it connects to the PSP model¶
Agentic Pay changes how a payment instruction is formed. The core and rails still execute it. Each existing component gains a connection to the new layer:
| Component | Role in the loop | Required addition |
|---|---|---|
| Balance core | Funding source; credential use reserves StarMap's balance | Associate mandates and credentials with funds and remaining delegated budget |
| Issuing | A ready source of scoped credentials; the issuing ecosystem already has merchant, amount and expiry controls | Tie credential lifetime to the mandate; revoke unused credentials when it is revoked |
| Payout endpoint | Credential source for bank payments | Beneficiary- and amount-limited authorization linked to the invoice |
| Acquiring | Merchant-side agent recognition and machine-readable products, prices and checkout | A checkout path trusted agents can complete |
| On-chain endpoint | Execution for machine-to-machine payments | Economical handling of very small payments, where suitable chains can offer low per-transfer costs |
The decision process changes before payment; execution can reuse existing capabilities. Add a mandate-to-credential layer before execution and an evidence trail after it. A provider already controlling issuing rules, payout authorization or merchant checkout has a place to issue or accept those credentials.
This locates the PSP's opportunity in steps 4 and 5: credential issuance and payment execution.
7. Consumer shopping, procurement and machine-to-machine payments need different loops¶
Agentic Payments distinguishes shopping for people from machine-to-machine transactions. From the PSP's business-customer perspective, procurement deserves a separate column:
| Consumer shopping | Business procurement and payments | Machine-to-machine | |
|---|---|---|---|
| Typical task | Book a flight | Buy software or pay a supplier invoice | Call another program's paid API |
| Payment size, in euros or dollars | Tens to thousands | Hundreds to hundreds of thousands | Potentially less than a cent |
| Frequency | Human shopping frequency | Business payment frequency | Potentially dozens per second |
| Mandate source | Individual | Finance or procurement policy | Program operator |
| Suitable credential | Single-use virtual card or merchant-bound token | Scoped payout instruction or supplier-bound virtual card | Scoped on-chain transfer |
| Suitable rail in this comparison | Card | Bank or card | On-chain stablecoin |
| Dispute need | Similar to ordinary shopping | Often based on invoices and contracts | Limited in the simple API example; stop further calls after an error |
| Evidence links to | Order and fulfillment | Invoice, contract and budget category | Call records |
Payment size influences viable rails: tiny payments may not cover card fixed costs. Dispute needs influence whether card-style protections are useful. Agentic Payments introduced those two variables. A third is who gives the mandate. An individual's boundary might be "no more than $800"; a business adds procurement policy, budget categories and supplier allowlists. That more complex business mandate is closest to the PSP's existing enterprise customers.
8. The questions this raises¶
Someone must perform each step: capture the mandate, issue the credential, open merchant checkout to trusted agents and connect the evidence. During 2025–2026, card schemes, Stripe, OpenAI, Google, Coinbase and startups each claimed parts of the process, with competing and sometimes compatible protocols.
The next chapter maps those roles.
9. Self-check questions¶
- An AI finance assistant reads invoices, checks contracts, proposes payments and calls a bank API after finance approves. Is that the complete loop? What might be missing?
- StarMap permits software purchases up to €2,000 within 30 days. The agent selects a general retailer selling both software and hardware. Can a single-use virtual card enforce "software only"? Where must the remaining check occur?
- Why are steps 4 and 5 the PSP's opportunity?
10. Answers¶
Try answering before reading on.
It has candidate formation, execution and a human policy decision. It lacks step 4 if it uses a general bank API credential rather than a beneficiary- and amount-specific authorization: a compromised agent could call that API beyond the approved payment. Step 6 also needs inspection: does the result automatically link to the task, invoice and contract? Adding the scoped authorization and that evidence completes the missing connections.
The card can restrict merchant, amount, expiry and merchant category, but a general retailer may have one category code for all its products. The card cannot see whether the basket contains software or hardware. Step 3 must check item-level candidate information before credential issuance; step 6 must compare the invoice and fulfillment afterward. Merchant-level credential controls do not replace product-level checks.
The new layer turns delegation into a credential, while established infrastructure executes payment. Credential issuance needs an issuing rules engine or payout authorization capability. Execution needs the balance core, endpoints and merchant acceptance. PSPs already provide these regulated capabilities. Agent platforms or enterprise software can supply steps 1–3, and finance systems can connect evidence, but steps 4–5 still require providers able to issue valid credentials and execute the payment.
Previous: Chapter 10 · Stablecoin Use Cases: Who Uses Them, and for What? Next: Chapter 12 · The Agentic Pay Ecosystem: Where Each Player Fits