A stablecoin is attractive to an agent payment system for one structural reason: it settles in minutes, around the clock, without asking a bank whether the counterparty is open for business. That property is real, and for machine-to-machine payments it is genuinely useful. But it arrives bundled with a set of mechanics that behave nothing like a card rail, and the mismatch is where implementations get hurt. Settlement is final, so there is no chargeback. The peg is a promise backed by a reserve, not a law of nature. Fees are paid in a different asset than the one you are sending. The same brand of coin on two chains is two different tokens. And your books live off-chain while the money moves on-chain. This piece walks those mechanics in order — issuance, reserves, custody, finality, fees, depeg, bridging, reconciliation — and what each one demands of an AP2 deployment.
Issuance and redemption — the coin is a redeemable liability
A fiat-backed stablecoin is not a currency; it is a liability of its issuer, redeemable for the reference asset. The primary market works in two directions. To mint, a vetted counterparty wires fiat to the issuer, the issuer records the deposit and mints an equivalent quantity of tokens to an address on a chain. To redeem, tokens are sent back and burned, and the issuer wires fiat out. Most participants never touch this path — they buy and sell on secondary venues, where the price is whatever the order book says.
That two-tier structure is what actually holds the peg. When the secondary price drifts below par, redeeming at par is profitable, so tokens are pulled out of circulation until the gap closes; above par, minting is profitable. The arbitrage only works if redemption is genuinely available at par, promptly, at scale. Every peg failure is, at bottom, a failure of that assumption.
Reserves — composition is the peg
If redemption is the mechanism, the reserve is the fuel. What backs the tokens determines whether redemption can be honoured on the day everyone asks at once. Reserve assets sit on a spectrum: bank deposits and overnight government repo at one end, short-dated treasury bills next, then longer duration, commercial paper, corporate credit, and other tokens at the far end. Each step away from cash adds one of three risks — duration (the asset must be sold at a loss if rates moved), credit (the issuer of the asset may not pay), and liquidity (there may be no buyer at the price you modelled).
Distinguish an attestation from an audit. An attestation reports that holdings matched a stated figure at a point in time; an audit is a broader opinion on financial statements. Point-in-time attestations say little about the days between them. Treat reserve disclosure as an input to a credit assessment you perform, not a guarantee you inherit.
Custody — who actually controls the agent’s balance
On-chain, control is the private key. Whoever holds it can move the funds; nothing else matters. So the custody question for an agent payment system is blunt: which process, on which machine, can produce a valid signature?
Three broad models. Self-custody means your infrastructure holds keys — maximum control, and the entire operational burden of key generation, backup, and rotation. Third-party custody moves keys to a specialist and converts a cryptographic problem into a counterparty and contractual one. Omnibus arrangements hold many customers' balances in shared addresses with entitlements tracked on the custodian's internal ledger — simple to operate, but your claim is a book entry, not an on-chain position. Whichever you pick, agents should never hold raw keys. Make each agent an authenticated client of a signing service that enforces policy, and split hot operating balances from cold reserves so a compromised agent bounds the loss.
Finality and the missing chargeback
A confirmed transfer cannot be pulled back. There is no acquirer to file against, no issuer to arbitrate, no representment cycle. This is the single most consequential difference from card rails, and it inverts where controls live.
Finality itself is not binary. Proof-of-work style chains offer probabilistic finality that strengthens with confirmation depth; chains with explicit finality gadgets mark a block irreversible after a defined process; layer-2 networks often give a fast soft confirmation that only becomes hard once state is settled to the layer below. Pick a confirmation policy per chain and per value band, and be honest that a low-latency soft confirmation is a risk decision, not a fact.
The consequence for AP2 is that every meaningful control must run before the signature. A refund is not a reversal — it is a fresh payment back, which requires the counterparty's cooperation and cannot be compelled.
Pre-transaction controls — where the mandate binds
Because after is too late, the mandate has to do its work before. An AP2 cart mandate expresses a signed, verifiable statement of what the user authorized; on a stablecoin rail that statement has to bind to the specific things that make a transfer unique — the amount and token, the destination address, the chain, and an expiry. A mandate that authorizes 'pay the merchant' without pinning chain and address authorizes far more than the user meant.
The signing service is the choke point, and it should refuse rather than warn. Practical gates: check the mandate signature and expiry; confirm the destination is on an allowlist or has passed screening; enforce per-transaction, daily, and cumulative velocity caps; simulate the transaction and reject on unexpected state changes; and require human approval above a threshold. Each of these is cheap before broadcast and impossible after.
Gas, fees, and who pays them
The asset you send and the asset that pays for sending it are not the same thing. Transfers consume a chain's native gas token, priced by demand for block space, so a payment can fail for lack of gas while the balance being paid is untouched. That is a real operational trap for autonomous agents: an address funded entirely with stablecoin cannot spend a cent of it.
Mitigations exist. Account-abstraction style designs let a paymaster sponsor gas on the user's behalf, and some tokens support delegated transfers where a relayer submits the transaction and is compensated in the token itself. Both move the cost rather than removing it, so decide explicitly whether payer, merchant, or platform bears it. Two more details bite: a reverted transaction still consumes gas, and per-address ordering means one stuck transaction can block every later payment from that address until it is replaced.
Depeg — the failure mode to design for
A depeg is a divergence between the secondary market price of a token and its reference unit. It can be triggered by doubt about reserve quality, by loss of banking access on the redemption path, by a liquidity squeeze in the venues where the token trades, or simply by redemption being gated or slowed. Historically these episodes have ranged from brief and shallow to permanent, and the difference has tracked reserve quality and redemption access rather than sentiment.
What matters is how a payment system behaves during one. Price the obligation in the unit of account, not in tokens, so a discount is visible instead of silently shifted onto the merchant. Attach a validity window to quotes. Define a tolerance band with an automatic response — widen spreads, cap exposure, then suspend the rail — so the decision is pre-agreed rather than improvised. And keep a second rail configured, because a suspended rail with no alternative is an outage.
Bridging and multi-chain fragmentation
'The same stablecoin' on two chains is usually two different tokens with different contract addresses. Some are natively issued by the issuer on each chain and are mutually redeemable; others are bridged representations, minted by a bridge against assets it locked elsewhere. A bridged token's value depends on the bridge's solvency and correctness, and cross-chain bridges have been among the largest single loss events in the ecosystem's history. Treat a bridged wrapper as a distinct credit instrument, not as the underlying.
Fragmentation also has mundane costs: liquidity splits across chains, and address formats that look identical across EVM networks make wrong-chain sends easy and unrecoverable. The defensive posture is enumeration. Maintain an explicit allowlist of accepted (chain, token contract address) pairs, resolve every payment to one of them, and reject anything else outright rather than attempting a best guess.
Reconciling an off-chain ledger against on-chain settlement
Your books are a double-entry ledger in a database; the money moves on a public chain. Reconciliation is the discipline of proving those two agree, and it is harder here than against a bank statement because the chain is authoritative, eventually consistent, and accepts payments you never asked for.
Model an explicit in-flight state between 'signed and broadcast' and 'confirmed to policy depth', and never treat broadcast as settled. Match on transaction hash as the primary key, since a memo or reference field is optional on most chains and frequently omitted. Then handle the awkward cases deliberately: a reorg that un-confirms a credited transfer; duplicate or partial sends from a counterparty who retried; unattributable inbound funds to a shared address; token decimal precision (six on some tokens, eighteen on others) that silently truncates; and gas, which is a real expense in a different asset and belongs in its own account.
Compliance and the issuer’s freeze — finality with an asterisk
A chain does not perform know-your-customer checks, so the obligations do not disappear; they relocate to you. Screening moves from a name-and-account check to an address check against sanctions and risk lists, plus heuristics about an address's history. Transfers between regulated institutions may carry originator and beneficiary information requirements the chain has no field for, so that data travels in a separate messaging layer.
One mechanism deserves explicit mention because it complicates the finality story: many fiat-backed token contracts include an administrative function letting the issuer freeze an address or blocklist funds. This is not a chargeback — it is not available to you, it is not a dispute process, and it can be exercised against a balance you hold. Plan for both directions: you cannot reverse a payment, and a third party can immobilise yours.