MENU
Stablecoin payments are becoming more integrated with mainstream financial infrastructure, but their growth also raises practical questions around custody, settlement, merchant operations, and regulatory oversight. Federal Reserve research on recent stablecoin market developments found that aggregate stablecoin market capitalization reached $317 billion in April 2026, after growing more than 50% since early 2025.
Coinbase Commerce was an early cryptocurrency checkout product built around self-custody and broad crypto acceptance. That product has now been consolidated into Coinbase Business. The transition deadline passed on March 31, 2026, and the former Commerce platform is no longer the relevant product for new merchant evaluations. Coinbase Business instead provides a custodial business account with stablecoin payments, invoices, payment links, treasury functions, trading, accounting integrations, and APIs.
Coinbase launched Commerce in 2018 as a cryptocurrency payment product that allowed merchants to accept digital assets while retaining control of their funds through self-custody.
That model reflected an earlier phase of crypto payments. Merchants could receive assets directly, but they also carried more responsibility for wallet management, private keys, asset conversion, and operational security.
Coinbase has since moved to a different model.
Commerce was consolidated into Coinbase Business, and merchants were instructed to complete the transition by March 31, 2026. After that date, the Commerce portal became inaccessible for normal merchant operations, including creating new Commerce charges and managing payments through the former dashboard.
Coinbase Business is currently available to eligible businesses in supported markets, including the United States and Singapore.
For businesses researching Coinbase Commerce today, the practical product to evaluate is Coinbase Business.
The transition represents more than a change in branding.
Coinbase Business moves away from the original Commerce model toward a custodial financial platform that combines merchant payments with broader business account functionality.
Important changes include:
Commerce merchants were also instructed to export their historical transaction data separately rather than assuming those records would automatically move into Coinbase Business.
The result is a materially different product architecture from the original self-custody merchant checkout experience.
The current Coinbase Business merchant-payment suite is primarily designed around USDC.
Customers can pay in USDC across supported networks including Ethereum, Base, Polygon, Optimism, and Arbitrum, with funds settling into the merchant's Coinbase Business account. Eligible businesses can also configure incoming USDC payments to settle as USD.
Businesses can create a payment link for a specified amount and share it through a URL or QR code.
Each link is designed for a specific payment request and can provide a straightforward way to collect stablecoin payments without developing a custom checkout flow.
Coinbase Business also supports invoicing.
Businesses can create invoices with customer information, line items, taxes, payment amounts, and due dates. Recurring invoicing and payment-status tracking support ongoing commercial relationships beyond one-time checkout.
Developers can use Coinbase Business APIs to automate payment and account workflows.
API functionality supports payment collection and other business account operations without requiring staff to initiate every action manually.
This makes Coinbase Business closer to a managed financial platform than the self-custody Commerce product it replaced.
The distinction between receiving cryptocurrency and accepting merchant payments is important.
Coinbase Business accounts can hold and receive multiple supported assets, but the formal Payment Links and Invoices experience currently centers on USDC across supported networks.
Bitcoin and other cryptocurrencies can still be transferred into a Coinbase Business account, but a general asset transfer is not the same as using the platform's structured merchant payment workflow.
Merchant payments add functions such as:
Businesses evaluating Coinbase Business should therefore distinguish general crypto account functionality from the payment products available to customers.
Coinbase Commerce emphasized self-custody.
Coinbase Business uses a custodial model, meaning Coinbase holds assets associated with the business account.
This changes the operational tradeoff.
Custody can reduce the need for merchants to manage private keys and manually move funds between wallets, exchanges, and bank accounts. At the same time, merchants rely on Coinbase as the custodian and operate within the platform's account, compliance, and withdrawal framework.
Businesses specifically looking for self-custody should not assume Coinbase Business preserves the structure of the former Commerce product.
Coinbase Business is available only to eligible businesses in supported jurisdictions.
Onboarding requires business verification and supporting documentation, and eligibility depends on factors such as company type, location, and compliance requirements.
That distinction matters for global payment strategies.
Stablecoins themselves can move across borders, but access to a managed merchant platform still depends on the provider's business eligibility rules and supported regions.
A customer may technically be able to send an onchain payment from another country while the merchant still needs to qualify for the underlying business account.
Coinbase's broader developer infrastructure also supports machine-to-machine payments through x402.
x402 allows a paid HTTP resource to return a payment requirement that a compatible client can satisfy programmatically. This model is relevant for APIs, digital resources, and AI agents that need to transact without a conventional checkout session.
Coinbase's payment infrastructure also supports programmatic authorization for machine-readable payment flows.
This is useful for AI commerce, but two separate payment problems still need to be considered.
A provider selling an API, tool, model, or digital resource needs to determine:
An autonomous agent also needs rules governing its ability to spend:
Accepting a machine payment and controlling the machine making that payment are distinct parts of agentic commerce.
Conventional merchant payment infrastructure is designed primarily to collect funds.
Autonomous AI transactions can require additional layers around the payment itself.
An agent may need to purchase an API call, dataset, model inference, MCP tool, or another agent's service while completing a larger task. The transaction needs to happen inside the software workflow while still respecting the owner's financial limits.
Financial authorization should remain separate from ordinary API access.
An agent can operate under delegated payment permissions that define a finite spending limit and expiration rather than exposing unrestricted card credentials.
Optional transaction limits can add another boundary around autonomous purchasing. Raw card information remains outside the agent's control and is tokenized before reaching the payment infrastructure.
The seller side has a different challenge.
AI services may need to charge according to requests, tokens, time, complexity, or another workload-specific metric.
Infrastructure supporting multiple payment models can apply credits-based, time-based, dynamic, or hybrid pricing according to the service being sold.
The commercial model can therefore remain attached to the AI workload rather than treating every transaction as a fixed checkout amount.
Enterprise agent deployments may involve several teams and autonomous systems using centrally managed company funds.
In that environment, individual agent permissions are only one layer of control.
Organizational groups and budgets can create separate spending ceilings for different teams or workloads while allowing them to operate against shared funding.
This keeps autonomous execution within limits established by the organization.
Stablecoins are useful for programmable machine payments, but many businesses and consumers still keep much of their spending power in conventional card and banking systems.
AI payment infrastructure may therefore need to support both.
A service purchased from an existing merchant might already accept cards. A machine-native API may prefer onchain settlement.
For fiat-funded workflows, fiat payment patterns can use card-based payment infrastructure for autonomous transactions.
For crypto-native services, stablecoin payment flows can support USDC, EURC, and other supported ERC-20 assets.
The important distinction is that the payment rail does not need to define the product.
The same AI service can apply its pricing and entitlement rules while supporting different funding methods for different buyers.
Nevermined focuses on connecting autonomous spending with monetization infrastructure for AI services.
Instead of treating checkout as the complete commercial workflow, Nevermined connects buyer authorization, seller access rules, pricing, metering, and settlement.
An API, agent, MCP tool, or protected resource can use a payment and entitlement layer to verify that a caller has the required commercial access before performing paid work.
This is particularly relevant when fulfilling the request creates meaningful compute, model, or third-party costs.
The service can validate access first, execute the workload, and then settle according to the attached plan.
Nevermined's multiple payment models support several ways to commercialize AI workloads.
These include credits consumed per request, time-based access, dynamic pricing based on complexity or another application-defined metric, and hybrid plans combining access periods with usage limits.
This allows one platform to monetize different services according to their own economics.
On the buyer side, the Nevermined Router lets agents pay compatible external services using delegated financial authority.
The agent operates under a defined spending cap and expiry, while the infrastructure enforces those limits independently of the model's reasoning.
Supported transactions can be recorded in one unified ledger, giving organizations a consolidated record of autonomous spending.
Stable request identifiers can also help prevent a retry of the same logical purchase from creating an unintended second payment.
Not every autonomous buyer needs a cryptocurrency wallet.
Delegated payment permissions can let a payment source fund separate agent delegations with defined spending ceilings and expiry periods.
The underlying card data remains outside the agent's possession while the payment infrastructure enforces the delegated financial boundary.
This gives agents the ability to transact without receiving unrestricted access to the owner's payment credentials.
For onchain services, stablecoin payment flows provide another settlement path.
This is useful for machine-readable services that already operate with stablecoins or need programmable onchain payments as part of the workflow.
The pricing and entitlement model can remain attached to the service regardless of which supported payment rail funds the transaction.
Larger deployments can combine agent-level permissions with shared payment methods and group budgets.
That allows teams to use centralized company funding while maintaining separate spending ceilings for different organizational units.
The financial policy remains outside the model's reasoning, so an agent cannot simply decide to exceed the configured limit.
Nevermined maintains payment security controls that include a SOC 2 Type II attestation report, ISO/IEC 27001:2022 certification, and PCI SAQ-D controls.
Raw card information is tokenized through PCI-compliant payment infrastructure before reaching Nevermined's systems.
These controls support the payment layer while AI service providers remain responsible for their own application security, data governance, and regulatory requirements.
Builders can begin with a working payment integration for an agent API, MCP tool, or protected resource.
The integration separates validation from settlement so commercial access can be checked before the workload runs and the applicable charge can be settled after successful execution.
Teams can then add service-specific pricing, metering, organizational controls, and reporting as the application moves toward production.
Coinbase Business and agent-native payment infrastructure solve overlapping but different commercial problems.
For merchant and stablecoin-payment operations, businesses should evaluate:
Agent-based commerce introduces another set of requirements:
The central distinction is not simply cryptocurrency versus fiat. It is conventional merchant acceptance versus payment infrastructure designed to govern autonomous economic activity on both sides of a transaction.
A paid AI service needs a way to communicate its price, verify the buyer's payment or entitlement, deliver the protected resource, and record settlement. The commercial unit might be an API request, credit, subscription period, or completed workflow. A payment and entitlement layer can connect those commercial rules directly to the protected service. The provider should also define how failures, retries, and incomplete work affect billing.
The agent can operate through a delegated financial permission with a fixed spending ceiling and expiration. The underlying funding credential remains separate from the agent, while the payment infrastructure determines whether each proposed transaction fits the approved authority. Delegated payment permissions can apply this model to card-funded transactions. Similar delegation principles can govern stablecoin-funded workflows.
Yes. Pricing and entitlement can remain separate from the funding rail. Card-funded buyers can use fiat payment infrastructure, while wallet-based buyers can use supported stablecoin settlement. Stablecoin and fiat payments can support different payment paths around the same underlying AI service. The provider can then choose which methods make sense for each customer group.
Individual delegations can limit one agent, while organization-level budgets can establish broader ceilings across teams. Centralized funding can then be shared without giving every agent unrestricted access to the entire balance. Groups and budgets provide one way to separate organizational funding from team-level spending authority. Clear attribution also helps finance teams understand which agents and workflows are generating each expense.
Automated systems frequently retry requests after timeouts, network failures, or incomplete responses. The payment layer should use a stable identifier for the logical purchase so the same request is not accidentally charged twice. The agent payment router can combine bounded spending controls with a unified transaction record for supported machine payments. This helps distinguish a retry from a genuinely new purchase while preserving a clear record of autonomous spending.
See Nevermined
in Action
Real-time payments, flexible pricing, and outcome-based monetization—all in one platform.
