Why Customers Leave During Authentication

v1 Why Customers Leave During Payment Authentication The customer has chosen the product, accepted the price, entered the card details, and tapped Pay. A new screen appears. It carries the bank’s name rather than the merchant’s. The customer is told that a code has been sent by text message. No message arrives. After waiting, the customer asks for another code. Still nothing. The customer closes the page. The merchant’s analytics record a checkout exit. That report makes the event look simple: a customer encountered authentication and abandoned the purchase. But the customer’s decision is only one possible explanation. The issuer may have sent the code to an outdated telephone number. The SMS provider may have delayed it. The challenge may have failed to render correctly. The browser may have lost state. The Access Control Server may have timed out. The customer may have completed the banking-app approval, but the result may not have returned to checkout. Authentication may even have succeeded before the later authorization request was declined. The missing order looks the same in the merchant’s dashboard. The underlying events are not.

Customers leave during authentication when a challenge is unexpected, slow, unclear, inaccessible, difficult to complete across devices, or dependent on an OTP or banking app they cannot access. However, some apparent abandonment is not voluntary at all: it is a rendering failure, message error, timeout, lost session, unsuccessful authentication, or authorization decline occurring elsewhere in the payment chain. The first task is therefore not to reduce one abandonment number. It is to determine what that number contains. Why payment authentication occurs Payment authentication attempts to establish that the person initiating an online card transaction is entitled to use the payment credential. EMV 3-D Secure, commonly called EMV 3DS or 3-D Secure, is a global authentication protocol for card-not-present payments. It allows transaction, device, cardholder, and merchant information to move through the authentication ecosystem so the issuer can assess risk and, when necessary, ask the cardholder to complete an additional verification step. (EMVCo) Authentication can support several objectives: * reducing unauthorized card use; * helping an issuer distinguish a legitimate customer from suspicious activity; * satisfying applicable strong customer authentication requirements; * providing authentication evidence; * and enabling risk-based decisions in which lower-risk transactions proceed without direct customer interaction.

Authentication does not itself transfer money or guarantee that the payment will be approved. It sits between the customer’s payment attempt and the authorization decision. Authentication is not authorization This distinction explains many inaccurate authentication-abandonment reports. Authentication Authentication asks: Is the person attempting this transaction sufficiently verified? The result may indicate successful authentication, failed authentication, an attempted authentication, an unavailable authentication service, cancellation, or a technical outcome, depending on the protocol and implementation. Authorization Authorization asks: Should the issuer approve this payment? That decision can consider available funds, account status, card restrictions, issuer risk controls, transaction details, and other factors unrelated to whether the customer successfully completed authentication. 3-D Secure authentication is performed before an authorization or payment request in a conventional authenticated card flow. The authentication data is then supplied with the authorization where appropriate. (Mastercard Gateway) A customer can therefore authenticate successfully and still receive an authorization decline. Insufficient funds is one straightforward example of an authorization problem that authentication cannot solve. (Visa) If analytics label this sequence as “authentication abandonment,” the merchant will try to repair the wrong stage. The terminology merchants must separate Term

Working definition Authentication The process used to assess or verify the customer in connection with the payment attempt Verification A broader term for confirming a fact, credential, account, or identity; it should not automatically be used as a synonym for 3DS authentication Challenge An authentication step requiring direct customer interaction Frictionless authentication An issuer authentication decision completed without asking the customer for additional interaction Challenge completion The customer reaches the end of the challenge interaction; this does not necessarily mean authentication succeeded Authentication success The issuer or Access Control Server returns a successful authentication outcome Authentication failure The authentication system returns an unsuccessful outcome Authentication abandonment The challenge was available to the customer, but the customer stopped before completing it, without evidence that a technical failure caused the exit Customer cancellation The customer explicitly selected cancel, close, back, or another defined cancellation action Technical error The challenge or related messages could not be initiated, rendered, exchanged, restored, or completed correctly Timeout The authentication ended because a permitted response or interaction did not occur within the applicable period Authorization decline Authentication may have completed, but the later payment authorization was rejected Exemption

A permitted basis for requesting that strong customer authentication not be applied in a transaction where the relevant rules support it Retry A new attempt following an incomplete, failed, unavailable, or declined outcome These definitions should become analytics rules, not just editorial terminology. Frictionless authentication and challenged authentication EMV 3DS supports two principal customer experiences. Frictionless authentication In a frictionless flow, the issuer evaluates the authentication request using available transaction, device, cardholder, merchant-relationship, and historical information without asking the customer to perform another action. EMVCo describes this as automatic issuer verification without additional cardholder interaction. (EMVCo) The customer may never know that authentication occurred. This is usually the least disruptive authentication experience, but “frictionless” does not mean that the whole payment will succeed. The authorization can still be declined or the order can still fail later. Challenged authentication In a challenge flow, the issuer or its Access Control Server asks the customer for additional input. Challenge methods can include: * a one-time passcode sent by text message or email; * approval through a banking application; * biometric authentication; * a PIN or password; * or another issuer-supported method.

The cardholder supplies the information directly to the issuer-controlled authentication service. EMVCo identifies OTP and out-of-band banking-app authentication as common challenge methods, while Visa and Mastercard publish separate user-experience guidance for challenged flows. (EMVCo) A challenge introduces a new actor, interface, and set of failure modes into checkout. That is where the merchant’s apparent control begins to shrink. The Authentication Handoff Map The Authentication Handoff Map turns the authentication journey into an ownership and observability model. A simplified card-authentication journey is: Merchant checkout → Payment provider or gateway → 3-D Secure server → Card-network directory infrastructure → Issuer or Access Control Server → Customer challenge → Authentication result → Authorization request → Merchant response The exact architecture varies by integration, provider, network, authentication version, and channel. The purpose of the map is not to reproduce the complete EMV specification. It is to prevent unrelated failures from being placed in one abandonment category. 1. Merchant checkout Owner: Merchant Customer sees: The payment form, order amount, card selection, Pay button, and any pre-authentication explanation. Merchant can observe: * payment form completion; * Pay-button activation; * client-side validation; * checkout session state; * authentication request initiation; * device and browser context; * and navigation away from checkout. Failure modes:

