WHY CUSTOMERS DO NOT RECEIVE AUTHENTICATION CODES

Why Customers Do Not Receive Authentication Codes During Payment A customer reaches a payment-authentication screen and waits for a text message. Nothing appears. The customer taps Resend code. Then taps it again. Meanwhile, the merchant’s support team can see that the payment entered a 3-D Secure challenge, but little else. It cannot confirm which phone number the issuer used. It cannot see whether the issuer generated a code. It has no telecom-delivery record. The support agent asks the customer to re-enter the phone number used during checkout. That advice sounds reasonable. It may also be irrelevant. The customer’s checkout number and the issuer’s authentication number may belong to different systems. Customers may not receive authentication codes because the issuer has outdated contact information, selects a different authentication method, encounters a message-generation problem, or sends the code through a telecommunications route affected by roaming, delay, filtering, device conditions, or network availability. Even when authentication succeeds, the customer may lose the checkout session before the order completes. An authentication-code failure is therefore not one failure. It is a chain of possible failures distributed across organizations that do not share equal visibility. Who Actually Sends the Authentication Code? In an EMV 3-D Secure challenge, the issuer or its Access Control Server generally controls the cardholder-authentication process.

The merchant initiates authentication and supplies supported transaction and customer context through its 3DS integration. The issuer-side ACS assesses the request and can complete authentication in the background or require a challenge. During a challenge, the ACS may ask the customer to enter a one-time code or approve the purchase through a banking application. (EMVCo) For an OTP challenge, Visa’s user-experience guidance states that customers may receive a secure code by text or email and that issuers choose which channels to offer. The example challenge presents a masked contact destination within issuer-controlled authentication screens. (Visa Developer) That creates a critical control boundary: Information or action Common controlling party Phone entered for shipping or support Merchant Phone sent as transaction context Merchant and payment provider Phone stored against the cardholder’s bank account Issuer Challenge method selected Issuer or ACS OTP generated Issuer-side authentication system SMS or email delivery service Issuer and its messaging providers Telecom routing Mobile-network operators and intermediaries Authentication result Issuer or ACS Checkout-session recovery Merchant, provider, browser, or app Exact roles can vary by program and implementation. The merchant should confirm the behavior of its own provider rather than infer it from the visible challenge screen. Merchant Checkout Number vs. Issuer Account Number

The customer may have entered a current phone number at checkout for delivery updates. The issuing bank may still hold a number from several years earlier. Updating the checkout field does not necessarily update the issuer’s records. The merchant may transmit a customer phone number as part of supported 3DS transaction data, but that does not mean the issuer will use it as the destination for an OTP. The issuer’s authentication process can rely on contact details or registered applications established through the cardholder’s banking relationship. EMVCo describes the authentication decision and challenge as issuer-side functions, while Visa states that issuers select the delivery channel. (EMVCo) A support agent should therefore avoid saying: “The code was sent to the number you entered on our checkout.” Unless the merchant’s integration provides specific evidence, safer wording is: “Your bank controls the verification method and may use the phone number or banking application registered with your card. Check the masked destination shown on the verification screen or contact your bank if it is no longer current.” The Authentication Code Delivery Chain The Authentication Code Delivery Chain maps ten stages from the issuer’s challenge decision to the customer’s return to checkout. A customer can experience “code not received” when any one of these stages fails—or when no SMS code was supposed to be sent at all. Stage Primary owner Possible failure Merchant visibility Customer-facing symptom

Likely recovery 1. Challenge decision Issuer or ACS Challenge cannot be initialized Partial Error before code screen Retry or use another payment method 2. Authentication method selected Issuer or ACS App approval selected while customer expects SMS Sometimes visible Customer waits for a nonexistent text Open bank app or select another issuer-offered method 3. Contact or device identified Issuer Outdated number, inaccessible email, unregistered app Usually none Masked destination is unfamiliar Customer updates details with issuer 4. Code or approval request generated Issuer authentication service Generation error, rate limit, service issue Usually none No message arrives Issuer support or a later retry 5. Delivery provider accepts message Issuer or messaging provider Message rejected or delayed before carrier handoff Usually none No message or late message Issuer/provider investigation 6. Telecom network routes message Mobile networks and intermediaries Routing, roaming, coverage, or filtering issue None in most merchant integrations Message delayed or missing Check network access; retry cautiously 7. Device receives or filters message Device, OS, messaging app, customer settings Spam filtering, blocked sender, wrong SIM, no storage or notification None Message exists but customer does not notice it Check filtered folders, blocked messages, SIM, and notifications 8. Customer finds and enters code Customer and ACS interface Wrong code, transcription error, stale code Partial “Incorrect code”

Use newest available code and read challenge instructions 9. Issuer validates code Issuer or ACS Expiration, attempt limit, replaced code Partial result only “Code expired” or “Verification failed” Restart challenge or use issuer alternative 10. Customer returns to checkout Merchant, provider, browser, app, ACS Checkout expired, browser reloaded, result not associated with payment Often observable Bank says approved, merchant says failed Restore session, retrieve result, or create a clean retry The framework is diagnostic, not absolute. Some issuers operate their own messaging infrastructure; others use vendors. Some providers expose rich challenge telemetry; others expose only the final authentication result. Stage 1: The Issuer Decides Whether a Challenge Is Needed A code is not generated for every 3DS transaction. Many authentications can complete through the protocol’s frictionless flow, where the issuer assesses the transaction without asking the customer for an extra step. When the issuer requires more evidence, the ACS requests a challenge. (EMVCo) If a merchant sees a customer waiting for a code before a challenge has actually been rendered, the problem may be checkout messaging rather than SMS delivery. The merchant should distinguish: * Authentication initiated * Challenge requested * Challenge rendered * OTP method displayed * Code requested * Authentication result returned Without these events, teams may investigate a missing message that was never supposed to exist.

Stage 2: The Issuer Selects the Authentication Method A challenge does not necessarily mean SMS. Supported issuer-controlled methods may include: * SMS OTP * Email OTP * Banking-app approval * Biometrics through an issuer application * Knowledge-based verification * Another supported authentication method EMVCo describes both one-time codes and banking-app approval as possible challenge experiences. Visa and Mastercard documentation similarly show that issuer authentication can use OTP or out-of-band application methods. (EMVCo) Example: the customer expects SMS, but the issuer requires app approval A customer sees: “Approve this purchase using your banking application.” The customer overlooks the wording and waits for a text. No code arrives because no code was generated. The correct merchant response is not to ask the customer to re-enter a phone number. It is to help the customer recognize the requested method: “Your bank is asking you to approve the payment in its app. Open the banking app, review the request, complete it, and then return to checkout.” Where the issuer provides a Choose another method option, the customer may be able to select SMS or email. Visa’s guidance recommends that issuers offer backup authentication choices where possible, but availability remains issuer-dependent. (Visa Developer) Stage 3: The Issuer Identifies the Contact or Registered Device If OTP is selected, the issuer must determine where to send it. The relevant destination may be:

* A mobile number held by the issuer * An email address held by the issuer * A registered banking application * A device associated with the cardholder account The merchant may see a masked destination in the ACS challenge, but it may not receive the full number or be able to change it. Example: outdated issuer telephone number The customer changed mobile providers and telephone numbers six months earlier. The merchant has the new number because the customer entered it for delivery. The issuing bank still has the old number. The authentication screen shows a masked destination ending in digits the customer does not recognize. The payment cannot be fixed by editing the merchant checkout. The customer needs an issuer-supported alternative or must update the banking record. This example illustrates why support should ask: “Does the masked number or email shown by your bank look familiar?” rather than: “Did you type your checkout phone number correctly?” Stage 4: The Code or Approval Request Is Generated Code generation and code delivery are separate events. The issuer’s ACS or connected authentication service may decide to generate an OTP. The resulting message must then be passed to email or telecommunications infrastructure. A merchant often receives no independent event confirming: * The code value * The complete destination * The exact generation time * Whether issuer rate limits were applied * Whether the issuer’s messaging platform accepted the request

