,

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.

Path

What the shopper sees

Who decided

What it protects against

Frictionless

Nothing, the purchase continues

The issuer’s risk analysis

Little, on a low-risk payment

Challenge

A prompt in the bank’s app or a code

The issuer, on a higher risk score

A payment made with stolen card details

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

/by
, , ,

Transaction Security for Online Banking: Which Controls Decide Whether a Payment Goes Through

A transfer is the point where a compromised account becomes a loss. Login controls decide who is at the keyboard. Transaction controls decide whether this particular payment should leave the account, and to whom. A bank that answers only the first question leaves the second one open.

For how the login factors compare, see our post on types of MFA used in online banking. The controls below pick up where that one stops.

Transaction verification decides each payment on its own

Transaction verification looks at one payment at a time and decides whether to allow it, challenge it, or hold it. The FFIEC’s 2021 guidance asks institutions to base their authentication on a risk assessment and to use layered security, so the decision depends on the combination of signals rather than on any single one.

Consider a payment of an amount you have never sent, to a payee you added an hour ago, from a device the bank has not seen before. Each signal alone might be explainable. Together they may justify a hold. The risk this control addresses is a valid session used to move money the owner did not intend to move. The bank can reduce that risk by recording the reasons for each decision, so it can explain a hold later. OmniDefend’s customer identity offering lists transaction verification among its capabilities. For the same logic applied at sign-in, see our post on why does my login suddenly require MFA.

Binding each approval to one amount and one payee

Under EU and UK strong customer authentication rules, the approval code must be specific to the payment’s amount and payee. Any change to either one invalidates the code. Suppose you approve a payment of £200 to one payee. A code generated for that payment cannot release £2,000 to a different account. The rules also require that the payer is made aware of the amount and payee before approving, which addresses payments altered after the owner has approved them.

This is the step where transaction verification and the approval factor have to agree. If the approval is not bound to the payment, a good risk score still leaves room for a substituted payment.

Checking the payee’s name before the first payment

In the UK, Confirmation of Payee checks the name entered for a new payee against the name on the receiving account. The Payment Systems Regulator’s Specific Direction 10 required the largest UK banks to introduce it. Take a customer who types a payee name and sees the app report that the name does not match the account. They stop and check the details before sending. The check is aimed at authorised push payment scams, in which a customer is persuaded to pay an account controlled by a fraudster, and at misdirected payments, according to Electronic Payments International.

The limit is scope. The check applies in the UK, and other markets have their own rules, so the same protection does not apply everywhere.

Secure e-commerce transactions at checkout

Online card and account payments are made without the cardholder being physically present, so the bank has less to go on. OmniDefend lists secure e-commerce transactions as part of its secure online experience offering. In practice, that means the same risk decision applies at checkout. A shopper buying from a site they have never used may see the payment approved without a prompt when it looks ordinary, and a confirmation step when it does not.

In general practice, merchants and banks decide together how much friction a checkout can carry. A step that is too heavy loses sales, and a step that is too light lets fraud through. Measuring both outcomes is what shows where the balance sits.

Limiting guesses and idle payment sessions

The EU and UK rules cap consecutive failed authentication attempts at five. After the cap is reached, the action is blocked temporarily or permanently, and a permanently blocked payer must have a secure procedure to regain use of the payment instrument. The same rules set a maximum of five minutes without activity for online access to a payment account. After that, the session must be authenticated again.

Picture someone trying several wrong codes on an account. After the fifth failure, the bank can block further attempts, as the rules allow. These controls address automated guessing of approval codes and a session left open on a shared device. Our post on how hackers bypass 2FA describes reverse proxy attacks that take over a session after login, which is why the inactivity limit matters.

Large-scale identification behind every decision

Each payment decision draws on an identity record: who the customer is, which devices they use, and which payees they have verified. OmniDefend lists large-scale identification and user management APIs among its customer identity capabilities. A customer who changes phones and adds a new payee should have a record that connects the new device and the payee to the same person, rather than leaving them as unconnected events.

The limit is data quality. Identity records only help if they are kept accurate, and duplicate or stale records weaken every decision that depends on them.

What a bank still has to do itself

No transaction control replaces the bank’s own systems. The table separates what each control is responsible for, so no reader assumes a capability covers more than it does.

Question

Control in general practice

What it cannot cover

Is this payment consistent with the account?

Transaction verification, using the risk assessment

A fraud pattern the bank has not yet seen

Was the approval bound to this amount and payee?

