Fraud Controls
Part of Payment authentication and fraud controls
Understanding the steps in a payment authentication flow
A payment authentication flow may happen quietly or ask the shopper to take an extra step.
EMV 3-D Secure (3DS) adds a cardholder authentication stage to an online card payment. The flow runs from checkout, through a 3DS Server and Directory Server to the issuer’s Access Control Server (ACS), then into payment authorisation.
From checkout to issuer decision
- The shopper submits a card payment at checkout. Before the authentication request, the 3DS integration checks card enrolment and versioning, collects browser information, and may gather more information for transaction risk assessment.
- The 3DS Server is the integrator’s server or systems for handling online transactions; it facilitates communication between the 3DS Requestor and Directory Server (DS). Transaction and device data are packaged in an Authentication Request (AReq) and sent to the DS.
- The DS operates in the interoperability domain and routes messages between the 3DS Server and issuer ACS. It also authenticates the 3DS Server and validates the 3DS Server, 3DS SDK and 3DS Requestor.
- The ACS operates in the issuer domain. It checks whether authentication is available for the card number and device type, assesses the request, and authenticates specific cardholders. The issuer’s ACS returns an Authentication Response (ARes) with the authentication result.
- A frictionless outcome completes authentication without a customer prompt. If the issuer requires further verification, the challenge flow presents an interaction such as a one-time password or biometric authentication; after successful authentication, the transaction proceeds.
- After authentication, the integration can initiate payment authorisation. A successful authentication generates a cryptographic value that travels with the authorisation, but 3DS authentication does not itself process payment: TabaPay says its 3DS APIs verify identity and a separate Create Transaction API is needed to create the transaction.
Frictionless vs Challenge Authentication Outcomes
- Frictionless AuthenticationNo customer interaction required. Completed silently by issuer based on risk profile. Common for low-risk transactions in Australia.
- Challenge AuthenticationCustomer prompted to verify identity (e.g., one-time password, biometric). Required when risk thresholds are exceeded.
Separate authentication from final payment status
Authentication verifies identity; it does not create the payment transaction. TabaPay’s documentation says its 3DS APIs only verify identity and that its separate Create Transaction API is needed to create the transaction.
Treat the order as paid only after the payment step has succeeded, not because a challenge screen closed. A frictionless outcome can complete authentication without any visible customer prompt.
Test the states a buyer sees
Stripe’s sandbox simulations do not move funds. Its test cards can simulate successful card payments, declines, fraud or invalid data, and authentication with 3D Secure and PINs.
Use test API keys and test values, not real card details. Stripe notes that card-level state from one test can affect later tests using the same card, so use a different test card for each independent end-to-end scenario when the test depends on that state.
Testing 3DS Authentication Flows (Stripe Sandbox)
- Use Test API KeysNever use live credentials; test keys simulate real environments safely.
- Test Different Card StatesEach test card has persistent state; use unique test cards for independent scenarios.
- Simulate Real ScenariosTest successful payments, declines, fraud detection, and 3DS challenges (including PINs).
