Money Has No Undo Button: Agents in the Payment Flow

Money has no undo button. Once it moves, it is mostly gone, and that single fact makes payments one of the hardest places on the internet to point an autonomous agent.

I build payment infrastructure at Hero Plus Group, where we move transactions across Southeast Asia. So when the rest of the industry started getting loud about agentic commerce, I found myself reading it through a fairly specific lens: not “what can an agent buy for me” but “what happens when software, not a human, is the thing reaching for the money.” Those are not the same question, and the gap between them is where most of the hard engineering lives.

The marketing version says agents will shop, negotiate, and pay on your behalf. The infrastructure version is less romantic and, to me, far more interesting. The domain is unforgiving in ways that prompts and benchmarks don’t really prepare you for, not because the AI is hard, but because the stakes do not reset.

The landscape is real, not hype

Part of why I take this seriously now is that the rails are actually being laid. Stripe shipped an Agentic Commerce Protocol (ACP) for letting agents transact against merchants. The x402 protocol revived the long-dormant HTTP 402 Payment Required status code into a real settlement path, using on-chain USDC, and moved under the Linux Foundation in 2026. Ant International open-sourced its Agentic Mobile Protocol (AMP). Visa and Mastercard both launched agent payment programmes to credential and constrain software buyers. This is not a single standard yet, it’s more of a standards war, but the direction looks fairly clear to me.

The market framing is loud too. Industry analysts at McKinsey have floated projections putting agentic commerce somewhere on the order of $3 to $5 trillion globally by 2030. I’d treat that as a directional industry bet rather than a fact, but even discounted heavily it’s a number large enough to reorganize an industry around.

In Southeast Asia the angle sharpens, at least from where I’m standing. Digital payments are projected to be the overwhelming majority of e-commerce across the region, and the shift I find most interesting is not happening in the apps people tap. It’s happening underneath, in the settlement, tokenization, and authorization layers that most users never see. That underlying infrastructure is roughly where I sit, and it’s where I think agents will either be safely contained or quietly cause a disaster.

Why payments is the adversarial stress test

The way I think about it, the core tension here is an engineering one, not a philosophical one.

Money movement is mostly irreversible. Once a settlement clears, you are not pressing undo, you are filing a dispute and hoping. Compare that to almost every other domain people point agents at: a bad draft email gets rewritten, a wrong database read gets re-run, a hallucinated summary gets ignored. In payments the default failure mode is permanent.

On top of that, most of the fraud and regulatory models we rely on were built for human behaviour. Velocity checks, spend pattern anomaly detection, KYC flows, much of it assumes a person with human-scale tempo. An agent can fire thousands of micro-transactions per second, each individually plausible, and walk straight through controls that were never designed for that shape of traffic. The threat model inverts. The legitimate user now behaves like the thing the system was built to catch.

That combination, irreversibility plus human-shaped controls meeting machine-shaped behaviour, is why I’ve come to think of payments as something like an adversarial stress test for agentic systems. My instinct is that if your harness survives here, it has a decent shot at surviving most places.

The five layers of an agentic payment lifecycle

When I try to decompose what an agent actually has to do to complete a purchase, it tends to fall into five layers for me. Each one reads as a distinct trust boundary.

flowchart TB
  L1[1. Merchant Discovery
catalog access, product feeds]
  L2[2. Delegated Identity
user intent capture, scope of mandate]
  L3[3. Payment Credentialing
tokenization, network agent credentials]
  L4[4. Authorization Rules
spend controls, policy checks]
  L5[5. Post Transaction
fraud, chargebacks, liability]
  L1 --> L2 --> L3 --> L4 --> L5
  L5 -.feedback.-> L4

The first three layers are mostly about representation and consent: which merchants the agent can see, what the user actually authorized, and what credential the agent presents. The protocols above are largely fighting over these. The last two layers, authorization rules and post-transaction liability, are where my own work tends to live, and to me they’re the layers that decide whether the whole thing is safe. You can standardize discovery and credentialing all day, but if spend control and liability are weak, I’d argue you’ve mostly built a faster way to lose money.

Where I would actually deploy agents at Hero Plus first

Given all that, here is the view I hold most strongly: the first place I’d want to put an agent at Hero Plus is not the money-movement path. It’s the back office.

The money path is irreversible, adversarial, and regulated. The back office is read-heavy, reversible, and drowning in toil. That asymmetry is most of the argument for me. The deployments I’d reach for first, the ones that feel high-value and low-regret, are:

• Reconciliation. Matching settlement reports against ledger entries is enormous, repetitive, pattern-matching work. An agent that proposes matches and flags the residue is genuinely useful, and every output is verifiable.
• Dispute and chargeback triage. Pulling the transaction history, the evidence, and the network rules into a drafted recommendation. A human still decides.
• Anomaly investigation. When a metric moves, an agent can gather the context, correlate signals, and write up the leading hypotheses before an analyst even opens the dashboard.
• Ops runbooks. Executing the read-only diagnostic steps of an incident playbook and summarizing the state.

Laid out as a rough map of where I’d let the agent operate, the asymmetry is hard to miss:

The common thread across the top four rows: these tasks are read-heavy and reversible, and they’re high-toil enough that even an imperfect agent tends to earn its keep. The last row is the contrast that, for me, defines the rule. The agent drafts. A human commits anything irreversible. That single rule, the agent never crosses the irreversibility line on its own, is what makes me comfortable starting the whole program at all.

The guardrails are the harness, and here they matter most

I’ve written before that the model is just one input into a running system, and that the harness around it, the prompt, tools, context policy, and guardrails, is where I think most of the real engineering sits. I’ve also walked through evolving a system from one-shot RAG into a properly harnessed agent. Payments is where that view, for me, stops being a design preference and starts feeling like a survival requirement. The guardrails aren’t a feature wrapped around the agent. In a payments context, I’d argue the guardrails are the product.

The way I see it, the harness matters even more in payments than it does elsewhere. The human-in-the-loop is not a courtesy step, it is the exit gate before an action that cannot be taken back.

So here is what I’d treat as non-negotiable for any agent that can get near money. These are the parts I wouldn’t bend on:

• Hard spend caps. Per transaction, per session, per day. Enforced as a ceiling the agent literally cannot exceed, not a number it’s politely asked to respect.
• Delegated authority with explicit scope and expiry. A mandate that says what, how much, for how long, and against which merchants. When it expires, it’s dead. No standing, unbounded authority, ever.
• Idempotency keys. A retrying agent is the natural enemy of exactly-once money movement. Every payment intent carries a key so a retry collapses into the same charge instead of a second one. This one line of discipline prevents an entire category of catastrophe.
• Deterministic policy enforced outside the model. This is the load-bearing rule. Spend limits and authorization logic live in code at the trust boundary, not in the system prompt. A prompt is a suggestion the model can be argued out of. A policy check in the harness is a wall. You never trust the model to enforce the rule that protects the money.
• A full audit trail. Every decision, tool call, and authorization captured as durable, replayable state. Regulators will ask, disputes will require it, and you will need it the first time something goes wrong.
• Human-in-the-loop as the exit gate. Every irreversible action passes through a human approval step. That gate is the difference between an agent that drafts and an agent that detonates.

Put together, those guardrails form a flow where the model proposes and the harness disposes:

flowchart TB
  INTENT[User Intent
plus scoped mandate] --> AGENT[Agent Reasoning Loop
drafts a proposed action]
  AGENT --> POLICY{Deterministic Policy Check
spend cap, scope, expiry, idempotency}
  POLICY -->|reject| BLOCK[Blocked and logged]
  POLICY -->|reversible action| EXEC[Execute, fully audited]
  POLICY -->|irreversible money movement| GATE{Human in the Loop
approval gate}
  GATE -->|approve| EXEC
  GATE -->|deny| BLOCK
  EXEC --> AUDIT[(Audit Trail
durable, replayable)]
  BLOCK --> AUDIT

Notice where the model is in that diagram. It drafts. It never holds the keys. Everything irreversible routes through a deterministic check and, when it really matters, a person. That’s the same harness discipline I try to apply everywhere, just with the stakes turned all the way up.

The honest position

I’m fairly bullish on agents in payments and, at the same time, deliberately conservative about where they touch. Both at once. The protocols arriving in 2026 are real, the regional shift toward digital settlement is real, and the back-office toil that agents can absorb today looks both substantial and low-risk to me. But the way I’d run it, the money-movement path earns autonomy slowly, one guardrail at a time, and only after the boring layers underneath it are provably solid. This space is moving fast, and I’m reasoning from a payments engineer’s instinct here, not claiming to have it all figured out.

My read is that payments doesn’t reward optimism so much as it rewards a harness that assumes the worst and is built so that even when the model is wrong, the system is still safe. Get that right and the agent can become a genuine force multiplier. Skip it and I suspect you’ve just automated one of the fastest ways to lose money ever invented.