The approval factor and its binding rules

A customer who approves a payment they were tricked into making

Does the payee name match the account?

Confirmation of Payee in the UK

Payees outside the UK, and payments the rule does not cover

Has the session been idle or attacked?

Inactivity limits and session controls

Sessions that stay active through normal use

Did the account change without the owner knowing?

Account change notifications

An owner who does not read or act on a notice

Account changes the owner should hear about

NIST SP 800-63B-4 expects subscribers to be notified of account events, such as a new authenticator being bound or a recovery being started, so the real owner can spot a takeover, according to a secondary summary by MojoAuth. Suppose you receive a message that a new device was added to your banking app, and you did not add one. The right response is to contact the bank through a number you already know. Notifications only help if they reach the owner, and if the owner has a route to report the change and freeze the account. Our post on tips to improve your customer identity verification process covers how banks tighten the steps that change an account.

Pick the payment your team would least want to fail

Start with the payment type your customers send most often, and check each row of the table against the controls you run today. The row with no owner, or with an owner that cannot cover the case, is the one to address first.

OmniDefend’s 30-day free trial comes with setup handled by our sales team, so the check runs on your own payment flows. If you want to see the capabilities first, request a demo. Start with the 30-day free trial and test one payment type end to end.

Frequently asked questions

Why did my bank hold a payment I started myself?

Transaction verification decides per payment. A payment that is unusual for your account or device can be held for an extra check, and the check confirms that you are the one sending it.

Why does a code stop working when I change the amount?

Under EU and UK rules, the approval code must be specific to the amount and payee. Changing either one invalidates it.

Does the name check protect payments outside the UK?

No. Confirmation of Payee is a UK requirement. Other markets have their own rules, and the checks differ.

Why was I logged out in the middle of a payment?

The EU and UK rules set a maximum of five minutes without activity for online access to a payment account. After that, the session must be authenticated again.

What should I do about an alert for a change I did not make?

Contact your bank through a number you already know, not through a link in the message, and ask them to freeze the account while you investigate.

Resources

/by
,

Bank Account Opening Online: The Cybersecurity Layers Behind the Form

Opening a bank account on your phone takes a few minutes. You type your details, photograph your driver’s license, and take a selfie. Behind those steps, the bank runs several security layers. Each one targets a different way someone could open an account in a name that is not theirs.

For the wider picture of how these layers connect to customer identity systems, see our complete guide to CIAM.

Layer 1: Identity resolution, catching fabricated and duplicate identities

What it does. It decides whether the details you entered describe a person the bank already knows, a new person, or someone the bank cannot confirm. NIST lists this as one of the outcomes of identity proofing, next to evidence validation and verification.

Example. You apply for a second account, and your name and birth date are almost identical to an existing customer’s. The bank has to decide whether the application is yours, a relative with a similar name, or a fabricated record.

Risk. Synthetic identities. NIST names synthetic identities as one of the attacks that the lowest assurance level is designed to limit.

Mitigation. At that level, core details are validated against authoritative or credible sources, and the applicant is linked to those details.

Layer 2: Evidence validation, stopping forged and stolen documents

What it does. It checks that the identity document is genuine and unexpired. Under federal rules, an unexpired government-issued photo ID is one of the documentary options a bank can use.

Example. A driver’s license photo with an expiry date in the past fails this check, even if the card itself is real.

Risk. Forged documents and stolen documents. NIST’s middle assurance level is designed to limit basic evidence falsification and evidence theft.

Mitigation. The middle level requires more evidence, more rigorous validation, and steps to confirm the applicant owns the evidence.

Layer 3: Liveness and face matching, stopping photo and video spoofs

What it does. It compares the selfie with the photo on the ID and checks that a live person is in front of the camera.

Example. Someone holds a printed photo of the account holder up to the camera.

How it works. Liveness checks look for signs of a real face. ISO/IEC 30107-3 is the standard for testing presentation attack detection, which covers photos, screen replays, and masks. A related read on how liveness works in login systems is in our post on how biometric authentication login systems can improve security and reduce fraud.

Risk. Presentation attacks, along with injection attacks. An injection attack feeds a pre-recorded or synthetic video into the capture process instead of showing it to the camera. ISO/IEC 30107-3 does not cover injection attacks.

Mitigation. Liveness testing against ISO/IEC 30107-3, plus injection attack detection that checks where the video came from.

Layer 4: Non-documentary checks, stopping identity theft without a document