Visa’s challenge model places OTP selection and delivery-channel availability under issuer control. The cardholder then enters the code through the issuer challenge. (Visa Developer) This is why a merchant should not display: “We have sent you a code.” unless its integration verifies that statement. Better wording is: “Your bank may send a code or ask you to approve the payment using its app.” Stage 5: The Issuer Hands the Message to a Delivery Provider An authentication service may generate a valid code but fail to deliver the associated SMS or email. Potential dependencies include: * Issuer messaging service * Messaging aggregator * Originating network * International routing partner * Destination network * Email-delivery infrastructure The merchant is usually outside this chain. It may see the challenge remain incomplete but cannot determine whether the message failed before or after carrier handoff. Support teams should distinguish: * Code-generation uncertainty: Did the issuer create the code? * Delivery uncertainty: Did the message leave the issuer’s messaging system? * Receipt uncertainty: Did the device receive or display it? “Not received” does not answer any of these questions. Stage 6: Mobile Networks Route the SMS SMS delivery is performed through mobile-network infrastructure defined separately from the 3DS protocol. The 3GPP maintains the technical specification for SMS realization across mobile-network generations. (3GPP Portal)

When a customer is roaming, the device is connected to a visited network rather than relying solely on its home operator’s local coverage. GSMA documentation defines SMS roaming as sending or receiving text messages while attached to a foreign network. (GSMA) Example: customer is roaming A customer from Canada attempts a payment while traveling in Southeast Asia. The customer has data access through hotel Wi-Fi, so checkout loads normally. But the phone is not properly registered for SMS roaming, has no cellular coverage, or is using a different SIM for travel. The customer can reach the merchant and issuer challenge over the internet but cannot receive a message addressed to the home mobile number. Roaming does not prove why an OTP failed. It adds network and device dependencies that make it a relevant diagnostic question: * Is the home SIM active? * Does it show cellular service? * Can it receive other SMS messages? * Is the customer using a travel eSIM for data while the banking number belongs to another SIM? * Is the issuer offering app or email verification instead? Stage 7: The Device Receives, Hides, or Filters the Message A message can reach the device without becoming visible to the customer. Modern operating systems and messaging applications can filter communications from unknown senders or classify messages as spam. Apple documents separate Unknown Senders and Spam views, while Google Messages provides spam detection and a Spam & blocked folder. (Apple Support)

Possible device-level causes include: * Sender blocked previously * Message placed in spam * Unknown-sender notifications suppressed * Wrong SIM active * Dual-SIM routing confusion * Airplane mode * No cellular signal * Device powered off * Message notifications disabled * Inbox or device malfunction Support should avoid asserting that filtering occurred. It can provide neutral checks: “Review your spam, blocked, transaction, and unknown-sender folders. Confirm that the SIM linked to your bank account is active and has mobile-network service.” Stage 8: The Customer Enters the Code A received code is not necessarily a usable code. The customer may: * Enter an earlier code * Confuse the merchant order number with the OTP * Add spaces or punctuation * Mistype a digit * Use an autofilled value from another application * Enter a code from a different payment attempt * Enter the OTP after the challenge has ended Visa’s current OTP guidelines include issuer-controlled passcode-entry, attempt limits, error handling, and a resend control. The specific length, lifetime, and number of permitted attempts depend on issuer and implementation. (Visa Developer) The merchant should record the returned authentication status where available but should not receive or log the actual OTP. Stage 9: The Issuer Validates the Code The code is validated by the issuer-side authentication system, not by the merchant checkout. Possible outcomes include: * Code accepted * Incorrect code * Code expired * Attempt limit exceeded

* Challenge canceled * Authentication timed out * Technical failure The merchant may receive only a normalized authentication result and reason code from its provider. It may not know whether the customer entered the wrong value or an otherwise correct code that was no longer active. Example: message arrives after expiration Consider a hypothetical issuer configuration with a short-lived OTP. The issuer generates a code. Telecom delivery is delayed. The message arrives after the issuer’s validity window or after the wider challenge has timed out. From the customer’s perspective, the code is new. From the authentication system’s perspective, it is already invalid. Exact OTP validity windows are issuer-specific. EMVCo separately documents finite challenge lifetimes, including a ten-minute timeout in one browser out-of-band flow, illustrating why authentication can expire while customer action is still in progress. (EMVCo) Support should not promise that a delayed code will remain usable. Stage 10: The Customer Returns to a Live Checkout The final failure can occur after the customer authenticates correctly. The issuer approves the authentication. The customer returns to the merchant page. The browser has refreshed, the payment intent has expired, or the authentication result is no longer associated with the live checkout. The customer reports: “I entered the code, but the payment still failed.” This may be a session-recovery failure, not an OTP failure.

EMVCo documents a related issue in mobile-browser out-of-band authentication: switching to a banking application can cause the operating system to background or terminate the browser tab. When the customer returns, the tab can reload, lose challenge context, or time out unless the merchant, 3DS Server, and ACS handle recovery correctly. (EMVCo) Example: customer leaves checkout and loses session state A hypothetical customer copies a code from the messaging application and returns to the browser. The browser reloads the checkout. The customer re-enters card details, creating a second authentication attempt. The original code belongs to the first attempt and fails against the second. The visible symptom is “incorrect code.” The underlying problem is payment-session continuity. Why Repeated Code Requests Can Make the Problem Worse The Resend code button is useful when a message was not received, but repeated requests can create ambiguity. Visa’s 3DS experience guidance includes a resend function, but the exact treatment of previous codes is issuer-specific. A new request may produce a new code, restart part of the challenge, trigger a cooldown, or cause an older code to stop working. Merchants should verify what their provider exposes rather than assume universal behavior. (Visa Developer) Hypothetical failure sequence 1. Code A is generated but delayed. 2. Customer requests Code B. 3. Customer requests Code C. 4. Code A arrives first. 5. Customer enters Code A.

6. The issuer expects Code C or has already invalidated Code A. 7. Authentication fails. The customer believes: “The bank sent me the wrong code.” The system may have sent three correct codes for three different points in the challenge timeline. Merchant guidance should therefore discourage rapid repeated requests: “Wait briefly after requesting a code. If you request another, use the newest code you receive and follow the instructions shown by your bank.” Do not specify an exact waiting period unless it has been confirmed for the relevant issuer or provider flow. SMS Challenge vs. Banking-App Approval A payment verification problem should not automatically be labeled an OTP failure. SMS or email OTP Banking-app or out-of-band approval Customer receives a code Customer receives or finds an approval request Code is entered in the issuer challenge Approval occurs in the issuer application Depends on messaging delivery Depends on app access, connectivity, notification, and issuer enrollment Can be delayed or filtered Can be missed if app notifications are disabled Customer stays in or returns to challenge Customer may switch apps and return Issuer validates code Issuer validates app-based authentication EMVCo defines out-of-band authentication as activity completed outside but alongside the 3DS flow. The ACS directs the cardholder to the issuer’s chosen application or service. (EMVCo) When customers say “I did not get a code,” first determine whether the challenge actually promised one.

What Merchants Can Observe Merchant visibility depends on the payment provider, card program, integration, and challenge type. A merchant may be able to observe: * Authentication initiated * Challenge requested * Challenge method category * Challenge rendered * Resend interaction, if exposed * Authentication result * Timeout * Cancellation * Technical error * Authorization submitted * Final order completion * Customer return to checkout A merchant generally should not assume it can observe: * Full issuer-held phone number * Whether the OTP was generated * The OTP value * Messaging-provider acceptance * Carrier delivery confirmation * Whether the message entered a spam folder * Whether the customer saw a notification * Which code remains active after resends The distinction should appear directly in support tools. An agent should see what is known, what is inferred, and what remains outside merchant visibility. Recommended support-status language Internal status Safe customer wording Challenge requested, method unknown “Your bank is requesting additional verification.” OTP method confirmed “Your bank should show where it is sending the verification code.” OOB method confirmed “Approve the payment using the banking app or service shown.” Authentication timed out “The verification session expired. Restart the payment to receive a new request.” Authentication failed “Your bank could not complete verification. Try again or use another payment method.” Authentication succeeded, checkout failed