* invalid payment data; * duplicate submission; * broken JavaScript; * blocked iframe creation; * missing return handling; * lost checkout state; * misleading instructions; * or a session that expires during authentication. Recovery path: Preserve the order and valid customer data, retry initialization where appropriate, restore the payment stage, or offer another payment method. Classification: Checkout or integration failure—not necessarily authentication abandonment. 2. Payment provider, gateway, or 3DS server Owner: Payment provider, gateway, authentication provider, or merchant, depending on the architecture. Customer sees: Usually a loading state or transition rather than a distinct organization. Merchant may observe: * authentication request accepted; * protocol version; * authentication availability; * challenge requested; * transaction identifiers; * provider error codes; * and callback or webhook events. Failure modes: * malformed authentication data; * unsupported card or channel; * routing error; * unavailable 3DS component; * missing callback; * correlation failure; * or an inconsistent transaction state. Recovery path: Correct the request, retry only when safe, use a supported version or route, or return the customer to a stable payment-method selection screen. Classification: Authentication-initiation or technical failure. 3. Card-network directory infrastructure Owner: Card network or relevant directory-service operator. Customer sees: Usually nothing.

Merchant may observe: Limited protocol outcomes supplied through its 3DS provider. Failure modes: * service unavailability; * routing or enrolment problems; * protocol mismatch; * or message-delivery failure. Recovery path: Usually provider- or network-led. The merchant should avoid presenting a false “customer cancelled” message when the infrastructure failed. Classification: Technical authentication failure. 4. Issuer or Access Control Server Owner: Card issuer and its ACS provider. The Access Control Server evaluates the authentication request and determines whether the transaction can proceed frictionlessly, should be challenged, cannot be authenticated, or should receive another supported outcome. Visa notes that issuer decisions depend on the information supplied in the authentication request and device-data collection. (Visa Corporate) Customer sees: * an issuer-branded challenge; * a request for an OTP; * banking-app instructions; * a biometric prompt; * a password or PIN request; * or an error message. Merchant may observe: * challenge requested; * challenge type; * authentication outcome; * transaction-status information; * cancellation indicators; * and some technical error information. Failure modes: * customer not recognized; * outdated contact information; * unsuitable challenge method; * confusing instructions; * OTP-delivery failure; * issuer-service outage; * inaccessible interface; * or an issuer timeout.

Recovery path: May require an issuer-provided resend option, backup method, banking-app approval, cardholder support, or another payment method. Classification: Issuer-controlled challenge failure, authentication failure, or customer abandonment depending on the evidence. 5. Customer challenge Owner: The challenge is generally controlled by the issuer or ACS, but the merchant and provider control the surrounding handoff, container, state preservation, and recovery experience. Customer sees: The most visible authentication step. Merchant may observe: * challenge rendered; * challenge started; * customer cancellation; * completion callback; * elapsed time; * page visibility changes; * app-background events; * and the final result, depending on integration. Failure modes: * distrust of an unfamiliar page; * no OTP; * incorrect OTP; * inability to open a banking app; * inability to return to checkout; * accessibility barrier; * page closure; * or voluntary abandonment. Recovery path: Resend code, use another supported security option, reopen the challenge where permitted, retry payment, or choose a different payment method. Classification: This is the only stage where “customer abandonment” may be appropriate, and only after technical explanations have been excluded. 6. Authentication-result return Owner: ACS, directory service, 3DS server, provider, and merchant integration share the chain. Customer sees: A processing state or return to checkout. Merchant should observe: * result received; * result status;

* callback time; * transaction identifier; * whether the result matches the active checkout; * and whether authorization was initiated. Failure modes: * successful challenge but missing result; * duplicate or delayed message; * page reload; * mismatch between browser and server state; * callback processing error; * or order session no longer available. Recovery path: Resolve the transaction status server-side, restore the checkout, avoid restarting authentication unnecessarily, and prevent duplicate authorization. Classification: Technical handoff or session-loss failure. 7. Authorization attempt Owner: Merchant, payment provider, acquirer, network, and issuer participate. Customer sees: Usually a processing screen. Merchant should observe: * authorization submitted; * authentication data attached; * authorization response; * decline category; * and retry guidance where available. Failure modes: * insufficient funds; * card restrictions; * expired or blocked credential; * issuer risk decline; * incorrect authorization data; * or processing failure. Recovery path: Use an accurate customer message, offer another payment method, or apply a permitted retry strategy based on the response. Classification: Authorization decline or processing failure—not authentication abandonment. 8. Merchant response and order creation Owner: Merchant and payment provider. Customer sees: Confirmation, decline, retry instruction, or an indefinite spinner. Failure modes: * payment approved but order not created;

* order created but confirmation not displayed; * duplicated order; * unclear outcome; * or customer sent back to a blank payment form. Recovery path: Reconcile payment and order status, show the actual outcome, and provide support or a safe continuation route. Classification: Order, confirmation, or post-payment failure. Why customers leave during authentication 1. The challenge is unexpected The customer believes the payment has already been submitted. Instead of confirmation, another organization asks for information. Without preparation, the customer may interpret the challenge as: * an error; * a request to pay again; * a suspicious redirect; * an unnecessary registration step; * or a demand for information the merchant should already possess. The merchant cannot determine whether the issuer will challenge every transaction, but it can prepare the customer for the possibility. A concise message before payment can explain: Your bank may ask you to verify this payment. Keep this page open while completing the verification. That message should not promise a particular challenge method or suggest that the merchant controls the bank’s decision. 2. The issuer page looks unfamiliar The customer entered payment details within a familiar merchant checkout. The challenge may then display different typography, colors, language, domain information, or terminology.

The mismatch can be legitimate because the issuer or ACS controls the authentication experience. Visa’s guidance differentiates issuer-controlled HTML challenge experiences from native SDK templates, and Mastercard treats challenge design and branding as a distinct part of the authentication journey. (Visa Developer) The merchant cannot redesign every issuer challenge. It can reduce uncertainty around the transition: * preserve the merchant’s order context; * show the amount before authentication; * explain that the bank controls the next step; * avoid opening an unexpected blank tab; * and restore the merchant checkout clearly after the result returns. Hypothetical scenario: the unfamiliar issuer page A customer buying software from a merchant in another country sees a challenge page in a different visual style. The page asks for a banking password but does not clearly restate the merchant or amount. The customer closes it. This may be genuine abandonment caused by distrust. But the merchant should still check whether the correct transaction and merchant information were supplied and displayed before concluding that the customer simply refused authentication. 3. The customer never receives the OTP An OTP challenge depends on more than the customer’s willingness.

