MENU
Stripe Issuing provides infrastructure for businesses and platforms to create and manage virtual and physical payment cards. Its APIs cover card creation, cardholders, spending controls, authorization decisions, transaction monitoring, digital wallets, and program funding. Stripe reports that more than 350 million cards have been created through Issuing.
Card infrastructure is also becoming relevant to autonomous software. The IMF's agentic payments analysis describes a shift toward software acting on users' behalf in financial transactions, which increases the importance of delegated authority, safeguards, and accountability. For companies evaluating agentic payments infrastructure, Stripe Issuing represents one approach to controlling card-based spending within that broader payment stack.
Stripe Issuing is programmable card infrastructure for businesses that need to create and manage commercial card programs. Cards can be assigned to employees, contractors, customers, platform users, or software-controlled workflows, depending on the program configuration.
Stripe manages the underlying card-network and issuing-bank relationships while the business defines how cards are created and used.
Stripe Issuing includes:
Current U.S. pricing lists virtual cards at $0.10 each and standard physical cards at $3.50 each before shipping. Customized physical-card programs have separate costs and requirements.
An Issuing program generally requires a business to complete Stripe's onboarding, establish the appropriate funding structure, create cardholders, and issue cards.
Funding options vary by program and eligibility. Stripe documents external-bank funding, transfers from Stripe balances, and other funding arrangements rather than requiring every Issuing customer to use the same prefunded model.
Teams should therefore evaluate the funding structure available to their account and use case rather than assuming all Stripe Issuing programs work identically.
Virtual cards remove the manufacturing and shipping requirements associated with physical credentials. They can be created through the Dashboard or API and managed programmatically as spending requirements change.
This makes them applicable to employee expenses, supplier payments, purchasing automation, platform workflows, and some autonomous-agent use cases.
Stripe allows controls to be applied at the card or cardholder level.
Depending on the configuration, policies can include:
These rules are evaluated as part of the authorization process. Businesses can therefore block transactions that fall outside an approved spending policy before the purchase completes.
For software acting on behalf of users, a similar principle applies to delegated financial authority. Infrastructure can delegate a spending budget while keeping the underlying payment method outside the agent's direct control.
Virtual cards can also be assigned to defined vendor or purchasing workflows.
A business might create a card for a particular supplier, category, budget, or operational task, then reconcile the resulting transaction against internal records. The Federal Reserve's B2B payments research highlights the broader shift toward automated payment and reconciliation processes as businesses digitize their financial operations.
The usefulness of virtual cards in these workflows depends on whether the recipient accepts card payments and whether the organization's controls can be expressed through the available authorization rules.
Virtual and physical cards have different operational requirements.
Virtual cards can be created after the Issuing program and cardholder structure are established. Physical cards add production, shipping, and, for customized designs, approval requirements.
Standard physical cards can use Stripe's available designs and branding options. Fully customized programs require additional design, network review, manufacturing, and minimum-order planning.
Stripe currently describes custom physical-card launches as an approximately 8-to-10-week process, depending on complexity.
Virtual cards are simpler operationally because no manufacturing or delivery is required. They are therefore more suitable when credentials need to be created, updated, or deactivated frequently.
Stripe exposes APIs for cardholders, cards, spending controls, transactions, and authorizations.
Applications can use them to:
Real-time authorization webhooks add another decision layer. When supported, Stripe can send an authorization request to the application before the transaction completes, allowing custom business logic to approve or decline it.
Card issuance is only one part of a corporate-spending workflow. Organizations also need to consider funding, policy enforcement, reconciliation, geographic availability, and the operational systems surrounding each card.
Relevant questions include:
Stripe Issuing exposes many of these controls through APIs, but availability and program structure can vary by geography and eligibility.
Stripe Issuing should not be treated solely as a prepaid card product.
Stripe documents multiple approaches to funding card activity, including external funding and eligible credit or post-funding arrangements. Specific options depend on the business, geography, and program.
Companies comparing Issuing with traditional corporate cards should therefore evaluate available funding terms separately from the card-management technology.
Stripe Issuing handles outbound card credentials and transaction controls. Other parts of a commercial payment stack, such as accepting customer payments, operating marketplace payouts, billing customers, or managing bank accounts, may involve different Stripe products or external systems.
This distinction matters because issuing a payment credential does not determine how every commercial interaction should be priced, metered, or settled.
Authorization and transaction events can be connected to internal applications through APIs and webhooks.
A business can attach internal identifiers to cards, evaluate authorization requests against policy, and reconcile completed purchases against their underlying business purpose.
For AI services, pricing can require a different mechanism when the amount depends on the workload rather than a known merchant purchase. Usage-based pricing patterns can connect charges to tokens, complexity, time, or consumption when a static card authorization does not represent the full commercial model.
Stripe now documents Issuing for agents, currently in private preview.
The product applies Issuing infrastructure to software agents by allowing businesses to create virtual cards for individual agents and control how those cards can be used.
Current documented capabilities include:
An application can therefore evaluate the context of an agent purchase and determine whether an attempted transaction should be approved.
This is an important update to earlier descriptions of Stripe Issuing. It is no longer accurate to say that the platform lacks agent-specific card controls or real-time authorization mechanisms.
A controlled virtual card addresses purchases made through card-accepting merchants. Some machine-to-machine transactions have different requirements.
An API, agent, or MCP tool may charge based on tokens, requests, compute, time, or another unit determined during execution. The seller may also need to verify payment authorization before starting the workload and settle the resulting amount without relying on a conventional merchant checkout.
The BIS analysis of AI agents in payment systems highlights similar questions around autonomous decision-making, liquidity constraints, payment priorities, and safeguards.
For agent deployments involving multiple users or business units, shared payment methods can also be paired with group-level budgets rather than managing every agent as an independent cardholder.
Card issuing creates obligations around payment credentials, authorization systems, access controls, and transaction records.
Stripe is certified as a PCI Level 1 Service Provider and produces SOC 1 and SOC 2 Type II reports. A customer's own compliance scope still depends on how its application handles card information and interacts with Stripe.
Reducing exposure to raw card credentials is an important part of card-program design.
The PCI Security Standards Council describes payment tokenization as a way to replace primary account numbers with alternative values within supported payment environments. This can reduce the amount of sensitive card data exposed across downstream systems.
Businesses still remain responsible for securing their own API keys, webhooks, administrative access, applications, logs, and any payment information that enters their environment.
Stripe Issuing combines predefined spending rules with real-time authorization logic.
Amount limits and merchant restrictions can reject purchases outside the expected policy. Where real-time authorization is enabled, businesses can add application-specific decision rules before approving a transaction.
For autonomous agents, the same principle is particularly important. Financial boundaries should be enforced by infrastructure rather than relying on the model to remember or interpret its spending limits correctly.
Stripe Issuing provides programmable card infrastructure and now extends those controls to selected agent-spending use cases. Nevermined focuses on the broader commercial workflow in which agents spend autonomously and AI services charge other software for access or work.
Nevermined lets users enroll existing payment methods and grant agents bounded authority to use them.
A delegation can define a budget, expiration period, transaction limit, API-key restriction, and revocation policy. The agent receives scoped payment capability rather than the underlying raw card number.
These card delegation controls make spending limits part of the payment infrastructure rather than a behavioral instruction given to the agent.
The seller side of an agent transaction can require pricing that changes with the work performed.
Nevermined supports usage-based pricing patterns based on tokens, request complexity, elapsed time, usage tiers, and application-defined metrics.
This allows an API, model, or tool to price the underlying workload rather than translating every service into a conventional retail card purchase.
Nevermined provides x402 infrastructure for APIs, agents, MCP tools, and other protected services.
A resource can return HTTP 402 payment requirements, receive signed authorization, verify the applicable permissions, execute the workload, and settle afterward. The x402 facilitator overview covers the verification and settlement layer behind this flow.
Nevermined supports both crypto smart-account transactions and delegated card-payment schemes, allowing the authorization model to operate across different payment rails.
Agent deployments often involve more than one card or buyer.
Nevermined's groups and budgets let organizations associate shared funding with groups while enforcing separate spending ceilings. Its payment observability tools connect commercial activity with request, usage, cost, and performance data.
This creates a policy layer above individual agents and transactions.
Nevermined publicly documents SOC 2 Type II auditing, ISO 27001 certification, PCI SAQ-D compliance, and GDPR controls through its security and compliance resources.
Card information is tokenized before entering Nevermined systems, while agents operate using scoped payment permissions.
These controls support security and procurement reviews for teams deploying agent-payment infrastructure in production.
Nevermined currently charges 1% to 2% of settled transaction volume with no setup fees or minimums. Its free personal account supports up to 20 agents and 10 payment plans, with organization plans available for larger deployments.
The quickstart documents a working payment integration in five minutes for an agent API, MCP tool, or protected resource. Teams can begin with authorization and settlement, then add workload pricing, delegated spending, organizational budgets, and observability as needed.
For AI products where payment is part of the agent workflow itself, Nevermined connects spending authority, service pricing, payment verification, metering, and settlement in the same commercial layer.
A card issuing platform provides infrastructure for businesses to create and manage payment cards for approved cardholders or software-driven workflows. It can include virtual and physical cards, spending controls, authorization processing, cardholder records, and transaction monitoring. Funding options, geographic availability, and compliance responsibilities vary by provider and program.
Virtual cards can be issued for specific employees, suppliers, budgets, or transactions without distributing a physical credential. Businesses can apply restrictions around amounts, merchant categories, countries, or usage periods. These controls help keep spending policy attached to the payment credential rather than relying only on reimbursement or manual review.
Agents can use payment cards when the surrounding infrastructure allows programmatic purchasing and gives the agent appropriate financial authority. Safer implementations place hard spending rules outside the model so the agent cannot exceed the authority granted to it. Users can delegate a spending budget when an agent needs bounded card-funded purchasing authority.
Useful controls include overall budgets, per-transaction limits, expiration, credential scope, merchant restrictions, revocation, and auditable transaction records. Organizations running multiple agents may also need shared funding with separate group-level ceilings. The main objective is to preserve agent autonomy without making financial authority unrestricted.
Virtual cards are appropriate when an agent needs to purchase from a merchant that already accepts cards. Machine-accessible services can require additional functions such as request-level authorization, metering, usage-based pricing, credits, and software-to-software settlement. A working payment integration can place those commercial checks directly around an API, MCP tool, or protected resource.
See Nevermined
in Action
Real-time payments, flexible pricing, and outcome-based monetization—all in one platform.