“Verification completed, but the checkout did not finish. We will help you restart without duplicating the order.” Issuer contact appears outdated “The verification destination is controlled by your bank. Contact it to update the registered details.” What Merchants Can Improve Merchants cannot repair every OTP-delivery failure, but they can reduce confusion and prevent recoverable failures from becoming abandoned orders. 1. Explain who controls verification Use language such as: “Your bank may send a code or ask you to approve the transaction in its app.” Avoid: “We sent you a code.” The first statement reflects the actual control boundary. The second may be false. 2. Preserve the payment session The checkout should survive: * App switching * Browser backgrounding * Delayed challenge completion * Return from issuer pages * Page reload where recoverable * Repeated callback delivery Authentication results should be reconciled using stable transaction identifiers rather than relying only on the browser tab remaining open. 3. Distinguish retry from resend A resend belongs to the same authentication challenge. A retry may create a new authentication and payment attempt. The interface should not accidentally create a new attempt when the customer only wanted another code. 4. Offer an alternative path Depending on issuer and provider capabilities, recovery may include: * Another issuer-offered challenge method * Another card * A wallet * A bank payment * Another local payment method

* A clean restart of the authentication flow The merchant should not bypass required authentication merely to complete the order. 5. Preserve clear order state Before inviting another attempt, determine whether: * An order already exists * Authorization was submitted * The payment was approved * Authentication succeeded * The checkout alone failed * A duplicate attempt could be created 6. Provide support with transaction identifiers Support escalation should include, where available: * Merchant payment-intent ID * Authentication transaction ID * Provider transaction ID * Issuer or network identifiers exposed by the provider * Challenge method * Authentication status * Status reason * Timestamps * Device and browser category * Whether the customer returned to checkout Do not include OTP values or request that customers disclose them. 7. Separate authentication and authorization failures A customer who never received a code did not necessarily receive an issuer authorization decline. Authentication may have failed before authorization was attempted. Customer-Support Troubleshooting Matrix Customer report First checks Likely ownership Safe guidance Avoid saying “No text arrived” Confirm OTP was the selected method; check masked destination Issuer, messaging chain, carrier, device Check issuer destination, signal, spam folders, and alternate issuer methods “We sent it to your checkout number” “The number shown is old” Confirm it is the issuer challenge Issuer

Update contact details with the bank or choose another issuer method “Edit the number on our checkout” “I’m abroad” Check home SIM, roaming service, app alternative Carrier, issuer, device Use bank app or another method if SMS is unavailable “Roaming always blocks codes” “The code arrived too late” Check timeout and authentication result Issuer, telecom chain Restart the challenge and use the newest code “The code is definitely still valid” “Every code says incorrect” Ask whether several resends were requested Issuer, customer timing Use the newest code and avoid rapid resends “All codes remain valid” “I never got a code, but my bank app shows a request” Confirm OOB challenge Issuer or ACS Approve in the bank app and return to checkout “Wait for the SMS” “My bank says it was approved, but the checkout failed” Check authentication result, authorization, and session recovery Merchant, provider, issuer Verify order state before retrying “The code was wrong” “The page disappeared when I opened Messages” Check session restoration and duplicate attempts Merchant, browser, device Restore or restart safely after checking order status “Start over immediately” “The message is in spam” Confirm sender was filtered Device or messaging app Move or unblock it and use a current code “Your bank did not send it” “Resend does nothing” Determine whether resend event is exposed Issuer or ACS Wait, choose another issuer method, or restart cleanly “Our checkout can force another SMS” What to Measure

Do not report an “OTP delivery rate” unless the merchant actually receives reliable issuer or messaging-delivery telemetry. Instead, measure what the integration can observe. Challenge-method distribution Challenges by known method ÷ challenged authentication attempts with a known method This helps separate OTP issues from app-based authentication. Resend-interaction rate OTP challenges with a recorded resend interaction ÷ OTP challenges where resend telemetry is available This is not a delivery-failure rate. Customers may resend for several reasons. Time to authentication completion Measure from challenge rendering to final authentication result. Report medians and upper percentiles, segmented by: * Country * Issuer * Device * Browser versus app * Challenge method * Provider Challenge-completion rate Successfully completed challenges ÷ rendered challenges Do not use initiated authentications as the denominator unless the metric is labeled differently. Timeout rate Timed-out challenges ÷ rendered challenges Separate issuer-reported timeout from merchant-session timeout where possible. Cancellation rate Canceled challenges ÷ rendered challenges Cancellation is not the same as technical failure. Authentication technical-error rate Challenges ending in a technical error ÷ initiated or rendered challenges included in the defined population State which technical statuses are included. Session-recovery rate Successful authentication results correctly re-associated with a live payment intent

÷ successful challenged authentications requiring return to checkout This measures merchant-side continuity rather than OTP delivery. Alternative-method recovery rate Payment intents completing through another available method ÷ failed or abandoned challenges offered an alternative Final order-completion rate Completed orders ÷ payment intents entering a challenge This is the commercial outcome, but its denominator differs from challenge completion. Support-contact rate Support contacts concerning code or challenge problems ÷ challenged payment intents Tag support cases by the customer’s description and the eventual technical classification. Customer wording such as “code missing” should not automatically become the internal root cause. Segmentation That Matters Authentication-code problems should be reviewed by: * Issuer * Country * Customer location * Roaming status where legitimately available * Browser versus native application * Operating system * SMS, email, or out-of-band method * New versus returning customer * Card network * Payment provider * Checkout version * Authentication result * Timeout reason * Resend usage * Session-recovery outcome A global blended rate can hide a problem concentrated in one issuer, network route, browser flow, or market. Testing and Validation Merchants cannot safely A/B test whether an issuer sends codes, but they can test the recovery experience around the challenge. Test merchant-controlled elements Suitable tests include:

* Clearer explanation of bank-controlled verification * SMS-versus-app guidance based on known challenge method * Visibility of alternative payment methods * Session restoration after backgrounding * Duplicate-attempt prevention * Recovery after timeout * Support escalation with transaction identifiers * Mobile-browser return behavior Simulate infrastructure conditions Test: * Slow return from authentication * Backgrounded browser * Closed or reloaded tab * Banking-app switching * Multiple callback delivery * Customer retry after timeout * Second payment attempt while the first remains unresolved * Unknown authentication result * Alternative method selection Guardrails Monitor: * Duplicate orders * Duplicate authorization attempts * Fraud * Chargebacks * Authentication success * Authorization approval * Support contacts * Technical errors * Completed orders * Customer complaints What Would Disprove the Leading Hypothesis? The article’s leading hypothesis is that better ownership communication and checkout recovery can reduce avoidable losses even when merchants cannot control OTP delivery. That hypothesis would be weakened if: * Improved guidance does not change support contacts or completion * Session restoration has no relationship with order completion * Most failures are proven issuer-side outages with no merchant recovery opportunity * Alternative-payment presentation creates confusion without recovering orders