The issuer must hold usable contact information, generate the code, select a delivery channel, send the message, and accept the returned code before it expires. Visa’s 3DS guidance describes OTP delivery through text or email and recommends giving customers more than one delivery option where supported. (Visa Developer) An OTP may not arrive because: * the issuer holds an old number or email address; * the customer is roaming; * the message is delayed; * the device has limited reception; * spam filtering intervenes; * the delivery provider fails; * or the customer cannot access the registered channel. The merchant generally cannot repair issuer contact data. It can ensure that the customer receives an accurate message and a recovery route. Bad response: Authentication failed. Better response: Your bank could not verify this payment. Try again, choose another verification option if your bank offers one, or use a different payment method. Measure OTP problems carefully “OTP challenge not completed” does not prove “OTP not delivered.” Unless delivery data is available from the issuer or authentication provider, separate: * OTP challenge displayed; * resend selected; * code submitted; * incorrect code; * expired code; * customer cancellation; * timeout; * and unknown non-completion. 4. OTP entry is inaccessible or unnecessarily difficult An OTP that arrives can still be difficult to enter. Examples include: * preventing paste; * splitting the code into separate boxes that do not accept a full pasted value;

* moving focus incorrectly; * resetting all digits after one mistake; * providing no indication of expiry; * or using an error message that a screen reader does not announce. WCAG 2.2 guidance on accessible authentication says users must be able to paste verification codes or use user-agent assistance rather than being forced to transcribe them manually. It specifically identifies one-time passcodes as part of authentication. (W3C) A merchant may not control an issuer-hosted OTP form, but it should: * test the challenge container; * avoid interfering with clipboard behavior; * record issuer or ACS accessibility patterns; * escalate concentrated failures; * and ensure merchant-controlled verification screens meet the same standard. 5. The customer must switch to a banking app Out-of-band authentication asks the customer to approve the payment through a separate issuer service, commonly a banking app. In a browser-based flow, EMVCo notes that the customer may need to leave the checkout manually, complete authentication in the other service, return to the challenge window, and select a completion control. The browser transition cannot always be automated. (EMVCo) That sequence creates several questions: * Did the banking app open? * Did it show the correct payment? * Did the customer authenticate? * Did the customer know to return? * Did the browser preserve the page? * Did the authentication result arrive while the browser was inactive? * Did the customer return to the right tab?

* Did the checkout recognize the result? A single missing order can result from failure at any point. Hypothetical scenario: approval succeeded, checkout disappeared A mobile customer approves the transaction in a banking app. While the browser is in the background, the operating system reclaims resources and refreshes the checkout tab. The customer returns to an empty payment form. EMVCo documents this type of mobile-browser out-of-band problem: the operating system may suspend or refresh the browser, the challenge context may need to be restored, and the authentication can fail or time out even though the customer completed the banking-app step. (EMVCo) Calling this “customer abandonment” is particularly misleading. The customer did exactly what the challenge requested. 6. App switching is not automated correctly Newer app-based implementations can support automatic switching from the merchant app to the authentication app and back when the relevant EMV 3DS version, SDK, Access Control Server, links, and message-extension capabilities align. EMVCo describes automated app-to-app switching for EMV 3DS 2.3.1 and for some 2.2 implementations using a bridging extension. It also documents fallback cases in which a link cannot be resolved and the customer must switch manually. (EMVCo) Merchants should therefore avoid assuming: * every issuer supports automatic return; * every device resolves the app link correctly; * every app version behaves identically;

* or every successful banking-app approval will automatically close the challenge. Instrument both the automated and manual paths. 7. The challenge fails to render Some authentication exits occur before the customer has a usable challenge. Possible symptoms include: * blank iframe; * endless loader; * incorrectly sized modal; * content rendered outside the viewport; * blocked redirect; * challenge opened behind another interface; * JavaScript error; * missing callback; * or unsupported browser context. EMV 3DS uses different mechanisms for browser and app channels. Browser challenges commonly use an iframe and ACS-provided interface, while app-based flows use the 3DS SDK. (EMVCo) In-app browsers and embedded webviews require specific testing because the merchant’s ordinary mobile-browser test does not prove that redirects, storage, focus, and return handling work in every embedded environment. Hypothetical scenario: analytics call a blank modal “abandonment” A challenge request is issued. The merchant records authentication_started. The issuer content never becomes visible because the challenge iframe fails to load. After 30 seconds, the customer closes the page. The dashboard reports: Authentication abandonment: 100% The accurate classification is: Challenge-render failure followed by customer exit. The customer’s closing action is real, but it is not the root cause. 8. The challenge times out Authentication challenges cannot remain open indefinitely. Timeouts can occur because:

* the OTP arrived late; * the customer took too long to find the banking app; * the customer did not know to return; * the browser was suspended; * the challenge result did not arrive; * or a message exchange failed. EMVCo describes a 10-minute timeout risk in certain browser out-of-band flows and recommends designs in which the ACS sends the result without waiting for an unnecessary final customer interaction when it already knows the authentication outcome. (EMVCo) Timeouts also have accessibility implications. W3C guidance explains that timed interactions can create barriers for users who need more time to read, understand, or complete a form, and that users should be warned when inactivity will cause data loss where the timeout is within the content provider’s control. (W3C) The merchant may not control the issuer’s timer. It does control whether its own checkout: * warns about merchant-session expiry; * preserves completed order information; * distinguishes authentication timeout from checkout timeout; * and gives the customer a safe next action. 9. The customer does not understand what is required An instruction such as “Complete authentication” assumes the customer knows: * who is authenticating them; * which device or app to use; * whether they should wait; * whether they should return; * and whether the payment has already been charged. Clear challenge information should identify the action without exposing sensitive information. Examples:

