Embedded Payments & Virtual Cards: What They Are and How They Work

A payment doesn’t have to happen in a banking app or be handled manually elsewhere. It can be built directly into the product — for example, when a supplier invoice is approved, a booking is confirmed, or a business expense needs to be paid.

With embedded payments, paying becomes part of the action the user is already performing. Virtual cards are one way to handle these payments. A card can be created when it is needed, used for a specific payment, and managed in the background.

In this article, the CardsPro Team explains how embedded payments work with virtual cards, where this model is already used, what happens on the platform side, the main ways cards can be set up, and what businesses need to consider before using them.

Embedded payments let users make payments directly inside the product they are already using. For example, an invoice can be approved and paid in the same system, or a booking can trigger payment to a supplier without opening a banking app.

One way to do this is with virtual cards. The platform can create a card for a specific payment and use it in the background instead of relying on an existing company card or bank transfer.

An embedded virtual card is a virtual card used directly inside an embedded payment flow. It can be created for a specific invoice, booking, order, supplier, or other payment and managed directly by the platform.

1. Procurement and supplier payments. SAP Ariba can issue a single-use virtual card for a specific purchase order. Once the order is approved, the card is created with a set amount and expiration date, and the supplier uses it to receive payment.

2. ERP and accounts payable. SAP-Embedded Visa Virtual Cards let companies pay approved supplier invoices directly from the ERP system. The payment is created and processed there, without moving the invoice into another payment flow.

3. Travel and booking platforms. A travel platform can issue a virtual card for a specific booking and use it to pay a hotel or another supplier. The card can be limited by amount, validity period, and other rules linked to that booking.

4. Marketplaces. A marketplace can use virtual cards to pay suppliers that fulfill customer orders. If one order involves several suppliers, the marketplace can issue a card for each supplier, set the required amount, and link each payment to the original order.

Expense management and accounts payable platforms can use the same model.
The user does not always see the card itself. In some products, the card is visible and can be managed directly. In others, it works in the background while the user only sees the booking, invoice, or order.

The flow looks like this:

An order, booking, or invoice is approved → the platform requests a virtual card → the card is issued with the required amount and restrictions → the supplier charges it → transaction data returns to the platform.

Card creation can be triggered by approving a purchase order, confirming a booking, or approving an expense. The user does not need to click “Issue card” — the platform can create it automatically when the required conditions are met.

The platform sends the payment details to the issuing infrastructure and requests a virtual card. In SAP Ariba, which we mentioned earlier, this happens after a purchase requisition is approved and becomes a purchase order: the system can then request a card for that payment.

The card can be issued with a fixed amount, expiration date, and restrictions on where it can be used.

It can also stay linked to the original booking, invoice, or purchase order. This allows authorizations, captures, refunds, and other transaction data to be matched back to the same record instead of reconciled manually later.

Cards can be assigned in several ways.

— One card per transaction. A single-use card is created for one payment. As in the SAP Ariba case above, a purchase order can have its own virtual card with a fixed amount and expiration date.

— One card per booking or order. The card stays linked to one booking or order and can be used for several related charges. This is common in travel, where a hotel may place a hold, charge the card later, add another charge, or issue a refund.

— One card per supplier or merchant. A platform can use a dedicated virtual card for payments to one supplier or service. This keeps recurring payments separate and easier to control. The same model works for SaaS subscriptions, which we covered in our guide to virtual cards for SaaS.

— One card per user or spending purpose. A platform can issue a card to an employee, contractor, or customer and set spending limits or other rules for that card.

Embedded virtual cards do not have to be single-use. A card can be created for one payment, one booking, one supplier, or one user.

Virtual cards give the platform more control over how each payment is made. Instead of routing different expenses through the same company card or bank account, the platform can create a card for a specific expense and set the rules in advance.

— Payment stays inside the product. A company can approve an invoice, booking, or purchase and complete the payment without switching to a banking app.

— Each payment can be tied to a specific purpose. The platform can assign a card to a supplier, booking, invoice, or order.

— Spending limits and restrictions can be set in advance. The card can be limited by amount, merchant, category, time, location, or other parameters supported by the card program.

— Reconciliation becomes simpler. If the card is linked to the order or booking that created it, the resulting transaction can be matched back to the same record automatically or with less manual work.

— Supplier payments can be automated. This is useful for procurement, accounts payable, marketplaces, and travel platforms, where the system already knows who needs to be paid, how much, and for what.

The platform needs card-issuing infrastructure, a way to fund the cards, an account or cardholder structure, and access to transaction data.

The platform defines what creates a card, what the user sees, what limits apply, and what the card is linked to.

This can be built on top of a card issuing API. CardsPro provides the infrastructure for issuing and managing virtual cards, while the platform decides when the cards are created and how they are used.

Automatic card creation does not remove onboarding and compliance requirements.

These requirements depend on the issuer, country, program, and account structure. They may include company or cardholder verification, KYC or KYB, issuer approval, acceptance of issuing terms, and limits on who can receive cards and how they can be used.

Stripe Issuing is one example. For connected accounts, the platform must show the relevant Stripe and issuing-bank terms, collect the user’s agreement, and keep a record of that consent. Stripe and the issuing bank must approve the account before cards can be issued.

SAP Ariba uses a different setup. The buyer first needs a virtual-card account with the issuer or bank, and suppliers must be enabled for virtual-card payments.

Cards can then be created automatically without asking for approval each time. The required consent, verification, and approvals are handled earlier, when the company or cardholder joins the card program.

Embedded virtual cards are not available in every country or for every type of business. Local regulation and provider rules determine where cards can be issued and which businesses can use them. Stripe, for example, limits Issuing by jurisdiction and does not support some types of card programs.

Some providers also require a specific setup before a platform can issue cards for customers, employees, or contractors.

Merchant acceptance is another limitation. Some suppliers do not accept commercial or virtual cards, while others require a separate process to handle them. Visa, for example, offers tools to automate virtual-card acceptance and supports B2B payment models for suppliers that do not accept commercial cards directly.