Final settlement needs checks before signing
Agent payments in stablecoins are final. No chargebacks, no disputes. Why payment providers should require limits enforced before signing, with proof attached.
Card payments come with a safety net. If a purchase was wrong, unauthorized or never delivered, it can be disputed and reversed. A whole industry of fraud scoring, chargebacks and dispute handling sits on top of that one property: payments can be undone.
Agent payments are moving to rails without this safety net. Most agent payments today settle in stablecoins: about 99% of x402 payments use USDC, by one Coinbase estimate. They are fast, cheap and final. That's the right choice for an agent buying an API call for 30 cents. It also removes the safety net that previously managed payments risk.
For payment service providers (PSPs), that changes where the controls have to sit.
What changes when payments are final
| Protection | Card payments | Stablecoin agent payments |
|---|---|---|
| Reversal | Chargebacks and disputes | None once settled |
| Fraud scoring | Per transaction, funded by 2–4% acceptance fees | Potentially uneconomic with an average x402 payment of ~$0.30 |
| Consent | A human approves, or a standing authority they set up | An agent decides, on instructions it interprets |
| Who carries an error | Allocated by scheme rules | Unresolved |
Card-era risk controls mostly act after authorization: score it, flag it, reverse it if needed. With final settlement, a control that acts after the signature is a report, not a control.
Agent errors can look like legitimate payments
The hardest agent failures to stop aren't stolen credentials. They are payments the agent was permitted to make in principle, but with an error baked in:
- Wrong payee: an agent manipulated by text (prompt injection) pays a lookalike service.
- Wrong amount: a misread price, or a retry loop that pays five times.
- Wrong time: spending continues after the task or budget should have ended.
- Too much in total: each payment is small; together they blow the budget.
Each payment is signed by a valid wallet, from a known agent, to a real merchant. Identity checks pass. Per-transaction scoring sees nothing unusual. As one CoinDesk analysis put it, systems can show who authorized an agent, but not whether the agent understood the owner's intent.
Payment service providers need enforcement that stops signatures
If a payment can't be undone, the only reliable control is one that stops it being signed. For agent payments, that means four things.
- A mandate per delegation: payees or merchant categories, a budget, per-payment limits, a time window and a payment count, set by the owner, not the agent.
- Enforcement before signing, outside the agent: the agent proposes a payment, and an enforcer signs only if the mandate holds.
- Cumulative limits checked against state: spend to date and payments made, not just the payment in front of it.
- Proof attached: evidence the payment satisfied the mandate, which the PSP and merchant can check before accepting.
PSPs don't have to build all of this themselves. They can require it from the wallets and agents they accept payments from, the way card acceptance requires tokens and authentication today.
Why it's worth it for a PSP
- Lower exposure. When something goes wrong, a proof shows whether the payment was within the owner's mandate. That turns an open liability question into a checkable fact.
- Merchant confidence. Merchants can accept agent payments knowing each one came from a bounded agent, without trusting every wallet's code.
- A regulatory story. UK payment rules require explicit customer consent, written for human decisions. The FCA has said it will consider whether rules need to change for agentic payments. An owner-approved mandate, enforced and proven per payment, is a strong answer to "how did the customer consent?"
Pakt agentic guardrails
Pakt enforces this pattern today, in beta, for AI agents trading Hyperliquid perpetuals. The owner approves the rules with their own signer. The agent proposes and never holds a key. Each action is checked inside secure hardware (a TEE) against the rules and the account's current state, then signed with a zero-knowledge proof in under two seconds, or refused for good.
For payments, the rules change and the guarantees don't. Pakt builds the checks to each PSP's flow: which payees, which budgets, which windows, and where the proof is checked, whether at your gateway, your facilitator or the merchant.