Open your banking app and approve the €48.00 purchase. Then return to this page. We sent a verification code to the contact method held by your bank. Your bank could not verify the payment. No completed order has been created. Visa’s challenge guidance recommends recognizable instructions, issuer information, transaction context, accessible controls, resend behavior, and alternative authentication methods where available. (Visa Developer) 10. The customer cannot use the requested method A challenge may technically work while being practically unavailable to the customer. Examples include: * the banking app is not installed; * the phone number belongs to a device the customer does not have; * the customer is abroad without mobile service; * biometric authentication is unavailable; * the issuer asks for forgotten knowledge-based information; * the customer cannot perceive or operate the interface; * or the registered device is inaccessible. Where issuers support backup authentication, the challenge should make the alternative discoverable. Visa recommends allowing customers to select another security option when more than one issuer-supported method is available. (Visa Developer) The merchant cannot create an issuer authentication method, but it can provide a different payment method when authentication cannot be completed. 11. The customer cancels deliberately Some customers do decide not to continue. They may: * distrust the challenge; * decide the purchase is not worth the effort;

* lack the required device; * notice the wrong amount; * change their mind; * or prefer another card. This is genuine customer cancellation or abandonment. It should still be classified precisely: * explicit cancel; * browser close; * back navigation; * merchant page exit; * or no further activity before timeout. These actions have different evidentiary value. An explicit Cancel event is stronger evidence of a decision than the absence of a callback. 12. Authentication fails A customer can complete the requested interaction and still fail authentication. Possible reasons include: * incorrect OTP; * expired code; * unsuccessful biometric; * wrong PIN or password; * issuer rejection; * cardholder not recognized; * or exceeded attempt limits. This is authentication failure, not abandonment. The customer may have spent substantial effort trying to complete the purchase. Reporting that effort as abandonment conceals a potentially fixable issuer, delivery, usability, or data-quality pattern. 13. The authentication service is unavailable The issuer or a 3DS component may be unable to authenticate the transaction. The result may indicate unavailable authentication, a system error, or another protocol outcome rather than a customer decision. Modern 3DS implementations can also expose more detailed challenge-error and cancellation information, depending on the supported specification and message extensions. (EMVCo) The merchant’s response depends on: * market and regulatory context; * network and provider rules;

* fraud policy; * liability implications; * transaction risk; * and whether authorization without successful authentication is permitted or appropriate. Do not turn a technical-unavailable result into a generic “Your card was declined” message. 14. Authentication succeeds, but authorization is declined This is one of the most commercially important distinctions. The customer completes the challenge correctly. The issuer confirms authentication. The merchant submits the authorization. The authorization is declined. Possible authorization reasons include: * insufficient funds; * account restrictions; * card status; * issuer risk controls; * unsupported transaction; * or invalid payment data. Successful authentication established something about the cardholder or transaction. It did not require the issuer to approve the payment. Classify the sequence as: 1. authentication initiated; 2. challenge completed; 3. authentication successful; 4. authorization submitted; 5. authorization declined; 6. order not completed. Do not optimize the authentication challenge to solve an authorization problem. What merchants control—and what they do not Merchant-controlled areas Merchants generally control or influence: * pre-challenge messaging; * order and amount accuracy; * authentication-request data supplied through their integration; * checkout-session preservation; * challenge-container implementation; * loading and transition states; * callback and result handling; * authorization submission after authentication;

* error classification; * customer messaging; * retry behavior; * alternative-payment presentation; * and merchant analytics. Payment-provider-controlled areas Depending on the integration, a payment or authentication provider may control or influence: * 3DS-server operation; * protocol-version support; * network routing; * authentication initialization; * request validation; * callbacks or webhooks; * challenge integration components; * provider error mapping; * and authorization orchestration. Card-network-controlled areas Networks generally control or govern: * directory infrastructure; * program rules; * protocol participation; * network-specific authentication programs; * and the movement of authentication information across participating systems. Issuer- and ACS-controlled areas Issuers and their ACS providers usually control: * frictionless-versus-challenge decisioning; * supported challenge methods; * OTP destination and delivery initiation; * banking-app authentication; * issuer challenge copy and branding; * customer-recognition logic; * challenge result; * and much of the customer-visible challenge interface. Mastercard describes the challenge as resulting from an issuer risk assessment, while Visa’s UX materials repeatedly identify issuer choice over challenge methods. (Mastercard Developers) Customer-controlled areas The customer controls: * whether to continue; * whether to use the available device; * whether to enter or approve the requested information; * whether to cancel;

* and whether to choose another payment method. The purpose of ownership mapping is not to avoid responsibility. It is to direct the correct team toward the correct intervention. Authentication data quality affects challenge decisions A merchant cannot command an issuer to use a frictionless flow. It can improve the completeness, consistency, and accuracy of the authentication data submitted through its provider. The issuer’s risk assessment may consider: * transaction amount and currency; * merchant identity; * customer details; * device information; * prior transaction history; * recurring-payment context; * account relationship; * and technical information associated with the transaction. EMVCo identifies these categories as inputs to frictionless risk assessment, and Visa states that issuers use authentication-request and device data to decide whether to authenticate frictionlessly, challenge, or reject an authentication request. (EMVCo) Poor data can limit the issuer’s ability to recognize a legitimate transaction. Possible data problems include: * missing browser information; * inconsistent customer names; * incorrect billing details; * missing device-data collection; * inaccurate transaction indicators; * inconsistent recurring-payment information; * or merchant integration errors. More data is not automatically better. Merchants should supply the correct supported fields for a defined purpose, not collect personal information speculatively.

The result should be assessed through actual challenge, fraud, approval, and completed-order outcomes. Strong customer authentication and exemptions In markets governed by PSD2 and its Regulatory Technical Standards, strong customer authentication requirements and permitted exemptions can affect whether an authentication step is requested. The EBA describes the SCA and secure-communication standards as part of the European payment-services framework. Exact applicability depends on the transaction, parties, market, exemption, and current legal interpretation. (European Banking Authority) An exemption request does not guarantee a frictionless customer experience or an approved payment. Merchants should track: * whether an exemption was requested; * which exemption; * whether it was accepted; * whether the issuer still requested a challenge; * and the later authorization result. Exemption strategy should be reviewed with payments, risk, compliance, acquirer, and provider teams. It should not be treated as a universal technique for avoiding authentication. How to measure authentication conversion A single “authentication conversion rate” usually hides more than it reveals. Use a sequence of rates with explicit denominators. Authentication initiation rate Authentication requests initiated ÷ eligible card-payment attempts This measures how often the merchant or payment provider began the authentication process.

