Fraud prevention and security
EMV 3-D Secure, commonly shortened to EMV 3DS, is a messaging protocol used to authenticate consumers during ecommerce card transactions. It lets a merchant-side 3DS service and a card issuer exchange information about the transaction, payment method, and device so the issuer can evaluate whether the shopper is entitled to use the card.
Authentication normally happens before payment authorization. The two steps are related but different: authentication evaluates the person presenting the card, while authorization is the issuer's decision on the payment request.
EMV 3DS adds an authentication exchange to a card-not-present checkout. According to EMVCo, the protocol gives issuers transaction, payment-method, and device data that can help them assess a purchase. Depending on the issuer's evaluation and the supported flow, the shopper may continue without a visible interruption or may be asked to complete an additional verification step.
The merchant does not independently authenticate the cardholder or choose the issuer's exact verification method. A payment gateway, 3DS server, card-network program, issuer, and other participating services may each have a role. The exact setup and supported transaction types depend on the merchant's selected ecommerce and payment providers.
After the shopper enters or selects a card, the merchant's connected payment environment initiates a 3DS authentication request when the transaction and configuration are eligible. Relevant checkout and device information is passed through the participating 3DS services.
The card issuer reviews the information it receives. EMVCo describes rich data exchange as a way for issuers to make authentication decisions while aiming to limit unnecessary checkout friction.
The authentication result is returned through the 3DS environment. The merchant's payment integration then handles the next supported step, which may include sending the separate authorization request.
For the wider sequence around these steps, see how online credit card payments work and the guide to ecommerce payment gateways.
A shopper may not always see a separate verification screen. In a frictionless flow, the issuer uses the exchanged information to authenticate without asking the shopper for another action. In a challenge flow, the issuer requests an additional step. Depending on the issuer and supported experience, that step may use a one-time code, an issuer app, a biometric method, or another issuer-selected mechanism.
A challenge is not necessarily a sign that the checkout is broken. It is an issuer-controlled authentication interaction. Merchants should make sure the checkout clearly tells shoppers when they are being asked to complete issuer verification, works across the devices they support, and returns the shopper to a clear success or retry state.
Merchants building a broader control plan can use the ecommerce fraud-reduction guide and the fraud prevention and security FAQ as planning resources.
Ask the gateway or payment provider which 3DS service and card-program connections are used, which integration method is supported, and which party handles technical support.
Confirm the supported card programs, countries, currencies, checkout channels, recurring or stored-credential scenarios, and any transaction types that follow a different authentication path.
Document how the integration receives authentication outcomes, what it sends with a later authorization request, and how timeouts, unavailable services, abandoned challenges, and retries appear to staff and shoppers.
Use provider-supplied test cases for frictionless, challenge, failure, cancellation, and mobile checkout paths. Confirm production-readiness steps directly with the selected provider.
Do not infer support from a platform name or a generic feature list. Record the current integration version, payment route, provider confirmation, and testing outcome for the exact checkout being deployed.
Authentication should fit the checkout rather than appear as an unexplained detour. Use concise on-screen instructions, preserve the order context, and provide a safe way to retry or choose another payment method if the flow cannot finish. Test keyboard navigation, screen-reader labels, narrow screens, browser transitions, and the return from an issuer-controlled challenge.
Customer-support staff should be able to distinguish an authentication interruption from an authorization decline or a completed order. They should never ask a shopper to share a one-time code, password, full card number, security code, bank credential, or screenshot containing sensitive payment details.
EMV 3DS is one part of ecommerce payment design. Merchants should also review checkout integration, gateway responsibilities, order confirmation, refund handling, account access, logging, and customer support. The ecommerce and online payments FAQ provides related explanations for those decisions.
The practical next step is to map the current checkout from card entry through authentication, authorization, and order confirmation. Then ask the selected providers which EMV 3DS flow they support and test the exact integration before relying on it in production.
Bring the gateway name, integration method, checkout channels, card markets, and current test results to a payment-provider conversation. Ask for written confirmation of the supported EMV 3DS path and the responsibilities of each participating service.
Discuss ecommerce payment requirements
Share business contact details and a high-level workflow only. Do not send cardholder data, passwords, one-time codes, bank credentials, full account numbers, security codes, or secret API keys.
To learn more about how TSYS can help improve the way your organization accepts payments, markets to new customers, or manages its HR responsibilities, get in touch by calling 585-981-8463 to get started.
CONTACT US