* Customers already understand the authentication method and are blocked solely by issuer contact records In that case, merchant effort should shift from interface changes to provider escalation, issuer-level analysis, or alternative payment availability. Merchant Action Plan Check immediately * Does checkout claim the merchant sent the code? * Does support assume the checkout phone number is used? * Can the challenge method be identified? * Are OTP and app-based challenges separated in reporting? * Can support see authentication status without seeing sensitive values? * Does checkout survive app switching and browser backgrounding? * Are duplicate payment attempts prevented? Fix first Prioritize: 1. Incorrect ownership language 2. Broken return-to-checkout behavior 3. Authentication and authorization being combined in reporting 4. Support scripts that promise issuer-controlled outcomes 5. Unsafe retry flows that create duplicate attempts 6. Missing alternative-payment recovery 7. Lack of stable authentication and payment identifiers Investigate next Determine: * Which issuers generate the most code-related support contacts * Whether timeouts cluster by device or browser * Whether customers expect SMS during app-based challenges * Whether repeated resends correlate with failed authentication * Whether successful authentications are being lost during session recovery * Whether provider statuses are detailed enough for diagnosis Do not change without evidence Do not:

* Assume merchant phone validation will fix issuer OTP delivery * Ask customers to disclose authentication codes * Encourage repeated resend requests * Advise customers to restart before checking order and payment state * Treat OTP failure as an authorization decline * Promise that an issuer will offer SMS * Promise that a delayed code remains valid * Claim a message was delivered without telemetry * Disable authentication merely because code challenges create friction Conclusion A missing authentication code appears to be a message problem. It may instead be an identity-record problem, an issuer-method problem, a telecom-routing problem, a roaming problem, a device-filtering problem, a timing problem, a code-version problem, or a checkout-session problem. The merchant participates in this system, but does not control all of it. The most effective merchant response is to identify the current owner of each stage: Issuer challenge decision → Method selection → Contact or device lookup → Code generation → Delivery handoff → Telecom routing → Device receipt → Customer entry → Issuer validation → Checkout recovery Merchants should improve the parts they can control: accurate messaging, resilient sessions, clear retry logic, alternative-payment recovery, useful reporting, and support escalation backed by transaction identifiers. They should be equally explicit about what they cannot control.

Original Practical Asset: Authentication Code Delivery Chain Issuer decides to challenge ↓ Issuer selects SMS, email, app, or another method ↓ Issuer identifies registered contact or device ↓ Code or approval request is generated ↓ Messaging provider accepts the request ↓ Telecommunications network routes the message ↓ Customer device receives or filters it ↓ Customer finds and enters the code ↓ Issuer validates the code ↓ Customer returns to a live checkout session The chain should be used by payment operations, product, engineering, and support teams to classify every “code not received” report by the last stage known to have succeeded.

This execution follows the uploaded authentication-friction brief, especially its OTP-delivery chain, control-boundary analysis, infrastructure-walkthrough format, recovery focus, and requirement not to treat the checkout phone field as the source of every authentication code. Editorial-Brief Interpretation The reader is dealing with a deceptively simple complaint: “The verification code never arrived.” From the merchant’s perspective, however, that complaint may describe several different failures. The issuer may have an outdated telephone number. The issuer may have selected banking-app approval instead of SMS. A message may have been generated but delayed or filtered. The customer may be entering an earlier code after requesting another. Authentication may have succeeded while the merchant’s checkout session failed to recover. The article must therefore follow the code through the hidden infrastructure behind the visible checkout, identify who controls each stage, and show merchants how to improve recovery without promising control they do not have. Unique Evidence Anchor In many issuer-controlled 3-D Secure challenges, the merchant neither generates the authentication code nor chooses the phone number or delivery channel used to send it. EMVCo describes the cardholder as providing challenge information directly to the issuer-side Access Control Server. Visa’s current 3DS guidance says issuers choose which OTP delivery channels are available. (EMVCo) Editorial Position

Merchants should design for recovery, observability, and clear ownership, not assume that an authentication-code problem can be fixed by changing the checkout phone-number field. Common Assumption Being Challenged “The code is sent to the phone number the customer entered during checkout.” That can be true in some payment or identity flows, but it is not a safe assumption for issuer-controlled 3DS authentication. The issuer or its ACS may use contact information or a registered device associated with the cardholder’s banking relationship, and it may select an app-based challenge instead of SMS. (Visa Developer) Selected Format and Structural Rationale Format: Hypothetical support scenario followed by an infrastructure walkthrough. The article begins with the customer-visible symptom, follows the authentication request through issuer and telecommunications systems to the customer’s device, and then follows the customer back into checkout. This reveals two separate journeys: 1. The code or approval request reaching the customer 2. The customer and authentication result returning to a live payment session Proposed Article Architecture 1. The code that never arrives 2. Direct answer: why authentication codes go missing 3. Who actually sends the code 4. The Authentication Code Delivery Chain 5. Issuer contact-data failures 6. Telecommunications and roaming failures 7. Device and message-filtering failures 8. Timing, expiration, and resend problems 9. SMS versus banking-app authentication

10. Authentication success followed by checkout-session failure 11. What merchants can observe 12. What merchants can improve 13. Customer-support troubleshooting matrix 14. Measurement and testing Merchant action plan

SEO Metadata SEO title: Why Customers Do Not Receive Authentication Codes Recommended H1: Why Customers Do Not Receive Authentication Codes During Payment Meta description: Learn why 3D Secure codes may not arrive, who controls OTP delivery, how SMS and app authentication fail, and what merchants can improve. URL slug: /why-customers-do-not-receive-authentication-codes Primary keyword: why customers do not receive authentication codes Secondary keywords: * 3D Secure code not received * Authentication code not received * OTP not received payment * 3DS OTP failure * Payment verification code not received * Card verification text not received * Authentication SMS delayed * 3D Secure SMS failure * Bank verification code missing * Payment authentication code problem Article excerpt: A missing payment-authentication code may be caused by outdated issuer records, message generation, telecom routing, roaming, device filtering, expiration, repeated resends, or checkout-session loss. Merchants can improve guidance and recovery, but they often do not control the number or channel the issuer uses. Internal-Link Recommendations * What Is 3D Secure? * Why 3D Secure Causes Checkout Abandonment * Frictionless Authentication vs. Challenge Flows * Strong Customer Authentication and Conversion * How Authentication Configuration Affects Approval Rates * Mobile Checkout Optimization * How Phone-Number Validation Causes Checkout Failure * Authorization Rate vs. Payment Conversion Rate * How to Diagnose Checkout Drop-Off

Authoritative Source Recommendations * EMVCo challenge-flow documentation: Issuer-side ACS control, OTP, and banking-app authentication. (EMVCo) * Visa OTP experience guidelines: Issuer-selected SMS and email channels, masked destinations, resend controls, and OTP challenge UX. (Visa Developer) * EMVCo browser out-of-band flow: App switching, challenge timeouts, lost browser state, and recovery recommendations. (EMVCo) * Mastercard authentication documentation: Issuer mobile-application and OTP authentication options. (Mastercard Developers) * 3GPP SMS specification: Technical realization of SMS across mobile networks. (3GPP Portal) * GSMA roaming documentation: SMS roaming and visited-network context. (GSMA) * Apple and Google support documentation: Unknown-sender and spam filtering that can hide received messages. (Apple Support)

Supporting Visual Concept “Where the Authentication Code Can Disappear” Create a horizontal timeline divided into five ownership zones. Issuer zone 1. Challenge decision 2. Authentication method selected 3. Registered contact or device identified 4. Code or app request generated Potential failures: * Outdated number * Wrong method expected * Issuer service problem * Rate limit Messaging-provider zone 5. Message accepted 6. Message passed toward mobile network Potential failures: * Provider rejection * Routing delay * Sender filtering Telecommunications zone 7. Home network routing 8. International or roaming handoff 9. Destination-network delivery Potential failures: * Roaming unavailable * Routing failure * Network delay * No cellular service Customer-device zone 10. Message received 11. Notification displayed 12. Customer retrieves code Potential failures: * Spam folder * Unknown-sender filter * Wrong SIM * Blocked sender * Notification disabled Merchant and checkout zone 13. Customer enters code 14. Issuer validates it 15. Customer returns to checkout 16. Order continues Potential failures: * Old code entered * Code expired * Earlier code invalidated * Browser session lost * Duplicate attempt Bottom takeaway: The merchant owns the recovery experience—not every part of code delivery. Recommended alt text: “Authentication-code delivery timeline showing issuer, messaging provider, telecom network, customer device, and merchant checkout failure points.” Proposed Author and Reviewer Attribution

