3D Secure for Virtual Cards: How Authentication Affects Payments

When you pay online with a virtual card, the payment may go through immediately or ask for additional confirmation — for example, a code, a push notification, or approval in a banking app.

That confirmation is 3D Secure. But 3DS does not always require an extra action: authentication can also happen in the background, without interrupting checkout.
In this article, the CardsPro Team explains what happens after you click Pay, how 3D Secure works, and where authentication ends and authorization begins.

3D Secure, or 3DS, is used to authenticate online card payments. When 3DS is triggered, the issuer receives information about the transaction and decides whether additional confirmation is needed.

If it is, the cardholder may receive an SMS code, a push notification, or a request to approve the payment in a banking app. If no extra check is needed, 3DS can complete without any action from the cardholder.

3DS handles authentication, not the final payment decision. After authentication, the transaction still goes through authorization.

— Authentication checks whether the transaction can be trusted and, when needed, asks the cardholder to confirm it. This is the role of 3D Secure.

— Authorization comes next. The issuer decides whether to approve the payment based on available balance, card limits, card status, merchant and country restrictions, and risk rules.

That means successful 3DS authentication does not guarantee approval. The cardholder may pass 3DS and still receive a decline because of insufficient funds, exceeded limits, or another authorization rule.

With frictionless 3DS, the ACS completes authentication without asking the cardholder to confirm the payment. The payment then continues to authorization without an OTP, push notification, or confirmation screen.

CardsPro, for example, supports Silent 3DS on a number of BINs. For eligible transactions, 3DS authentication can complete without any action from the cardholder.

If the issuer requires additional verification, the ACS starts a challenge.
The cardholder may need to enter a one-time code, approve a push notification, confirm the payment in a banking app, or use another verification method supported by the issuer.

If the challenge is completed successfully, the transaction proceeds to authorization. If it fails, expires, or is abandoned, authentication is not completed.

The same virtual card can pass one payment frictionlessly and receive a challenge on another. The issuer evaluates each transaction separately based on its data and risk rules.

Once 3DS starts, several outcomes are possible.

• Authentication completes frictionlessly. Nothing appears on screen, and the transaction moves on to authorization.
• A challenge appears and the cardholder completes it. Authentication succeeds, and authorization follows.
• The challenge is not completed. The user may enter the wrong code, ignore the request, close the page, or let the session expire. The payment may stop at the authentication stage.
• 3DS succeeds, but authorization fails. Authentication was successful, but the issuer declines the payment for another reason, such as balance, limits, card controls, or risk rules.
• The payment gets a soft decline and is retried with 3DS. The issuer may require authentication before approving the payment, so the merchant runs 3DS and resubmits the transaction.

A successful 3DS check does not guarantee approval. And if the issuer requires authentication during authorization, the merchant may need to run 3DS and submit the payment again.

If your business issues virtual cards under its own brand or embeds card issuing into a product, 3D Secure becomes part of how your users pay with those cards. A transaction may pass silently, require confirmation from the cardholder, or stop at the authentication stage before authorization begins.

The exact flow depends on the issuer, BIN, ACS, and authentication rules. Some transactions can complete through frictionless or Silent 3DS, while others require a challenge by SMS, push notification, or confirmation in a banking app.

Recurring payments work differently. The first payment or card setup may require 3DS because the cardholder is actively making the transaction. Later subscription charges can be submitted as merchant-initiated recurring payments, so a new 3DS challenge is usually not required for every charge. For SaaS and other subscription products, this means the initial payment and subsequent recurring charges may follow different authentication flows.

For businesses issuing cards through an API, the 3DS result in transaction data or webhooks lets the product distinguish between successful authentication, a challenge, failed or expired authentication, and a payment that later failed at authorization. The exact statuses depend on the issuing platform, but this data helps show the right message to the user and identify where the payment failed.