Programmable stablecoin payments are what happens when approval, execution, and settlement all become signable primitives. Instead of “click approve, click swap, click bridge, wait, verify,” a user signs a single intent and the infrastructure handles the rest — including paying gas in stablecoins and settling across chains. This guide walks through the approval paradigm that makes this possible, how the flow actually composes end-to-end, and where the primitives (Permit2, Permit3, intents, solvers) fit.
If you are coming from the stablecoin orchestration overview, this article is the payment-flow deep-dive. The big picture: the approval layer has evolved from raw ERC-20.approve to Permit2 to Permit3, and each step has collapsed friction for stablecoin payments.
Fig 1. Each step flattens more friction: Permit2 killed the double-transaction, Permit3 kills the chain fragmentation and the gas-token requirement.
The approval paradigm, from ERC-20 to Permit3
Stablecoin payments start with an approval. That approval is what lets a smart contract pull tokens from the user's wallet to execute the intended action. For years the standard was raw ERC-20.approve — one onchain transaction that authorized a specific spender for a specific amount. It worked, but it was a tax: every new integration required a new transaction, every upgrade required a re-approval, and every dollar of gas paid to approve was a dollar not going to the user's actual goal.
Uniswap's Permit2 flipped the model. Instead of an onchain approval per contract, users sign an EIP-712 message with an expiration and nonce, and the Permit2 contract acts as a trusted intermediary. One signature can authorize a whole sequence of actions inside the signature's lifetime. Permit2 was a genuine breakthrough — it removed the double-transaction pattern and let frontends stage gasless UX for approvals. For a primer on how EIP-712 messages are constructed, see the EIP-712 spec on ethereum.org.
But Permit2 is still single-chain. A user who wants to authorize a stablecoin payment that will land on Base after starting on Ethereum signs one message on Ethereum, then has to repeat the dance on Base. Multi-chain stablecoin workflows multiplied approvals, not consolidated them.
Permit3 is Eco's answer. It extends the Permit2 pattern to be global and chain-portable. One signature authorizes transfers across multiple chains, and — this is the piece that matters most for B2B — stablecoins can be used to pay gas. The user never needs to source ETH on Arbitrum or MATIC on Polygon to make a transfer work. Paying gas in stablecoins closes the last UX gap for payment-oriented integrations. You can see how this composes into orchestration flows in the settlement network guide and the cross-chain transfer checklist.
What makes a payment "programmable"
A programmable stablecoin payment is one where the entire path — approval, execution, settlement, and post-settlement actions — is specified upfront and executed by infrastructure. Four things compose:
A signed intent describing the desired outcome (amount, destination, deadline, conditions).
A global approval — typically Permit3 — that authorizes the infrastructure to pull funds.
A solver or rail that executes the cross-chain delivery.
A post-settlement hook — optional — that fires custody sweeps, accounting entries, or compliance checks when funds land.
The contrast with “non-programmable” payments is stark: in the old model, every step was a separate user action with its own gas cost, failure mode, and recovery path. In the programmable model, the user signs once and the infrastructure absorbs the orchestration burden. The intent-based DEX guide and the intent protocols comparison explain the underlying primitive.
Stablecoin as gas
The biggest practical improvement in programmable payments is removing the native-gas dependency. Native gas tokens are the friction of last resort: you can build a beautiful payment flow, and then the user fails because they do not have 0.002 ETH on the destination chain. The industry has tried paymasters, gas stations, and abstracted wallets to solve this; they work, but they add centralized dependencies.
Permit3 pays gas in the stablecoin being transferred. A solver covers the native gas on every chain touched and collects the equivalent in stablecoin as part of the settled intent. The user sees: “I sent 100 USDC, 99.8 USDC landed, 0.2 USDC of fees and gas were deducted.” One asset, one mental model.
For the broader pattern of gas abstraction, Ethereum's gas documentation and ERC-4337 account abstraction are the canonical background. Permit3 is simpler than full account abstraction for the stablecoin-payment use case — it does not require the user to migrate to a new wallet type.
The numbers matter: on a typical Ethereum L1 transfer, the native-gas cost is a few dollars; on a Base or Arbitrum L2, it is a few cents. Multiply by thousands of monthly B2B transfers and the gas-token treasury operations become a real line item. Paying gas in stablecoins consolidates it, and — importantly — brings it inside the same reconciliation pipeline as the rest of the payment. No separate “native gas tokens held for operational use” ledger.
End-to-end: what a programmable payment looks like
Walk through a concrete flow. A fintech wants to pay a contractor 10,000 USDC on Base. The contractor has a receiving address and a deadline of end of day. Here is the programmable flow:
Fig 2. The whole flow is signed once and executed by infrastructure; the user's only action is the EIP-712 signature at the left.
The fintech's app constructs an intent: “pay 10,000 USDC from source chain X to contractor address Y on Base by Z timestamp.”
The user signs a Permit3 message authorizing the transfer. This signature covers the whole path, including gas.
The intent lands in a solver network. A solver picks it up, checks the rail options, and commits to fulfillment.
The solver executes: pulls funds via Permit3, routes via CCTP or a messaging rail, and delivers USDC to the contractor's address on Base.
Settlement event fires; any registered post-hook runs — for example, posting an accounting entry via the treasury reconciliation pipeline.
Total user actions: one signature. Total chains touched: two or more. Total gas tokens required from the user: zero. That is what programmable means in practice.
Use cases where programmability pays off
Not every payment needs programmability — a one-off transfer does not justify the integration lift. But a few shapes pay back handsomely:
Recurring B2B payouts — payroll, vendor settlement, marketplace disbursements. See the B2B payout API comparison.
Merchant settlement with automated sweeps — funds land on a dedicated address and auto-sweep to custody. The sweep automation tool comparison has the implementation shape.
Cross-chain treasury rebalancing — the system moves balances automatically when thresholds cross. See the treasury automation guide (sibling).
AI-agent-initiated payments — programmable approvals are the foundation of autonomous agent flows. The AI agents for stablecoin treasury explainer and onchain agentic payments piece cover this frontier.
What to watch when integrating
Three practical failure modes kill programmable-payment integrations in the first weeks:
Replay risk. Ensure the Permit3 nonce scheme and expiration are enforced. A sloppy integration re-uses signatures across rails.
Gas-token mismatch. Verify the solver actually settles fees in the stablecoin being transferred; some integrations silently require the user to hold a fraction of native gas as insurance.
Post-hook reliability. If your integration depends on a post-settlement webhook, build idempotent handlers. The webhook infrastructure comparison covers the trade-offs.
Sanctions drift. Destination address screening needs to fire at intent submission, not post-settlement. Integrate a compliance tool into the pre-submit path.
Fee opacity. Document exactly what a solver charges and how it surfaces in reconciliation. A programmable payment where finance cannot explain the fee deduction is a programmable payment that does not make it into production.
How programmability changes product design
Once payments are programmable, product teams stop designing around the payment as a step and start designing around the outcome. That is a subtle but important flip. A checkout used to be “click, approve, wait, confirm, done.” With programmable payments, it is “sign, done.” The time between user intent and completed payment collapses, and the intermediate screens — “your transaction is pending,” “waiting for confirmation” — disappear.
Three product patterns emerge from this:
Invoice-driven flows. An invoicing platform generates a payment request; the payer signs one intent; the invoice updates to paid on settlement. No multi-step “first approve, then pay” flow. The stablecoin invoicing platforms overview surveys the category.
Conditional payments. An intent can encode conditions — “pay X once service Y is complete” — that settle when the condition fires. This is the pattern emerging in escrow and marketplace flows. Related: stablecoin marketplace settlement tools.
Autonomous agent payments. An AI agent signs intents on behalf of a user, within limits the user pre-authorized. The onchain agentic payments explainer and Coinbase AgentKit stablecoin routing walkthrough cover how this fits the Eco stack.
The common thread: programmable payments let product designers treat payment as a signed contract with the infrastructure, not a flow to shepherd the user through. That unlocks product surfaces that used to require custom middleware to build.
Security considerations
Programmable payments carry specific risks worth managing explicitly. Three categories:
Signature hygiene. A Permit3 signature is a bearer instrument until it expires. Use short expirations for high-value flows; rotate signing keys on a schedule; alert on unusual signature volumes. For a deeper look at the security considerations of EIP-712 signatures broadly, ConsenSys has research on mitigating signature phishing.
Solver trust. A solver network introduces intermediaries between intent and settlement. A well-designed network is atomic — the solver can only collect if the settlement completes — but the engineering quality of the atomic guarantees varies across vendors. Audit it. Our solver networks writeup covers the trust model comparisons.
Contract risk. Permit3 and any orchestration contract are smart contracts. Treat them like you would treat any other DeFi dependency: review audits, track upgradeability, monitor for exploits. a16z crypto's crypto security guide is a good framework.
These are manageable risks, not categorical deal-breakers. But they deserve explicit owners in the integration review. Most teams that have lost money on programmable-payment flows did so because nobody was on the hook for signature policy, solver review, or contract audit. Naming the owner at kickoff solves most of this. For a concrete example of how one platform operationalizes these reviews, the treasury API vendor comparison lists the security-review artifacts vendors typically publish.
Developer entry point
For teams building on this pattern, the fastest path is to integrate a programmable-payment-native stack rather than wire Permit3, solver routing, and post-hooks together individually. The stablecoin SDK feature comparison frames the vendor choice. On Eco, Routes handles the intent submission and execution; Permit3 handles the global approval; Programmable Addresses handle the post-settlement side. Three primitives, one integration, covers the whole pipeline. For the broader orchestration picture, start with the pillar on orchestrating stablecoins across 15 chains.
Related articles
FAQ
What are programmable stablecoin payments? Payments where the whole flow — approval, execution, settlement, and post-settlement logic — is specified in a single signed intent and executed by infrastructure. The user signs once; solvers and rails handle the rest.
How does Permit3 differ from Permit2? Permit2 is single-chain and does not cover gas. Permit3 extends the model to be global (one signature across multiple chains) and lets stablecoins pay for gas, removing the native-gas-token dependency. The Permit2 documentation is the background reading.
Can I really pay gas in stablecoins? Yes. With Permit3, a solver covers native gas on every chain touched and collects the equivalent in the stablecoin being transferred. The user sees one asset and one fee line item.
What are stablecoin intents? A stablecoin intent is a signed declaration of a desired outcome — amount, destination, deadline — without specifying the execution path. Solvers or routing infrastructure pick the path. See the intent protocol comparison.
Are programmable payments safe? Yes, when integrated correctly. The safety envelope comes from signature expiration, nonces, and atomic execution. Risks (replay, reorg, rail finality) are well-understood and mitigated by standard patterns. The compliance tools overview is helpful for the policy side.