Real names must be assigned before publication. Author:

Payments reviewer:

Support and operations reviewer:

Required first-hand contribution: Add a verified observation answering: How do customers most commonly describe authentication-code failures, and which explanations do support teams initially assume incorrectly? Do not attribute a quotation or support pattern until the contributor, wording, role, and approval are verified. Last reviewed: [Insert verified review date] Technical Fact-Check Items

* Confirm whether OTP request and resend events are visible. * Confirm available authentication status and reason codes.

* Confirm browser and native-app return handling. * Confirm session-restoration behavior after app switching. * Confirm how duplicate authentication and payment attempts are detected. * Confirm whether successful authentication results can be retrieved asynchronously. * Confirm what support teams can see in internal tools. * Confirm escalation identifiers available for issuer or provider investigation. * Confirm that OTP values are never logged or requested by support. * Review the age and terminology of the public Brick 3D Secure page. Regulatory Fact-Check Items Regulation is not central to this article, but before publication: * Do not imply that OTP is required globally. * Do not present EEA or UK Strong Customer Authentication rules as universal. * Do not imply that SMS OTP always satisfies applicable authentication requirements. * Distinguish regulatory requirements from issuer-selected challenge methods. * Link detailed regulatory questions to the Strong Customer Authentication article. * Confirm any market-specific statement with legal and compliance reviewers. Amber-Flag Claims These require specialist review: * Any claim that a particular issuer uses the checkout phone number * Any claim that a carrier delivered or blocked a message * Any statement about universal OTP-expiration periods * Any claim that requesting a new code always invalidates the previous one * Any claim that roaming causes SMS failure in a specific market * Any numerical OTP-delivery or abandonment benchmark

* Any claim that alternative authentication is always available * Any claim that better recovery will produce a stated conversion lift

* Supported protocol versions * Challenge-method visibility * OTP and resend event visibility * Authentication result and reason-code reporting * Timeout handling * App-based and browser-based challenge support * Session-preservation behavior * Asynchronous result retrieval * Retry and duplicate-attempt logic * Alternative-payment recovery * Issuer-level authentication reporting * Customer-support tooling * Escalation processes for issuer-side failures * Current support scripts * Any anonymized support patterns

Cluster-Wide Sameness Audit Fields Field This article Title Why Customers Do Not Receive Authentication Codes During Payment First sentence A customer reaches a payment-authentication screen and waits for a text message. Opening device Hypothetical support case with incomplete merchant visibility Primary format Infrastructure walkthrough and troubleshooting matrix Evidence anchor Issuer often controls OTP generation, destination, and delivery channel Editorial position Design for recovery and ownership, not checkout-only fixes Common assumption challenged Checkout phone number is always used for the code Original framework Authentication Code Delivery Chain Main example Customer repeatedly resends while support cannot see issuer or telecom events Supporting visual Code-delivery timeline divided by control owner Closing argument The merchant owns recovery but not every delivery stage CTA

FAQ alternative Customer-support troubleshooting matrix

Prompt used to generate this article:

The article-specific editorial brief below is the only variable input. It controls the topic, keyword strategy, audience, evidence anchor, thesis, format, structure, examples, original asset, human contribution, research priorities, and internal-linking role. The remaining instructions are constant editorial standards. They must support the brief without forcing every article into the same shape.

ARTICLE-SPECIFIC EDITORIAL BRIEF BEGIN EDITORIAL BRIEF EDITORIAL BRIEF 6 WHY CUSTOMERS DO NOT RECEIVE AUTHENTICATION CODES Article topic Why Customers Do Not Receive Authentication Codes Working title Why Customers Do Not Receive Authentication Codes During Payment Primary keyword why customers do not receive authentication codes Secondary keyword targets * 3D Secure code not received * authentication code not received * OTP not received payment * 3DS OTP failure * payment verification code not received * card verification text not received * authentication SMS delayed * 3D Secure SMS failure * bank verification code missing * payment authentication code problem Search intent Technical troubleshooting and customer-experience diagnosis. Primary audience * Payment operations teams * Customer-support teams * Product managers * Developers * Ecommerce leaders * Fraud teams Audience sophistication Mixed. Geographic scope Global. Primary evidence anchor Anchor the article in this control-boundary distinction: In many 3-D Secure flows, the merchant does not generate the authentication code and may not control the phone number or delivery channel used by the issuer. This explains why merchants often cannot solve OTP failures solely by changing the checkout phone field. Primary reader problem

Customers report that they never received a code, but the merchant cannot see whether the code was generated, which contact information was used, whether the message was delivered, or whether another authentication method was available. Desired reader outcome The reader should be able to map the OTP delivery chain, identify observable and unobservable failure points, improve customer recovery, and avoid promising fixes outside merchant control. Unique thesis An authentication-code failure is rarely one problem. It can result from issuer contact records, telecommunications delivery, roaming, device conditions, delays, customer misunderstanding, app-based authentication, repeated-code invalidation, or merchant session recovery. Editorial position Merchants should design for recovery and clear ownership, not assume that code delivery can be fixed inside the checkout. Common assumption being challenged “The code is sent to the phone number the customer entered during checkout.” That may not be true in issuer-controlled authentication. Editorial influence Apply the hidden-infrastructure reporting qualities associated with Christopher Mims without imitating his prose. Editorial qualities to apply * Follow one code through the systems required to create and deliver it. * Reveal infrastructure customers and merchants do not see. * Translate technical dependencies into operational consequences. * Clearly identify control boundaries. * Use a timeline to show where delays and failures can occur.

* Avoid blaming the customer, merchant, bank, or telecom provider without evidence. Article format Anonymized scenario and infrastructure walkthrough Opening approach Begin with a customer pressing “send code again” several times while the merchant support team has no visibility into whether the issuer generated or delivered the code. Structural principle Follow the code from authentication decision to customer device, then follow the customer back to checkout. Article-owned territory Cover: * Who typically initiates the code challenge * Issuer-held contact information * Merchant-held phone information * SMS delivery chain * Telecom routing * Roaming * Delays * Device and network issues * Blocked or filtered messages * Outdated issuer records * Multiple code requests * Code expiration * App-based or out-of-band alternatives * Customer recognition * Merchant observability * Session preservation * Retry and alternative-payment recovery * Support guidance Topics to mention briefly * Checkout phone-field validation * General 3DS abandonment * Strong Customer Authentication * Risk-based authentication * Challenge reduction Topics to exclude or delegate Do not turn this into: * A general phone-number validation article * A telecommunications compliance guide * A full 3DS explanation * A complete SCA guide * A generic customer-support script collection Required distinctions * Merchant checkout phone number versus issuer account phone number * Code generation versus delivery * Delivery versus customer access

* SMS challenge versus banking-app approval * Resend request versus new valid code * OTP failure versus checkout session loss * Merchant observability versus issuer observability Required examples Include: * Issuer has an outdated phone number * Customer is roaming * Message is delayed and arrives after expiration * Several code requests invalidate earlier codes * Customer expects SMS but issuer requires banking-app approval * Customer leaves the checkout to retrieve the code and loses session state * Merchant support incorrectly tells the customer that the checkout phone number will be used Original framework The Authentication Code Delivery Chain 1. Challenge decision 2. Issuer selects authentication method 3. Issuer identifies contact or device 4. Code or approval request is generated 5. Delivery provider receives the message 6. Telecommunications network routes it 7. Customer device receives or filters it 8. Customer finds and enters the code 9. Issuer validates it 10. Customer returns to a live checkout session For each stage, identify: * Primary owner * Possible failure * Merchant visibility * Customer-facing symptom * Recovery option Measurement requirements Where observable, track: * Challenge method * Code-request event * Resend event * Time to completion * Timeout * Challenge completion * Cancellation * Technical error * Session recovery * Alternative method selection * Support contact * Final order completion

