A virtual card can exist as soon as an issuing platform creates the card record and returns its credentials. A physical card has to be designed, manufactured and shipped. That difference makes “instant card issuance” useful, but it does not make the rest of a card programme instant.
The programme still needs an issuer or issuing provider, verified cardholders, funding, authorisation rules, card-data controls and a way to manage the card after launch. The fast part is the virtual credential.
What instant card issuance means
Instant card issuance usually means creating a virtual payment card through an API and making its details available to an eligible user without waiting for plastic.
Stripe documents separate flows for virtual and physical cards. Its virtual-card guide begins with creating a cardholder and then issuing a virtual card. Adyen says a virtual card has no physical form and returns card details in the API response; creating a physical card starts a manufacturing order instead.
That distinction matters for product teams. A virtual-first programme can give an approved user a usable credential early, while a physical card follows later if the use case needs one. The approach works for expense cards, procurement, marketplace payouts and other controlled-spend products, but only after the programme’s legal and operational setup is ready.
The minimum object model
Issuing platforms use different names, but their resources tend to follow the same dependency chain.
| Resource | What it represents | Why it comes first |
|---|---|---|
| Account holder or cardholder | The person or company allowed to receive cards | The programme must know who is using the credential |
| Balance or funding source | The money or credit available to spend | A card without funds or credit cannot settle purchases |
| Card product or programme | Shared settings for a class of cards | It defines network, form factor and programme rules |
| Card | The individual virtual or physical credential | It is created for an eligible holder under the programme |
| Controls and lifecycle state | Limits, merchant rules, active or suspended state | They determine where the card can be used and how it changes |
Marqeta’s API shows this hierarchy directly: a card is derived from and controlled by a card product, and card-level settings can override values inherited from the product. Adyen requires an account holder and balance account before card creation. These are implementation details, but they reveal the product decision behind them: create reusable policy at programme level, then apply exceptions only where necessary.
Virtual-first does not mean controls later
A card should not become active before its controls are defined.
Stripe’s Issuing documentation supports limits, merchant-category restrictions and geographic controls. It also supports real-time authorisation through webhooks. Those features can reduce the exposure of a newly issued credential, but they add runtime dependencies. If a programme makes authorisation decisions in its own service, latency, availability and fallback behaviour become part of the card product.
A practical launch sequence is:
- verify and create the cardholder;
- connect the holder to the correct funding source;
- apply programme and card-level limits;
- create the virtual card;
- expose card data only through an approved secure interface;
- test authorisation, reversal, refund and dispute paths;
- activate the card when the product is ready to support it.
The API call that creates the card sits in the middle of this sequence. It is not the start or the finish.
Card data changes the security boundary
Adyen’s documentation says virtual-card details are returned in the API response. That creates an immediate design question: which systems and people can see the primary account number, expiry date and security code?
The answer affects PCI scope. Adyen explicitly says the scope depends on the use case, including the type of cards and how they will be used. A product that reveals raw card data in its own interface may have different obligations from one that uses the issuing provider’s hosted components or secure SDKs.
Treat card-data display as its own feature. Give it a separate threat model, access policy and audit trail. Do not assume that creating a card through an API also solves safe presentation of its credentials.
Physical fulfilment is a separate workflow
A physical card adds design approval, manufacturing, personalisation, inventory and shipping.
Adyen requires the physical card and mailer design to be approved by Visa or Mastercard before live creation, and says a physical-card request starts a manufacturing order. Stripe separates physical-card design and shipping from virtual-card creation in its documentation.
That means a virtual-first launch should track two lifecycles:
- credential lifecycle: created, activated, suspended, replaced or closed;
- fulfilment lifecycle: design approved, ordered, personalised, shipped, delivered or returned.
They can move independently. A user may spend with a virtual card while a physical card is in transit. A replacement physical card may share an account relationship but still require deliberate credential and wallet decisions.
What to test before launch
A sandbox purchase is only one part of an issuing test plan.
Test the states that are awkward in production:
- cardholder verification fails or remains pending;
- funding is unavailable;
- the card is created but not activated;
- a limit blocks a purchase;
- an authorisation times out;
- a merchant submits an incremental or reversed authorisation;
- the card is suspended after it has been added to a digital wallet;
- a physical card is lost before activation;
- a credential is replaced after suspected compromise.
Stripe recommends simulating purchases before going live and documents separate handling for authorisations, transactions, refunds and disputes. The test plan should follow that full lifecycle.
Choosing an issuing platform for instant issuance
“Can it create a virtual card?” is a weak selection question. Most modern issuing stacks can.
Ask instead:
- Which countries, currencies and programme types are actually available?
- Who is the regulated issuer, and which party owns compliance decisions?
- How are holders verified?
- Can controls be set before activation?
- How are card details revealed without expanding PCI scope unnecessarily?
- What happens when the real-time authorisation service is unavailable?
- How are physical cards designed, shipped and replaced?
- Which webhooks and reports reconcile authorisations, clearing and refunds?
- Can card and programme settings be versioned and audited?
Our guide to choosing an issuer processor covers the vendor questions behind that decision. For the regulated relationship, see BIN sponsorship. The card issuing platforms guide maps the wider stack.