What it does. When documents are not enough, or the applicant does not appear in person, the bank can check details against other sources. The federal rule lists contacting the applicant, comparing details with consumer reporting data or public records, checking references with other financial institutions, and reviewing a financial statement.

Example. An online application asks about previous addresses. The answers are checked against consumer reporting data, so a fabricated history is harder to sustain.

Risk. Applicants who cannot present an acceptable document, or who never appear in person. The rule requires procedures for these situations.

Mitigation. Several sources rather than one, and a documented procedure for each case.

Layer 5: Risk-based decisions, matching controls to fraud risk

What it does. It sets how much verification an application needs, based on a risk assessment. The FFIEC’s 2021 authentication guidance asks institutions to base their approach on that assessment, use layered security, and recognize that multi-factor authentication or controls of equivalent strength can reduce unauthorized access.

Example. Several applications arriving from one device may warrant more checks than a single application from a familiar device. How a bank weighs those signals is its own decision.

Risk. Applications that pass each check on their own but look wrong as a set.

Mitigation. Layered controls chosen from the risk assessment, rather than one pass-or-fail check for everyone.

Layer 6: Sanctions screening, keeping listed persons out

What it does. It checks applicants against federal lists of known or suspected terrorists. The rule requires this check within a reasonable period after opening, or sooner if another law or directive requires it.

Example. A name that closely matches a listed person triggers a review before the bank decides anything.

Risk. Opening accounts for listed persons.

Mitigation. Screening before approval, screening again after opening, and documented review of each match.

Layer 7: Login factor setup, stopping account takeover after opening

What it does. It binds the authenticators you will use to sign in later, such as a passkey, a one-time code, or an app approval.

Example. You create a passkey on your phone during account opening, so the next login uses your device rather than a password.

How it works. A passkey is tied to the website it was created for. Trail of Bits explains that the browser passes the site’s origin to the authenticator, so a passkey created for one site will not be used on a lookalike site.

Risk. Factors attached without a check, and factors that can be intercepted. NIST classifies SMS one-time codes as a restricted authenticator. Restricted means they are allowed only after the organization documents its risk acceptance.

Mitigation. Offer phishing-resistant factors first. Our post on phishing-proof MFA versus standard MFA explains which factors resist real-time phishing, and types of MFA used in online banking compares their strength.

Where OmniDefend fits. OmniDefend’s customer identity offering lists multi-factor identification for customer transactions, online or on-premise. The factors enrolled here are the ones that offering manages.

Where a gap in one layer lets fraud through

No single layer decides the outcome. A duplicate can pass a document check. A genuine document can fail a liveness check. A clean applicant can still be restricted by risk scoring. What matters is whether each layer’s result is recorded clearly enough to explain the decision later.

OmniDefend’s customer identity offering also lists large-scale identification and user management APIs, which are the parts of the stack that keep identity records consistent across a large customer base. For how those records are maintained after onboarding, see our tips to improve your customer identity verification process.

Testing the layers against fraudulent applications

Reading about each layer is useful. Testing them on your own cases is better. Run these five through your onboarding flow:

  • A near-duplicate of an existing customer.
  • An applicant with an expired ID.
  • A genuine ID with a selfie that does not match.
  • A second application from a device already used by others.
  • A name that triggers a screening match.

For each case, check which layer caught it and whether the record explains the outcome well enough to defend later. OmniDefend’s 30-day free trial comes with setup handled by our sales team, so your month goes on your cases, not on configuration. Start the free trial. If you want to see the platform run those five cases first, request a demo and we will walk through them live.

Frequently asked questions

Why does the bank check whether I already have an account?

The bank needs to decide whether your details describe you or a person it already knows. Matching them correctly is the first step in identity resolution.

Can I open an account without a photo ID?

Federal rules allow non-documentary verification. The bank can use other sources, such as consumer reporting data, and it must have procedures for applicants who cannot present an acceptable document.

Why do I need a selfie?

The selfie checks that the face matches the ID photo and that a live person is present, rather than a printed photo or a replayed video.

Why does my new account have limits?

The rule requires verification within a reasonable time after opening, and the bank must set the terms of use for the period before verification is complete.

What does the bank keep from my ID?

The rule requires a record of the document used, including its type, identification number, place of issuance, and any dates shown.

Are text codes safe for opening an account?

NIST treats SMS one-time codes as a restricted authenticator. They are permitted only after the organization documents its risk acceptance, and phishing-resistant options are preferred where available.

Resources

/by