Do not claim merchants can measure issuer-side code generation or telecom delivery unless the implementation provides that visibility. Human contribution Use both:

* A customer-support or operations reviewer The best contribution would be a verified support pattern showing how customers describe code failures and which explanations are commonly incorrect. Research priorities * Official issuer or network authentication documentation * Telecommunications authority information * Mobile-platform documentation

* Accessibility and customer-recovery guidance Internal-link targets * Why 3D Secure Causes Checkout Abandonment * What Is 3D Secure? * Frictionless Authentication vs Challenge Flows * Strong Customer Authentication and Conversion * How Authentication Configuration Affects Approval Rates Differentiation requirement This article owns OTP and authentication-code delivery failures. It should not explain all challenge abandonment or general phone formatting. Suggested architecture 1. The code that never arrives 2. Who actually sends the authentication code? 3. The Authentication Code Delivery Chain 4. Issuer contact-data failures 5. Telecommunications and device failures 6. Customer-experience and timing failures 7. Why repeated code requests can make the problem worse 8. What merchants can observe 9. What merchants can improve 10. A customer-recovery playbook FAQ approach Use a customer-support troubleshooting matrix. Supporting visual Create a code-delivery timeline with control ownership. END EDITORIAL BRIEF

1. EDITORIAL-BRIEF PRIORITY Treat the editorial brief as the controlling document. Follow it when deciding: * What the article is built around * Which evidence or distinction anchors the piece * What position the article takes * Which reader problem it solves * Which search intent it owns * Which format it uses * How it opens * How the argument unfolds * Which topics receive depth * Which topics are mentioned briefly * Which topics belong in other articles * Which examples are used * Which original framework or asset is developed * Which human expertise is included * Which metrics matter * Which internal links are appropriate Do not replace the brief’s direction with a generic article template. Before drafting, determine privately: 1. What unique evidence, distinction, scenario, or expert observation anchors the article. 2. What definitive but defensible position the article takes. 3. What common assumption it challenges or corrects. 4. What structural format best serves the material. 5. How it differs from every adjacent article in the series. 6. What original value it contributes beyond existing search results.

Complete these statements privately: “The unique anchor for this article is…” “The position this article takes is…” “The format selected for this article is…” “This article is different from the rest of the series because…” Do not begin drafting until each statement has a specific answer.

2. SERIES CONTEXT The authentication-friction series includes: 1. What Is 3D Secure? 2. Why 3D Secure Causes Checkout Abandonment 3. 3D Secure 2 Explained 4. Frictionless Authentication vs Challenge Flows 5. How to Reduce Unnecessary 3DS Challenges 6. Why Customers Do Not Receive Authentication Codes 7. Strong Customer Authentication and Conversion 8. SCA Exemptions Explained 9. Risk-Based Authentication 10. Delegated Authentication 11. How Authentication Configuration Affects Approval Rates Each article must work independently while owning a distinct search intent, merchant decision, authentication stage, failure mode, or technical distinction. Do not reproduce another article’s full explanation when a concise distinction and internal link will serve the reader better. At least 70% of the finished article must be substantively specific to its editorial brief.

3. SEPARATE STANDARDS FROM SOURCE MATERIAL Treat the assignment as three layers. Constant standards The instructions in this master prompt establish: * Factual accuracy * Technical precision * Regulatory qualification * Amber-flag discipline * No unsupported superlatives * No fabricated claims * Clear control boundaries * Merchant relevance * Human accountability * Series differentiation Editorial brief The editorial brief determines: * Evidence anchor * Thesis * Position * Format * Structure * Scope * Examples * Original asset * Human contribution * Metrics * Research priorities Source material Source material may include: * Previous drafts

* Case studies * Expert notes * Interviews * Product documentation * Technical specifications * Regulatory sources * Merchant observations * Published research Use source material for evidence and insight. Do not automatically preserve its organization. Do not allow a previous draft to dictate the final structure when the editorial brief calls for a better approach.

4. BUILD BACKWARD FROM THE UNIQUE ANCHOR Do not build the article forward from the keyword alone. Build it backward from the strongest unique element identified in the editorial brief, such as:

* A specific merchant outcome * An anonymized case * A technical distinction competitors commonly miss * A market-specific pattern * An issuer-level difference * A device or browser failure * A measurable authentication contradiction * An expert observation * A regulatory distinction with practical consequences * A clearly labeled hypothetical scenario that exposes a system failure Use the keyword to make the article discoverable. Do not let the keyword determine the intellectual structure. The anchor should influence: * Opening * Thesis * Section order * Examples * Framework * Measurement * Conclusion If the supplied anchor is unverified, label it appropriately and identify the verification required.

5. TAKE A CLEAR EDITORIAL POSITION The article must reach a useful conclusion. Do not remain artificially neutral when the evidence supports a defensible position. A strong position should explain: * What merchants commonly misunderstand * Why the common view is incomplete * What the evidence indicates * What merchants should prioritize * Which metric should guide the decision * What should not be optimized in isolation * Under which conditions the conclusion changes A qualified position is acceptable. A vague conclusion is not. Avoid ending with: * It depends. * Every merchant is different. * Security and conversion must be balanced. * Testing is important. * There is no single answer. When the answer depends on context, identify: * Which variables matter * What the recommended default is * What evidence justifies an exception * How merchants should classify their situation

6. VARY THE ARTICLE FORMAT Do not default every article to a comprehensive-guide format. Use the format specified or implied by the editorial brief. Appropriate formats may include: * Definition or quick-answer page * Decision framework * Contrarian analysis * Anonymized merchant scenario * Comparison article * Myths-versus-reality article * Diagnostic playbook * Data-led analysis * Technical walkthrough * Regulatory decision tree * Configuration scorecard * Visual or interactive tool * Failure taxonomy * Expert commentary piece The format must shape the article materially. It should affect: * Opening * Section sequence * Use of tables * Examples * Framework * Conclusion * Supporting visual * Presence or absence of an FAQ Do not merely label an ordinary guide as a different format.

7. STRUCTURAL FREEDOM Do not impose one H2 or H3 pattern across the series. Build the structure around the article’s: * Evidence anchor * Position * Search intent * Reader sophistication * Technical depth * Regulatory scope * Original asset * Natural argumentative progression Possible structural approaches include: * Follow one transaction through the authentication chain. * Work backward from a failed authorization. * Organize around merchant decisions. * Alternate customer-visible symptoms with system causes. * Build around a set of myths. * Center the article on a comparison matrix. * Present the article as an investigation. * Begin with a result and reveal how it occurred. * Use a failure chain. * Use a decision tree. * Use a diagnostic sequence. * Use a before-and-after merchant scenario. Do not default to: 1. Introduction 2. What is it? 3. Why it matters 4. Benefits 5. Challenges 6. Best practices 7. Conclusion 8. FAQ unless that structure genuinely suits the article.

8. OPENING REQUIREMENTS Follow the opening approach in the editorial brief. Possible opening devices include: * Direct answer * Verified data point * Anonymized merchant scenario * Contradiction * Technical failure sequence * Merchant decision * Customer journey * Myth correction * Regulatory distinction * Comparison Avoid repeating the same opening device across adjacent articles. Do not begin with: * “In today’s digital economy” * A dictionary definition * A generic fraud statistic * A rhetorical question followed by a statistic in every article * A broad claim that 3-D Secure balances security and conversion * An introduction that could be reused unchanged elsewhere Answer the article’s primary question near the beginning. The direct answer should normally be understandable when quoted independently.

