What Happens at Checkout When a Payment Needs Extra Verification

You buy a train ticket on a site you have used before. You press pay, a small window opens in your bank’s app, you tap approve, and the confirmation page appears. From your side, that is one extra step.

Behind it, the payment went through a short exchange between the merchant, the card network, and the card issuer. The issuer made a risk decision, and the merchant had to be ready for either outcome.

The issuer makes the call

The decision that matters is not made by the merchant. In the 3-D Secure protocol that most card checkouts use, the issuer’s access control server evaluates the transaction and decides whether it can proceed without a challenge or needs one. The merchant can send information to help that decision, but the issuer decides.

For example, a shopper buys from a store they have used twice before, on the same laptop, for an amount close to their usual. The issuer sees a familiar pattern and can approve without a prompt. The same shopper buying a larger amount from a new device at 2 a.m. gives the issuer a reason to challenge.

Two paths, one decision

The frictionless flow completes the authentication in the background. The shopper sees no prompt, and the payment moves on to authorization.

The challenge flow asks the shopper for proof. The prompt might be an approval in the bank’s app, a one-time passcode, or a biometric check on a device the shopper already trusts.

A third variant, the out-of-band flow, moves the challenge into the bank’s own app, outside the protocol. For example, the shopper approves the purchase in the bank’s app, and the checkout waits for that approval to come back. The merchant has to handle that wait without treating silence as a refusal.

What the merchant sends changes the outcome

The merchant does not choose the path, but it does shape the information the issuer uses. Our post on types of MFA used in online banking compares the factors a challenge can use. For example, a checkout that sends a consistent billing name, address, and account history gives the issuer more to work with than one that sends partial details.

• Billing details: consistent with the card on file.
• Account history: a returning customer with past clean transactions.
• Device data: collected during checkout through the protocol’s browser method.
• Transaction type: correctly labeled, so the issuer does not evaluate a recurring payment as a new one.

In general practice, merchants that send complete, consistent data see fewer unnecessary challenges. The effect is measured per merchant, not assumed.

When the challenge reaches the shopper

A challenge is only useful if the shopper can complete it. When it fails, the cause is usually at the checkout, not the bank.

Picture a shopper who receives the bank prompt, but the checkout page has timed out and has no way to resume. The payment fails, and the shopper assumes the card was declined. A clear message and a way to retry without losing the cart prevent most of those losses.

• Timeout: the session expires before the shopper responds. Show what happened and allow a retry without re-entering the cart.
• Abandoned challenge: the checkout page never presents the challenge. The authentication should be treated as failed, and the shopper should be told why.
• No bank app: a shopper with only a card and no app needs another option, such as a text code that actually arrives.

Exemptions narrow the choice in the UK and EU

Within the European Union and the United Kingdom, the strong customer authentication rules require two independent elements for electronic payments. For remote payments, the code must be dynamically linked to the amount and the payee, so a code for one payment cannot be used for another.

Those rules also allow exemptions from full authentication in defined cases. For example, a low-value payment may qualify, but the provider’s risk analysis still has to hold, and the exemption is not a guarantee of a frictionless flow. Outside these regions, the requirements differ, and issuers and card schemes rely more on their own risk models and program rules.

Checkout friction is a measured trade-off

Every challenge is a decision with two costs. Too few challenges, and fraud reaches the merchant. Too many, and genuine customers leave the page. Neither cost is visible in isolation.

For example, a merchant that raises its challenge rate to stop a fraud wave may also lose a share of genuine buyers. The useful measures are the frictionless rate, the challenge completion rate, abandonment after a challenge, and fraud on approved payments.

Where OmniDefend’s e-commerce capability fits

OmniDefend’s secure online experience offering lists a password-less website login and secure e-commerce transactions. Its customer identity offering describes multi-factor identification for customer transactions, online or on-premise, with transaction verification that can be called from a merchant’s own applications.

For example, a merchant using the password-less login for returning shoppers still gets the issuer’s decision on each card payment. These capabilities sit at the authentication step. They do not change the card network’s protocol or the issuer’s decision, so a merchant still needs its own checkout design for timeouts, abandoned challenges, and retries.

Test a checkout with real cases

The most useful test is a set of real cases run through your own checkout, not a demo. Start with these five cases:

1. A returning customer on a familiar device, expecting a frictionless approval.
2. A larger amount from a new device, expecting a challenge.
3. A challenge the shopper completes on the first try.
4. A challenge the shopper abandons halfway, to confirm the retry path works.
5. A card with no bank app, to confirm the fallback option arrives.

OmniDefend’s sales team sets up the 30-day free trial, so the test runs on your own checkout rather than a sandbox. Start the free trial, or request a demo to see the e-commerce capability first.

Frequently asked questions

• Why did my bank ask me to confirm a purchase I was already making?

The issuer’s risk analysis judged the payment unusual for your account or device. The prompt is the bank confirming that you, and not someone holding your card details, are authorizing it.

• What happens if I do not finish the challenge in time?

The payment normally fails or is abandoned. A well-built checkout lets you retry without losing the cart.

• Does a challenge mean the merchant thinks I am a fraudster?

No. The issuer makes the challenge decision from its own risk analysis. The merchant sees the outcome but does not choose the path.

• Why did checkout skip the extra step this time?

The issuer judged the payment low risk, or an exemption applied. Exemptions depend on the amount, the payment type, and the region, so the behavior can differ between countries and merchants.

• Can a merchant turn off extra verification?

A merchant can send better data and handle outcomes well, but it cannot override the issuer’s decision. Trying to route around the check moves the fraud risk back onto the merchant.

Resources

• Verifone, 3-D Secure 2 knowledge base, UK Gateway (frictionless and challenge flows)
• Cielo, Payment authorization flow with 3DS authentication
• Commission Delegated Regulation (EU) 2018/389, Chapter II (strong customer authentication)