“Eligible” must be defined. Exclude payment methods that do not use the measured authentication route. Frictionless rate Frictionless authentication outcomes ÷ authentication requests receiving a valid authentication decision Do not divide frictionless outcomes by all checkout sessions. Challenge rate Challenge requests ÷ authentication requests receiving a valid authentication decision A high challenge rate is not automatically evidence of a bad merchant integration. It may reflect issuer policy, market requirements, card portfolio, risk mix, or data quality. Challenge-render rate Challenges visibly rendered ÷ challenge requests This is one of the most frequently missing metrics. A challenge that was requested but never rendered should not enter the same denominator as a challenge the customer saw and abandoned. Challenge-interaction rate Challenges with a customer interaction ÷ rendered challenges Interaction can include: * OTP request; * code entry; * resend; * opening a banking app; * selecting another method; * or explicit cancellation. Challenge-completion rate Completed challenge interactions ÷ rendered challenges Define completion as reaching a protocol-defined or provider-defined end of the interaction, not merely clicking Continue. Authentication-success rate Successful authentication outcomes ÷ completed authentication attempts with a final outcome Keep unavailable and technical-error outcomes visible rather than silently excluding them. Authentication-failure rate

Failed authentication outcomes ÷ authentication attempts with a final outcome Break this into recognizable categories where the data permits: * incorrect credential; * expired OTP; * issuer rejection; * exceeded attempts; * cardholder not recognized; * and unknown failure. Authentication-abandonment rate A defensible operational definition is: Rendered challenges with no completion, no explicit technical error, no issuer failure result, and no later successful recovery ÷ rendered challenges This definition is narrower than “authentication started but no order.” That is intentional. Customer-cancellation rate Explicit customer cancellations ÷ rendered challenges Keep explicit cancellation separate from passive timeout. Timeout rate Authentication attempts ending in a timeout ÷ initiated authentication attempts Further classify: * issuer challenge timeout; * merchant checkout timeout; * provider timeout; * browser or session timeout; * and unknown timeout. Technical-error rate Authentication attempts ending in a technical error ÷ initiated authentication attempts Assign an owner when possible: * merchant; * provider; * 3DS server; * directory service; * ACS; * browser or SDK; * or unknown. OTP resend rate Challenges with at least one resend request ÷ rendered OTP challenges A high resend rate may indicate delivery delays, unclear delivery channels, or customers who cannot access the registered contact method. OTP completion rate Successfully completed OTP challenges ÷ rendered OTP challenges

Do not claim to measure delivery unless the issuer or provider exposes a delivery event. Session-loss rate Authentication attempts in which merchant checkout state was lost ÷ authentication attempts involving a redirect, app switch, page suspension, or return This requires merchant instrumentation around page state and authentication correlation. Authorization rate after successful authentication Approved authorizations following successful authentication ÷ authorization attempts following successful authentication This metric prevents authorization problems from being misreported as authentication problems. Completed-order rate after successful authentication Completed orders following successful authentication ÷ successful authentications The difference between authorization approval and completed order reveals post-payment or order-creation failures. Retry rate Authentication or payment attempts followed by an eligible retry ÷ incomplete or unsuccessful attempts Track whether the customer: * retried the same card; * used another card; * selected another payment method; * restarted checkout; * or completed the order later. Alternative-payment recovery rate Completed orders through another payment method after an authentication problem ÷ customers offered another eligible method after that problem This measures recovery, not merely method clicks. Instrument the journey as connected events Every authentication attempt should have a stable correlation identifier connecting: * checkout session;

* order attempt; * payment attempt; * authentication attempt; * authorization attempt; * and final order. Useful event names include: * authentication_requested * authentication_initialized * authentication_frictionless * challenge_requested * challenge_rendered * challenge_interacted * challenge_cancelled * challenge_timed_out * authentication_succeeded * authentication_failed * authentication_unavailable * authentication_technical_error * authorization_submitted * authorization_approved * authorization_declined * order_completed * payment_method_changed * authentication_retried Useful event properties include: * authentication version; * browser or app channel; * device and operating system; * issuer or issuer segment where contractually and lawfully available; * card type; * country; * currency; * order value; * challenge method; * exemption status; * provider; * checkout version; * error owner; * error category; * elapsed time; * and whether the merchant session was restored. Do not log OTP values, passwords, full card data, or other sensitive authentication credentials. The authentication diagnostic decision tree Use this sequence for every missing order associated with authentication. Step 1: Was authentication requested? No: The problem is before authentication or authentication was not applicable. Yes: Continue. Step 2: Did the authentication service return a valid initial decision? No: Classify as initialization, provider, routing, availability, or technical failure. Yes: Continue.

Step 3: Was the result frictionless or challenged? Frictionless: Go directly to the authentication-result and authorization checks. Challenged: Continue. Step 4: Was the challenge rendered? No: Classify as challenge-render or technical failure. Yes: Continue. Step 5: Did the customer interact? No: Investigate visibility, trust, page closure, immediate cancellation, accessibility, and passive timeout. Yes: Continue. Step 6: Was there an explicit cancellation? Yes: Classify as customer cancellation. No: Continue. Step 7: Did the challenge end with a final authentication result? No: Investigate timeout, app-switch failure, browser-state loss, message failure, or callback loss. Yes: Continue. Step 8: What was the authentication result? Failure: Classify as authentication failure. Success: Continue. Unavailable or error: Classify according to the technical outcome. Step 9: Was authorization submitted? No: Classify as merchant, provider, orchestration, or session failure after authentication. Yes: Continue. Step 10: Was authorization approved? No: Classify as authorization decline. Yes: Continue. Step 11: Was the order completed and confirmed? No: Classify as post-authorization order or confirmation failure. Yes: The transaction completed. This tree prevents a single customer-visible exit from swallowing several institutional and technical outcomes. How merchants can reduce authentication friction Explain the handoff before it happens Tell the customer that their bank may request verification.