9. TECHNICAL ACCURACY Use technically precise terminology. Where relevant, distinguish: * 3-D Secure * 3DS * 3DS2 * Authentication * Authorization * Verification * Frictionless authentication * Challenge flow * Challenge completion * Authentication success * Authentication failure * Customer abandonment * Technical failure * Timeout * Cancellation * One-time password * Out-of-band authentication * Strong Customer Authentication * Exemption * Exclusion * Transaction-risk analysis * Risk-based authentication * Delegated authentication * Soft decline * Hard decline * Approval rate * Checkout conversion * Completed-order rate * Retained revenue Do not use connected but distinct events interchangeably. Explain where relevant that: * Authentication and authorization are separate. * Successful authentication does not guarantee approval. * Frictionless authentication does not mean no authentication assessment occurred. * A challenge does not necessarily indicate failure. * An exemption request does not guarantee acceptance. * Merchant configuration does not fully control issuer decisions. * Challenge rate and challenge-completion rate measure different outcomes. * Approval rate and checkout conversion use different denominators.

10. AUTHENTICATION-SYSTEM CONTEXT When relevant, place the article within this broader lifecycle: Customer begins checkout → Merchant collects transaction and payment information → Authentication request is prepared → Transaction and device data are supplied → 3-D Secure infrastructure processes the request → Issuer or access-control server assesses risk → Frictionless result or challenge requested → Customer completes, fails, abandons, or times out → Authentication result returns → Authorization request is submitted → Issuer approves or declines → Merchant confirms or recovers the order → Payment is captured → Fraud, refunds, and chargebacks emerge later Identify only the stages relevant to the editorial brief. Do not repeat the entire lifecycle in every article.

11. CONTROL-BOUNDARY DISCIPLINE Clearly distinguish what is controlled or influenced by each party. Merchant Potential areas include: * Checkout explanation * Integration quality * Transaction-data quality * Authentication configuration * Exemption-request strategy * Recovery experience * Alternative payment methods * Analytics * Customer communication Payment provider or gateway Potential areas include: * Data mapping * Protocol support * Routing * Configuration options * Error handling * Reporting * Result transmission * Soft-decline recovery support Card network and authentication infrastructure Potential areas include: * Protocol rules * Directory services * Message exchange * Network-specific programs * Authentication-value handling Issuer or access-control server Potential areas include: * Risk decision * Frictionless or challenge outcome * Challenge method * OTP generation * Customer contact records * Exemption acceptance * Authentication result * Authorization decision Customer and device environment Potential areas include: * Browser behavior * Network access * Banking-app access * Phone availability * Device switching * Recognition of the challenge * Ability or decision to complete it Do not assign responsibility to one party without evidence.

12. AMBER-FLAG DISCIPLINE Use extra caution for claims involving: * Regulatory interpretation * Issuer behavior * Network-specific requirements * Provider-specific support * Country-wide generalizations * Conversion causality * Fraud outcomes * Chargeback outcomes * Liability shift * Approval-rate changes * Time-sensitive protocol support * Exemption eligibility * Delegated-authentication availability For each amber-flag claim: 1. Identify the relevant jurisdiction, market, network, issuer, or provider. 2. Confirm the supporting source. 3. State material limitations. 4. Avoid universal wording. 5. Mark the statement for specialist review when necessary. Appropriate qualification may include: * May * Can * In this market * For participating issuers * Under these conditions * Depending on implementation * Subject to issuer acceptance * Merchants should verify * The result should be tested Do not hedge facts that are firmly established.

13. REGULATORY SAFEGUARDS When discussing Strong Customer Authentication, exemptions, exclusions, or delegated authentication: * Identify the applicable jurisdiction. * Do not present EEA or UK rules as global. * Distinguish regulation from network rules. * Distinguish an exemption from an exclusion where applicable. * Explain who requests an exemption. * Explain who accepts or rejects it. * Acknowledge issuer discretion. * Avoid legal advice. * Verify current conditions and thresholds using official sources. * Do not declare eligibility without sufficient facts. * State when an explanation is simplified. Include an educational disclaimer when regulation is a material part of the article: This article provides general information and does not constitute legal or regulatory advice. Merchants should confirm applicable obligations with qualified advisers and relevant payment partners. Do not add the disclaimer mechanically when the article does not materially concern regulation.

14. NO-SUPERLATIVE RULE Avoid unsupported claims such as: * Best * Leading * Most advanced * Highest-performing * Seamless * Friction-free * Guaranteed * Industry-leading * Unmatched * Optimal * Superior Use a superlative only when: * The comparison group is defined. * The metric is stated. * The period is stated. * The evidence is approved. * The comparison is materially relevant. Be especially careful with the word “frictionless.” When describing the formal authentication outcome, make clear that it is a protocol classification rather than a claim that the entire customer experience had no friction.

15. NO FABRICATION Never invent: * Statistics * Conversion lifts * Approval-rate changes * Challenge-rate reductions * Fraud improvements * Chargeback results * Exemption acceptance * Customer quotations * Merchant stories

* Product capabilities * Regulatory requirements * Issuer behavior * Network rules * Research findings * Human credentials * Expert opinions * Review status When evidence is unavailable: * Use a clearly labeled hypothetical example. * State what would need to be verified. * Avoid numerical precision. * Do not imply that an outcome occurred. * Add the point to the verification list.

16. SOURCE STANDARDS Prioritize: 1. Official regulatory sources 2. EMVCo documentation 3. Official card-network documentation 4. Government and supervisory authorities 5. Official technical documentation 6. National telecommunications authorities 7. Browser and platform documentation 8. Academic and peer-reviewed research 9. Original merchant data 10. Original industry datasets

12. Reputable secondary analysis For every consequential claim: * Find the most authoritative available source. * Confirm it supports the exact claim. * Check the publication date. * Confirm the applicable protocol version. * Confirm the jurisdiction. * Distinguish requirements from recommendations. * Distinguish protocol capability from implementation. * State significant methodological limitations. * Distinguish correlation from causation.

17. HUMAN CONTRIBUTION AND ACCOUNTABILITY Every published article should have: * A named author * A meaningful role or credential * A named technical, risk, compliance, or payments reviewer where appropriate * A last-reviewed or updated date when relevant Include a genuine first-hand contribution where available, such as: * An expert observation * An implementation lesson * An anonymized merchant pattern * A technical caution * A market-specific insight * An attributed quotation

Do not invent: * Authors * Reviewers * Credentials * Quotations * Anecdotes * Review completion When attribution has not yet been assigned, mark it as an editorial requirement rather than fabricating it.

18. ORIGINAL ARTICLE ASSET Each article must contribute at least one original asset. Possible assets include: * Decision matrix * Authentication lifecycle * Failure taxonomy * Diagnostic sequence * Control-boundary map * Comparison table * Metric stack * Configuration scorecard * Myth-versus-reality table * Issuer segmentation model * Exemption decision tree * OTP failure chain * Transaction map * Merchant audit * Interactive calculator * Visual decision tool The asset must help the reader: * Understand the system * Diagnose a problem * Compare approaches * Make a decision * Prioritize action * Measure an outcome * Communicate across teams Do not recycle the same framework under a new name.

19. MEASUREMENT DISCIPLINE Define every important metric precisely. Potential metrics include: * Authentication initiation rate * Frictionless rate * Challenge rate * Challenge-render rate * Challenge-completion rate * Authentication success rate * Authentication technical-error rate * Cancellation rate * Timeout rate * OTP delivery rate * OTP completion rate * Exemption-request rate * Exemption-acceptance rate * Soft-decline rate * Soft-decline recovery rate * Post-authentication approval rate * Completed-order rate * Fraud rate * Chargeback rate * Retained-revenue conversion State the denominator for every metric. For example: Challenge rate Challenged authentication attempts ÷ eligible authentication attempts × 100 Challenge-completion rate Successfully completed challenges ÷ rendered challenges × 100 Post-authentication approval rate Approved authorization attempts following authentication ÷ authorization attempts following authentication × 100 Do not compare metrics with different eligible populations as though they are equivalent. Do not optimize one metric without appropriate guardrails.

