What the Commerce Payments Protocol adds to onchain payments
Coinbase and Shopify are launching the Commerce Payments Protocol to close the gap between crypto payments and real-world commerce. Most onchain payments today handle peer-to-peer transfers well but lack the mechanisms needed for commercial purchases, which require multi-stage payment commitments. The protocol brings those flows onchain while preserving crypto's speed, low cost and global reach.
The protocol is available now on Base and open to all developers. It powers Shopify's new USDC payment method, which is rolling out to merchants using Shopify Payments, letting them accept USDC on Base through their existing checkout.
What crypto already does well
Payments on Base settle faster, cost less and work across borders without intermediaries. For goods delivered immediately, fast settlement matters: on Base, payments can land in as little as 200 milliseconds, even internationally. Transaction fees are typically under $0.01, and they keep dropping as network capacity grows.
Base is internet-native, so anyone with a connection can transact globally, which opens new markets for merchants and new options for buyers. Blockchains also create a shared ledger that different systems can reference, enabling shared standards and composable, interconnected applications.
What commerce needs that crypto hasn't had
Since the famous Bitcoin pizza purchase fifteen years ago, most onchain payments have stayed stuck at direct token transfers. Commerce demands more. Checkout, settlement and fulfillment race against each other: inventory can sell out between checkout and payment, tax obligations can shift, and either party may cancel an order or request a refund.
Traditional finance splits the problem by separating buyer approval from the storefront's checks before execution. The crypto equivalent is letting buyers sign off on spending without immediately broadcasting a transaction. That pattern — known as authorize and capture — has supported commerce for decades. It locks buyer funds on authorization, then disburses them to the merchant on capture, giving merchants payment guarantees and buyers reserved-but-not-finalized payment, while keeping fees lower since merchants only pay on captured amounts. It also allows partial captures for split fulfillment.
Onchain payments have lacked this capability, which is what the new protocol introduces.
Escrow at the center
The protocol inserts an escrow smart contract between what it calls the payer and the receiver — deliberately more general terms than buyer and merchant. Authorization moves funds from the payer into escrow; capture moves them out to the receiver. The contract enforces that authorized funds are held, guaranteeing they can be captured later.
Escrow avoids assumptions about what the payer's or receiver's addresses can do. A locking mechanism on the payer's wallet, by contrast, would require capabilities many wallets don't have. The escrow contract is immutable and open to anyone, which gives integrators strong guarantees and makes it a shared hub for commerce payments.
The operator role and its limits
Blockchain transactions need fees, and the protocol follows traditional commerce by having receivers absorb them instead of payers. That improves payer conversion, but forces receivers to manage blockchain transactions. The protocol introduces a new role, the operator, to handle moving funds between the transacting parties.
An operator can be any address — a simple externally-owned account, an advanced smart contract or an API-driven service. Coinbase provides one, and the protocol is open for anyone to build their own. But operator convenience never supersedes security: users shouldn't have to trust an operator to be safe.
Three safeguards limit operator power. First, operators can't change the payer's original intent, including the receiver address, token, maximum amount and expiries. The payer signs a hash of those details, making any alteration detectable, and the protocol rejects any signed payment used more than once.
Second, operators can't lock funds indefinitely. If an authorization expires without capture or void, the payer can pull funds directly out of escrow without operator involvement. Third, operators can't interfere with each other. The operator's address is encoded in the signed payment, so only one operator manages a given payment's lifecycle. Payments for different operators sit in separate escrow buckets, so a vulnerability in one operator's setup doesn't put others at risk and honest operators can migrate payments to patched protocol versions.
The operations covering a payment's lifecycle
Six core operations make up the protocol, each updating payment accounting and enforcing that transitions only happen within the valid windows set by the payment's expiries:
authorize— moves funds from payer to escrowcapture— moves funds from escrow to receivercharge— combines authorize and capture in one transactionvoid— returns uncaptured funds from escrow to payerreclaim— payer-initiated void after authorization expiresrefund— returns captured funds to the payer
Authorization and capture
authorize reserves payer funds for future capture, enabling delayed settlement and guaranteeing merchant payment. Collecting those funds is left open-ended, but the initial implementation uses ERC-3009, which lets any wallet type grant spending permission with just a signature. That signature must be used before an expiry defined at signing time.
capture transfers authorized funds to the receiver. It can happen in multiple partial increments, supporting merchants who ship goods in batches, but the total can't exceed the authorized amount. Captures are also bound by the authorization expiry set when the payer signs.
charge combines both steps into one transaction for payments that don't need delayed capture. It mirrors a credit card "sale" and follows the same expiry patterns as authorize.
Void, reclaim and refund
void cancels an authorization, returning escrowed funds to the payer. It handles errors unrelated to payment or orders merchants can't fulfill, and can execute at any time, but only once per payment, reversing the full remaining authorized amount.
reclaim is the payer equivalent of a void, only available after an authorization has expired. It's a safety valve against a malfunctioning operator and is the sole payment operation not controlled by the operator.
refund returns funds after capture. Like authorization, it uses ERC-3009 to flexibly source capital from the receiver, another merchant-controlled address or the operator. Refunds are subject to an expiry, after which captured payments are final.
How a Transaction Unfolds
When a customer chooses to pay with crypto, the merchant's storefront first asks the buyer to sign the payment details using their wallet. The storefront then forwards that signed information to an operator service, which constructs and submits a blockchain transaction. That transaction directs the operator to call the escrow smart contract for authorization. Once the call executes successfully, the buyer receives confirmation of payment. The merchant can later choose to capture or void the authorized amount.
An Open Foundation for Onchain Payments
Although Coinbase and Shopify currently act as stewards and initial participants, the protocol itself is open. No single party controls it, and nothing prevents others from building on top of it.
Keeping the core to just six payment operations was a deliberate choice. That minimal surface made security review tractable while still leaving substantial room for innovation above the base layer. Several directions stand out as particularly promising.
Operator Smart Contracts
Because operators drive money movement, they are the natural place to compose payment logic with additional contract systems. The design also permits delegating operator control to other roles—or back to the payer and receiver themselves—depending on the level of trust a given integration requires.
Receiver Smart Contracts
Receivers can leverage the same composability to stack features like revenue splitting, currency swaps, or privacy mechanisms directly into how they accept funds.
Token Collector Smart Contracts
The exact mechanics for token collection and refunds were intentionally left vague in the initial description for brevity. The current implementation integrates with ERC-3009 for gas-less USDC payments, but that is only one route. Signing authorizations opens the door to flexible refunds—where liquidity to make the payer whole can come from any source, enabling looser settlement between operator and merchant. Discounts, chain abstraction, and multi-token payment options are other plausible extensions.
The full implementation and documentation are available on GitHub, and the Base Discord server is open for questions. The infrastructure for permissionless, decentralized commerce is in place—what remains is building on it.