Keep the message brief and accurate. Do not add so much warning text that the checkout appears dangerous. Preserve checkout state Before launching authentication, safely preserve: * the order reference; * cart contents; * delivery option; * customer details; * non-sensitive payment-method state; * authentication identifiers; * and the current checkout step. When the customer returns, resolve the server-side status before displaying a new payment form. Keep the amount and merchant context consistent The amount shown before authentication should match the authenticated transaction and later authorization. Investigate mismatches among: * order total; * currency; * merchant name; * recurring-payment details; * and challenge information. Improve authentication-request data quality Validate required and recommended 3DS data fields across: * browser; * app; * guest; * returning customer; * subscription; * one-time purchase; * and relevant country flows. Do not assume the provider supplies merchant-owned customer or transaction data automatically. Test the challenge container Verify: * iframe dimensions; * mobile viewport behavior; * scrolling; * focus; * close and cancel behavior; * screen-reader access; * loading state; * browser history; * app backgrounding; * and return handling. Make the waiting state explicit Differentiate: * contacting the bank; * waiting for verification; * returning from a banking app; * checking the result; * submitting authorization; * and creating the order.

An indefinite spinner hides the stage that failed. Provide a safe retry A retry should not: * create a duplicate order; * reuse an invalid or expired authentication result; * submit authorization repeatedly without guidance; * or erase all checkout information. Decide when to: * restart authentication; * resubmit authorization; * ask for another card; * offer another payment method; * or instruct the customer to contact the issuer. Offer another payment method where appropriate A customer unable to complete card authentication may still be able to pay using: * another card; * a digital wallet; * bank transfer; * local bank-payment method; * or another eligible option. The alternatives should match the customer’s market, device, currency, and transaction rather than appearing as an unprioritized catalogue. Use accurate customer messages Different failure classes require different messages. Customer cancelled Verification was cancelled. Your order has not been completed. Try again or choose another payment method. Authentication failed Your bank could not verify this payment. Check the verification information or use another payment method. Verification timed out The bank verification session expired. Your checkout information has been preserved. Technical error We could not open the bank verification step. Try again or choose another payment method. Authorization declined after successful authentication

Your bank verified the payment attempt but did not approve the transaction. Use another payment method or contact your bank. Only show the detail supported by the actual result. How to test authentication journeys Authentication testing should cover more than one successful OTP. Frictionless scenarios Test: * successful frictionless authentication and approval; * frictionless authentication followed by decline; * authentication unavailable; * issuer rejection; * malformed or missing data; * and provider timeout. OTP scenarios Test: * immediate delivery; * delayed delivery; * no delivery; * resend; * incorrect code; * expired code; * maximum attempts; * pasted code; * autofilled code where supported; * cancellation; * and challenge timeout. Banking-app scenarios Test: * app opens correctly; * app not installed; * app link opens a browser; * approval succeeds; * approval fails; * customer cancels; * automatic return works; * manual return is required; * browser or merchant app is suspended; * checkout state is restored; * and the result arrives before or after the customer returns. Browser and device scenarios Test: * major mobile and desktop browsers; * in-app browser; * private-browsing mode where supported; * blocked third-party content; * reduced memory; * small viewport; * orientation change; * enlarged text; * screen reader; * back navigation; * page refresh; * multiple tabs; * and browser termination. Result and authorization scenarios Test: * authentication success followed by authorization approval;

* success followed by authorization decline; * failure with no authorization; * technical error with permitted recovery; * delayed result; * duplicate callback; * authorization response lost; * order creation failure; * and approved payment with missing confirmation. Controlled testing and guardrails Possible interventions include: * improved pre-authentication explanation; * better state restoration; * corrected 3DS data; * different challenge-container behavior; * alternative-payment recovery; * and improved error messaging. Use a primary metric that matches the intervention. For state-restoration work, a suitable hypothesis might be: Preserving and restoring checkout state after banking-app authentication will increase completed orders among challenged mobile-browser sessions without increasing duplicate authorizations or orders. Guardrails should include: * fraud; * chargebacks; * authentication success; * payment approval; * duplicate submission; * technical-error rate; * support contacts; * refund rate; * and retained revenue. Evidence against the hypothesis would include no meaningful session-loss problem, no improvement in return-to-checkout completion, or an increase in duplicate or inconsistent payment states. Merchant diagnostic checklist Inspect immediately * Confirm authentication and authorization are separate analytics stages. * Identify whether challenge rendering is measured. * Review all “authentication abandonment” rules.

* Test OTP, banking-app, cancellation, timeout, and unavailable outcomes. * Confirm checkout state survives app switching and browser refresh. * Check whether successful authentication always produces an authorization attempt. * Review customer messages for each result category. * Verify that retry cannot create duplicate payment attempts or orders. Validate in the data * Authentication initiation rate * Frictionless rate * Challenge rate * Challenge-render rate * Challenge-interaction rate * Challenge-completion rate * Authentication-success rate * Authentication-failure rate * Explicit-cancellation rate * Timeout rate * Technical-error rate * Authorization after successful authentication * Completed order after successful authentication * Retry and alternative-payment recovery Segment the results At minimum, review: * country; * device; * browser; * operating system; * app versus browser; * issuer or issuer group; * card type; * payment provider; * challenge type; * authentication version; * new versus returning customer; * order value; * risk segment; * and exemption status. Fix first Prioritize failures that: * affect many eligible transactions; * prevent challenge rendering; * lose checkout state; * misclassify successful authentication; * prevent authorization after success; * generate unclear customer messages; * or offer no safe recovery route. Investigate with partners Escalate concentrated patterns such as: * one issuer’s OTP timeouts; * one browser’s render failures; * one provider route’s missing callbacks;

* one ACS’s app-return failures; * or one authentication version’s technical errors. Provide transaction identifiers, timestamps, device information, protocol outcomes, and reproducible steps rather than only a conversion chart. Do not change without evidence Do not: * disable required authentication controls; * submit unauthenticated authorization indiscriminately; * request exemptions without appropriate review; * automatically retry every failure; * or interpret a lower challenge rate as success without reviewing fraud, approval, and completed orders. The conclusion: one exit, several possible causes A customer disappears during authentication. The merchant sees no order. That outcome may represent a voluntary decision. It may also represent an OTP that never arrived, a challenge that never rendered, a banking app that did not return, a browser that lost state, an ACS that timed out, a result that was not correlated, or an authorization that was declined after successful authentication. These are different problems owned by different parties. The durable rule is: Do not optimize authentication abandonment until you have classified authentication outcomes. The Authentication Handoff Map gives payments, product, engineering, risk, and conversion teams a shared way to do that. At every handoff, identify the owner, customer-visible experience, observable events, failure modes, recovery route, and correct classification.