20. SEGMENTATION Where relevant, segment results by: * Country * Regulatory market * Device * Browser * Operating system * Browser versus application * Issuer * Card network * Card type * Authentication version * Challenge method * Payment provider * Customer type * New versus returning customer * Order value * Currency * Risk profile * Exemption type * Authentication result * Authorization result * Soft-decline status * Checkout version Do not rely solely on a blended global average. Explain why the segments selected matter to the article’s thesis.

21. TESTING AND VALIDATION Explain how recommendations should be evaluated. Possible methods include: * Controlled configuration changes * A/B testing where appropriate * Country-level rollout * Issuer-level analysis * Device-level analysis * Payment-method comparison * Before-and-after analysis * Holdout groups * Soft-decline recovery analysis * Challenge-method analysis * Error-log review * User testing * Session analysis * Support-ticket analysis Potential guardrails include: * Fraud rate * Chargeback rate * Authentication success * Approval rate * Completed-order rate * Challenge rate * Challenge completion * Support volume * Refund rate * Technical errors * Customer complaints * Retained revenue State what evidence would disprove the article’s leading hypothesis. Do not recommend reducing authentication friction without considering fraud, compliance, issuer behavior, and downstream authorization.

Use only verified:

* First-party data * Product behavior * Operational observations * Merchant outcomes * Expert comments Do not: * Turn the article into a product page

* Guarantee frictionless authentication * Guarantee exemption acceptance * Guarantee higher approval rates * Promise regulatory compliance * Invent product features * Use unsupported superlatives * Criticize named competitors Where relevant, explain how an experienced payment partner may help merchants: * Implement authentication correctly * Improve transaction-data completeness * Review configuration * Analyze challenge performance * Segment issuer outcomes * Manage exemption requests * Recover soft declines * Compare authentication and authorization outcomes * Diagnose technical errors * Monitor conversion and fraud guardrails

23. SEO AND DISCOVERY Search optimization should support the article rather than dictate its structure. Use the keyword targets in the editorial brief naturally. Do not: * Force exact-match keywords into every heading * Repeat the same definition across all articles * Reuse the same FAQ questions * Cannibalize another article’s search intent * Select a structure solely because ranking competitors use it * Sacrifice technical accuracy for keyword inclusion Provide appropriate: * SEO title * H1 * Meta description * URL slug * Article excerpt * Internal links * Authoritative external sources * Supporting visual concept * Image alt text

24. FAQ FLEXIBILITY Do not add a standard FAQ block automatically. Use an FAQ only when it improves the article and suits the selected format. Alternatives include: * Questions answered contextually * A comparison table * A troubleshooting matrix * A glossary * A myth-correction section * A decision tree * A merchant checklist * A visual flow When an FAQ is used: * Make it article-specific. * Avoid repeating the body verbatim. * Avoid promotional answers. * Include regulatory qualifications when relevant. * Do not reuse the same questions across the series.

25. NATURAL AND ORIGINAL WRITING Create uniqueness through: * Evidence * Position * Structure * Format * Human contribution * Examples * Original assets * Editorial judgment Do not rely on superficial voice variation. Use: * Specific nouns * Concrete verbs * Topic-specific terminology * Logical transitions * Varied paragraph lengths * Counterexamples * Exceptions * Clear causal reasoning * Explicit uncertainty * Strong but supportable conclusions Avoid: * Generic fintech introductions * Repetitive rhetorical questions * A statistic-first opening in every article * Identical H2 structures * Formulaic conclusions * Excessive em dashes * Excessive three-part lists * Mechanical transitions * Empty thought-leadership language * Keyword stuffing * Fake anecdotes * Deliberate grammatical errors * Awkward phrasing intended to appear human Do not attempt to manipulate search engines or authorship-detection systems. Focus on substantive originality and human-reviewed usefulness.

26. ARTICLE-LEVEL QUALITY REVIEW Before delivering the article, review it privately. Editorial-brief review Confirm: * The article is built from the unique anchor. * It takes the assigned position. * It follows the selected format. * Its structure is specific to the material. * The original asset is central. * Scope boundaries are respected. * The article does not read like a keyword substitution. Technical review Confirm: * Authentication and authorization are distinguished. * Merchant and issuer control are distinguished. * Frictionless and challenge outcomes are described accurately. * OTP responsibilities are assigned correctly. * Protocol capabilities are separated from issuer behavior. * Soft declines and recovery are accurate where relevant. Regulatory review Confirm: * The jurisdiction is identified. * Current primary sources are used. * Exemptions and exclusions are distinguished where relevant. * Issuer discretion is acknowledged. * Legal advice is avoided. * The disclaimer is included only where needed. Evidence review Confirm: * Consequential claims are supported. * The evidence anchor is verified or labeled. * Limitations are stated. * Causal claims are defensible. * First-party claims are approved. * Nothing has been fabricated. Position review Confirm: * The article reaches a clear conclusion. * The conclusion follows from the evidence. * Opposing or incomplete views are addressed fairly. * The article avoids false neutrality. * Conditions and exceptions are clear. Originality review Confirm:

* The opening is distinct. * The format differs from adjacent articles where appropriate. * The original framework is unique. * Examples are not recycled. * The article offers more than rewritten consensus. * It would remain valuable even without the primary keyword. Human-accountability review Confirm: * The author attribution is real. * The reviewer attribution is real where required. * Credentials are accurate. * Human contributions are authentic. * Review claims are truthful.

27. CLUSTER-WIDE SAMENESS AUDIT Before publishing a group of authentication articles, compare them side by side. Extract from every article: * Title * First two sentences * First paragraph * H2 headings * H3 headings * Primary format * Evidence anchor * Editorial position * Original framework * Main example * Closing paragraph * CTA * FAQ questions or alternative closing element Flag repeated patterns when three or more articles share: * The same opening device * A rhetorical question followed by a statistic * The same number of major sections * The same heading sequence * The same definition-first structure * The same benefits-and-challenges progression * The same conclusion pattern * The same CTA * The same example type * The same framework shape * The same FAQ structure * The same paragraph rhythm When sameness appears, change substance rather than synonyms. Possible corrections include: * Replace the opening. * Select a different article format. * Rebuild the section order. * Center the piece on a different evidence anchor. * Remove repeated definitions. * Convert prose into a comparison table. * Replace a guide with a decision tree. * Turn a neutral overview into a defended position. * Add a genuine human observation. * Replace the conclusion with a recommendation or diagnostic tool. * Remove the FAQ. * Convert the article into a visual or interactive asset. Do not publish a cluster with unresolved major structural repetition.

28. DELIVERY REQUIREMENTS Deliver the finished assignment with: * A concise interpretation of the editorial brief * The unique evidence anchor * The article’s editorial position * The common assumption being challenged * The selected format and structural rationale * The proposed article architecture * The complete article * The original framework or practical asset * Appropriate SEO metadata * Internal-link recommendations * Authoritative source recommendations * A supporting visual or interactive concept * Proposed author and reviewer attribution * Technical fact-check items * Regulatory fact-check items where relevant * Amber-flag claims

* The fields needed for the cluster-wide sameness audit Do not add output sections that are irrelevant to the selected article format.

29. FINAL INSTRUCTION

They must not make all articles structurally identical. The editorial brief determines: * The article’s intellectual starting point * Its evidence anchor * Its position * Its format * Its opening * Its structure * Its human contribution * Its original asset * Its conclusion The finished article should not feel like a standard guide with a new keyword inserted. It should feel designed specifically for one authentication question, one merchant problem, one evidence base, and one editorial purpose. This keeps the editorial brief as the only insertion point while retaining the stronger requirements around structural variance, evidence-led briefs, clear positions, human accountability, and cluster-wide sameness review.