How the embedded checkout works
The sequence behind the payment field, and why your site never sees a card number.
What customers experience, why liability shift matters, and how version 2 differs from the one you remember.
3D Secure 2.0 is an authentication step that asks the card issuer to confirm the cardholder is who they say they are. The plugin supports it, and for most merchants it is switched on at the bank.
Often nothing at all. The newer protocol passes device and transaction data to the issuer behind the scenes, and if the issuer is satisfied the payment proceeds with no interruption. This is called a frictionless flow and it covers the majority of transactions.
When the issuer wants more assurance, the customer gets a challenge, usually a one-time code by SMS or an approval in their banking app.
On an authenticated transaction, liability for a fraudulent chargeback shifts from you to the card issuer. Without authentication, a disputed transaction is generally your loss.
This matters most if you take a meaningful share of orders from overseas cards, which is common for Caribbean merchants selling to a diaspora or to visitors booking ahead.
If you remember 3D Secure as the clunky static-password page that cost merchants sales, that was version 1. Version 2 was designed specifically to fix that. Most customers now pass without seeing anything.
Trigger a challenge deliberately during sandbox testing so you know what your customers see. A challenge that appears unexpectedly on a live order, with no idea whether it is legitimate, is a support call you can avoid.
Still stuck? Professional and Premium licence holders get priority support, answered from Trinidad and Tobago.
Contact support