Only then does the merchant know what to fix, what to escalate, and what cannot be solved by changing the checkout page.

Frequently asked questions Why do customers abandon 3-D Secure? Customers may abandon because the challenge is unexpected, unfamiliar, slow, inaccessible, difficult to complete, or dependent on a device or OTP they cannot access. Some apparent 3DS abandonment is actually a rendering error, timeout, lost browser state, failed authentication, or missing return message. What is frictionless authentication? Frictionless authentication occurs when the issuer assesses and authenticates the transaction without requiring additional customer interaction. The customer does not enter an OTP or approve a banking-app prompt, although authentication still occurs in the background. (EMVCo) Is authentication failure the same as a payment decline? No. Authentication determines whether the customer or transaction can be sufficiently verified. Authorization determines whether the issuer approves the payment. Authentication may fail before authorization, or authentication may succeed and the authorization may still be declined. Why might an OTP never arrive? The issuer may hold outdated contact information, delivery may be delayed, the customer may lack mobile service, the message may be filtered, or the issuer’s delivery provider may fail. Without issuer delivery data, a merchant should describe the outcome as an incomplete OTP challenge rather than proven non-delivery. Can a customer authenticate successfully and still be declined?

Yes. Successful authentication does not guarantee authorization. The issuer may later decline because of available funds, card status, transaction restrictions, risk controls, or another authorization factor. Who controls the 3-D Secure challenge page? The issuer or its Access Control Server generally controls the challenge decision, method, and much of the challenge interface. The merchant and payment provider control the surrounding checkout, technical handoff, container, state preservation, result handling, and recovery. How should authentication abandonment be measured? Use rendered challenges as the denominator. Count only sessions with no challenge completion, no explicit technical error, no authentication-failure result, and no later recovery as probable abandonment. Report explicit cancellation, timeout, technical error, and authentication failure separately. Can mobile app switching interrupt authentication? Yes. A customer may leave the browser to approve the payment in a banking app, while the operating system suspends or refreshes the original checkout. EMVCo documents this as a possible source of failed or timed-out out-of-band authentication. (EMVCo) Should customers be allowed to retry authentication?

Usually, a recovery route is valuable, but the appropriate retry depends on the result. A timeout may justify a new challenge; an incorrect OTP may support another attempt; an authorization decline may require another card; and a technical error may require provider resolution. Retries must not create duplicate payments or orders. How can merchants reduce authentication friction? Merchants can explain the verification step, improve authentication-request data, preserve checkout state, test challenge rendering, classify results accurately, provide safe retry paths, and offer relevant alternative payment methods. Issuer-controlled OTP delivery and challenge design require partner or issuer investigation rather than checkout changes alone.

The article below follows the brief’s central requirement: classify authentication-stage exits by system owner and actual failure point rather than treating every incomplete order as customer abandonment. Editorial-brief interpretation This article should explain why a customer can disappear during payment authentication even when the merchant’s checkout is functioning correctly. The visible interruption may originate in the merchant integration, payment provider, 3-D Secure infrastructure, card network, issuer’s Access Control Server, OTP delivery channel, banking app, browser, device, or later authorization request. The central merchant problem is therefore not simply “reducing 3-D Secure friction.” It is building enough observability to determine: * whether the customer received a challenge; * whether it rendered; * whether the customer attempted it; * whether authentication succeeded; * whether the result returned correctly; * whether authorization followed; * and whether the merchant created the order. The Authentication Handoff Map is the article’s central framework. It assigns an owner, customer-visible experience, observable events, failure modes, recovery route, and classification to every authentication handoff. This follows the framework and distinctions required by the supplied editorial brief. One-sentence differentiation statement

This article is different because it treats authentication-stage drop-off as a multi-system classification problem rather than assuming that every missing order represents a customer who voluntarily abandoned a 3-D Secure screen. Unique article thesis Authentication abandonment often appears to be one checkout problem, but the same visible outcome can result from customer choice, issuer challenge design, missing OTPs, inaccessible verification, browser-state loss, technical message failures, timeouts, or an authorization decline that happens after successful authentication. Primary reader problem Payments and checkout teams need to identify why customers disappear during authentication, determine which organization controls the failure point, and distinguish true customer abandonment from authentication failure, technical failure, session loss, and post-authentication authorization decline. Search intent Dominant intent: Payment-specific explanation, diagnosis, and conversion troubleshooting. Immediate question: Why do customers leave during payment authentication? Deeper business problem: Merchants need to improve authentication conversion without weakening fraud controls, misclassifying payment outcomes, or trying to fix issuer-controlled experiences through checkout design alone.

Likely reader decision: Instrument the complete authentication journey, establish an ownership-based error taxonomy, fix merchant-controlled handoffs, and escalate issuer- or provider-controlled failure patterns with evidence. Primary keyword why customers leave during authentication Secondary keywords * authentication abandonment * 3D Secure abandonment * checkout authentication failure * payment authentication friction * customers abandon 3DS * failed payment authentication * SCA checkout abandonment * OTP checkout failure * authentication conversion rate * payment challenge abandonment * 3DS challenge failure * payment verification abandonment * authentication drop-off * frictionless authentication Recommended title options 1. Why Customers Leave During Payment Authentication 2. Authentication Abandonment: Why Customers Disappear During 3-D Secure 3. Why Customers Abandon 3-D Secure—and How to Diagnose It 4. Payment Authentication Friction: Failures, Handoffs, and Recovery 5. Authentication Failure or Customer Abandonment? A Merchant’s Guide Recommended article structure 1. The customer who disappears inside authentication 2. Why customers leave during authentication 3. Authentication is not authorization 4. Frictionless and challenged authentication 5. The Authentication Handoff Map 6. Common causes of authentication-stage exits 7. When apparent abandonment is a technical failure 8. Why authentication success does not guarantee payment success 9. What merchants control—and what issuers control

10. Authentication data quality and challenge decisions 11. How to measure authentication conversion 12. A diagnostic decision tree 13. Recovery, retry, and alternative-payment paths 14. Testing authentication journeys 15. Merchant action plan Frequently asked questions

