Strong customer authentication testing is the verification of payment and banking flows that require a customer to prove their identity using at least two independent elements from the knowledge, possession and inherence categories. It checks that authentication, exemptions, challenges and failure handling follow the applicable rules and that the resulting transaction state is correct across connected systems.
What strong customer authentication testing covers
Strong customer authentication (SCA) is a regulatory authentication requirement in jurisdictions and payment contexts where it applies. Knowledge means something the customer knows, such as a password; possession means something they have, such as a registered device; inherence means something they are, such as a biometric characteristic. Two elements from the same category do not meet the two-category requirement. The elements must also be independent, so compromise of one does not compromise the other.
Testing checks the full authentication journey rather than only whether a challenge screen appears. For a card-not-present payment using 3-D Secure (3DS), this can involve the merchant, acquirer, card scheme and issuer's access control system. A transaction may proceed through a challenge, or through a frictionless flow in which the issuer authenticates without asking the customer to interact. The expected route depends on the transaction and the applicable rules.
SCA and multi-factor authentication (MFA) overlap, since both can use multiple authentication factors. SCA testing focuses on whether the relevant regulatory and payment requirements are met, including element independence and any applicable transaction-specific controls. A generic MFA test may check a second factor without verifying those payment requirements.
What to verify in a test
Start with the applicable jurisdiction, payment type, customer journey and configured SCA rules. Confirm which factors, exemptions and authentication outcomes are supported in the test environment. Exemptions have eligibility conditions, and their availability or application can depend on the payment provider and transaction context. A test should verify the decision and resulting flow rather than assume that every transaction must display a challenge.
Cover successful and unsuccessful paths. Check that valid factors allow the expected authentication outcome; an incorrect or unavailable factor does not grant access; and a customer who abandons or times out of a challenge does not leave a payment incorrectly authorised. Test retry limits, recovery or step-up behaviour where requirements specify them. For remote electronic payments, verify amount and payee binding, often called dynamic linking, where it applies.
Assert outcomes at the system boundary as well as in the user interface. For example, check the authentication result returned to the payment service, the payment's status, and the recorded reason when a challenge fails or an exemption is used. Confirm that retries do not create duplicate payments and that downstream notifications or audit records match the final transaction state. Keep test evidence free of real customer credentials and sensitive authentication data.
Practical example: a card payment challenge
Set up a test card and issuer simulator to require a 3DS challenge. Submit a payment for a defined amount and verify that the customer is routed to the challenge. Enter the valid test factor and confirm that the issuer returns a successful authentication result, the merchant receives the expected response, and the payment proceeds according to its configured authorisation flow.
Repeat with an invalid factor and with an abandoned challenge. In each case, verify that the payment is declined, cancelled or left in the specified pending state, and that the customer-facing message agrees with the recorded result. If the amount changes after authentication, check that the transaction is rejected or re-authenticated as required by the implementation. A challenge displayed successfully is insufficient evidence on its own: the authentication result and final payment state must also be consistent.
Common failure modes
Environment drift can make a test unreliable: issuer rules, test cards, authentication methods or exemption configuration may differ between test and production. A simulated challenge can also pass while the payment service mishandles the issuer's response. Other defects include treating a challenge timeout as approval, applying an exemption outside its configured conditions, or losing the authentication result between payment services.
Use traceable test cases linked to the relevant SCA rules and payment requirements. Correlate the user journey with service logs and transaction identifiers, while avoiding sensitive authentication data in logs. For related topics, see [3-D Secure authentication testing] and [Banking authentication exemption rule testing].
Frequently asked questions
Is a biometric by itself enough for strong customer authentication?
A biometric is an inherence element, so it does not by itself provide two elements from different categories. The flow needs another independent element, such as possession of a registered device, when SCA applies.
Does every online payment need a customer-facing challenge?
No. Depending on the transaction and applicable rules, authentication may complete without an interactive challenge, or an exemption may apply. Testing should verify the recorded decision and resulting payment outcome.
How should SCA tests handle customer authentication data?
Use provider-approved test credentials and controlled test environments. Do not store real passwords, one-time passcodes or other sensitive authentication data in test evidence, source control or application logs.