SEO deliverables SEO title Why Customers Leave During Payment Authentication Recommended H1 Why Customers Leave During Payment Authentication Meta description Learn why customers abandon 3-D Secure, how authentication failures differ from payment declines, and how to diagnose OTP, timeout, app-switching, and technical errors. Suggested URL slug /why-customers-leave-during-authentication Article excerpt Authentication abandonment is not one problem. A customer may cancel a challenge, never receive an OTP, lose checkout state while switching to a banking app, encounter a technical error, or authenticate successfully before the payment is declined. The Authentication Handoff Map helps merchants identify the real failure point and owner. Social-sharing description Not every customer who disappears during 3-D Secure chose to abandon. Learn how to separate customer cancellation from OTP failure, browser-state loss, authentication errors, timeouts, and later authorization declines. Related entities * EMV 3-D Secure * EMVCo * 3DS Server * Directory Server * Access Control Server * card issuer * acquirer * payment gateway * one-time passcode * out-of-band authentication * banking-app authentication * strong customer authentication * PSD2 * frictionless authentication * challenge flow * authentication result * authorization * Visa Secure * Mastercard Identity Check * WCAG 2.2 Internal-link recommendations Suggested anchor text: * Mobile checkout optimization * Redirect checkout versus embedded checkout

* How checkout speed affects conversion * How checkout design builds trust * Checkout conversion-rate optimization * How to diagnose checkout drop-off * How to reduce checkout abandonment * Authentication versus authorization * Why card payments are declined * How payment data affects approval rates * How local payment methods improve recovery * 3-D Secure and strong customer authentication Authoritative external-source recommendations * EMVCo: EMV 3-D Secure specifications, frictionless and challenge flows, out-of-band authentication, challenge errors, message extensions, and technical handoffs. (EMVCo) * Visa Developer: Visa Secure user-experience guidance for OTP, out-of-band, backup authentication, error flows, accessibility, and transaction information. (Visa Developer) * Mastercard Developers: Identity Check challenged and frictionless journeys, branding guidance, authentication methods, and integration testing. (Mastercard Developers) * European Banking Authority: PSD2 and the regulatory technical standards governing strong customer authentication and secure communication. (European Banking Authority) * W3C Web Accessibility Initiative: Accessible authentication, OTP pasting and autofill, timeouts, re-authentication, form errors, and data preservation. (W3C)

Supporting infographic concepts Supporting infographic 1: “The Authentication Handoff Map” Create a horizontal payment-authentication chain: Merchant checkout → Payment provider → 3DS Server → Card network → Issuer / ACS → Customer challenge → Authentication result → Authorization → Merchant response Under every step, show five questions: * Who owns it? * What does the customer see? * What can the merchant measure? * What can fail? * How can the customer recover? Use color coding: * Merchant-controlled * Provider-controlled * Network-controlled * Issuer-controlled * Customer-controlled Bottom takeaway: One checkout exit can originate in several independent systems. Recommended alt text: “Authentication Handoff Map showing ownership, customer experience, observable events, failure modes, and recovery paths from merchant checkout through issuer authentication and payment authorization.” Supporting infographic 2: “One Missing Order, Four Different Outcomes” Create one customer journey that ends without a completed order, then split it into four diagnostic routes: Route 1: Customer abandonment * Challenge rendered * Customer saw it * Customer cancelled or left * No technical error Route 2: Technical failure * Challenge requested * Challenge did not render or result did not return * Customer could not continue Route 3: Authentication failure * Customer completed the challenge * Issuer returned unsuccessful authentication Route 4: Authorization decline * Authentication succeeded * Authorization was submitted

* Issuer declined payment Bottom takeaway: The same visible outcome does not prove the same cause. Recommended alt text: “Diagnostic comparison separating genuine authentication abandonment from technical failure, failed authentication, and authorization decline after successful 3-D Secure verification.” Recommended header-image alt text “Customer encountering a payment-authentication challenge while multiple systems connect the merchant, payment provider, card network, issuing bank, OTP service, and authorization response.” Editorial fact-check list Before publication, verify:

* The exact transaction-status and cancellation values exposed to merchants. * Which challenge-error details are available by authentication version. * Current Visa Secure and Mastercard Identity Check program terminology. * Current PSD2 and SCA requirements in each market discussed. * Whether every cited accessibility criterion applies to the relevant merchant- or issuer-controlled interface. * OTP resend, expiry, and delivery-channel behavior by issuer and ACS. * Browser and mobile-app return behavior across supported SDK versions. * Timeout values used by the provider, ACS, merchant session, and checkout. * Whether the merchant can distinguish challenge requested from challenge rendered. * Whether issuer, BIN, card-type, and risk segmentation is available and lawful. * Whether an unsuccessful authentication can proceed to authorization in each supported configuration. * Correct handling of authentication evidence in authorization messages. * Retry rules for authentication failures, technical errors, soft declines, and hard declines. * Duplicate-payment and duplicate-order protection. * Definitions of authentication success, completed challenge, approved authorization, and completed order. * Any claim connecting authentication changes to conversion, fraud, approval, or chargeback results.

* EMV 3DS versions supported by Brick, hosted checkout, direct APIs, SDKs, and other card integrations. * Support for browser, mobile-browser, native-app, and in-app-browser authentication.

* Availability of device-data collection and 3DS Method handling. * Support for frictionless, OTP, out-of-band, biometric, decoupled, and other challenge flows. * Challenge-container and redirect behavior by integration. * Whether challenge-render events are exposed. * Authentication result, cancellation, timeout, and technical-error fields exposed to merchants. * Availability of challenge-error reporting and message-extension data. * Session preservation after redirects, banking-app switching, and browser suspension. * Correlation among checkout, authentication, authorization, and order identifiers. * Whether an authentication success automatically triggers authorization. * Behavior after authentication failure, unavailability, cancellation, and timeout. * Whether merchants can configure retry and alternative-payment recovery. * Authorization-response detail available after successful authentication. * Issuer-, country-, device-, browser-, card-, and challenge-level reporting. * Exemption support and configuration where SCA rules apply. * Liability-shift handling and evidence availability. * Duplicate-authentication, duplicate-authorization, and duplicate-order controls. * Current public claim of more than 150 local payment methods across 200 regions.