Definition
3DS (3D Secure) is an online payment authentication protocol launched by card organizations such as Visa and Mastercard, designed to enhance the security of remote card transactions. The protocol introduces a three-party verification process among the issuing bank, acquiring bank, and cardholder, adding strong authentication methods such as dynamic passwords, biometrics, or SMS verification during the payment process, effectively reducing risks of card fraud and other malicious activities. 3DS 1.0 was launched in 2001, and 3DS 2.0 (EMV 3-D Secure) was released in 2016, supporting features like frictionless authentication, device fingerprinting, and risk-based authentication, significantly improving user experience and transaction approval rates.
Technical Architecture and Process
3DS 2.0 adopts a three-party architecture of "card issuer—directory server—acquirer." When a cardholder initiates a payment, the acquirer requests verification from the directory server, which forwards the request to the card issuer; the card issuer conducts a risk assessment based on device information, transaction history, behavioral data, etc. For high-risk transactions, challenge-based authentication is triggered (such as OTP or biometrics), while low-risk transactions can pass silently. The verification result is returned through the 3DS message channel, based on which the acquirer completes or declines the transaction. This process complies with PSD2 Strong Customer Authentication (SCA) requirements and serves as the compliance basis for online payments in the EU and other regions.
Application in IoT and cross-border scenarios
In IoT scenarios, 3DS combined with IoT SIM cards provides secure payment capabilities for cross-border charging stations, unmanned retail, vending machines, shared devices, etc. When charging station operators deploy devices overseas, they need to support local card network 3DS verification to meet compliance requirements and reduce the risk of chargebacks. SimtoLink international IoT SIM card solutions cover over 200 countries and regions, supporting eSIM, data pool sharing, and multi-country card usage, providing stable cross-border connectivity for charging stations, POS machines, payment terminals, and other devices, and working with the 3DS protocol to achieve secure and compliant remote payment transactions.
Who can shift fraud liability in the authentication request
On an international IoT terminal, 3DS means the cardholder is authenticated before a remote card payment is sent for authorization. The acquirer or payment gateway builds an authentication request from the amount, currency, merchant category, the country where the terminal sits, and whatever device data can be collected, sends it to the card network directory server, and receives the issuer's result. There are two paths. If the issuer judges the risk to be low, it returns a frictionless approval. If it wants further confirmation, it asks for a one-time password, approval in the banking app, or biometrics. That step is the challenge. The authentication result and the electronic-commerce indicator must be copied unchanged into the authorization message that follows. Only then does the acquirer have a basis for discussing a liability shift. 3DS does not protect how the card number is stored in the terminal, and it does not replace tokenization, which is a separate data-protection control.
Enabling it requires several concrete conditions at once. The acquiring agreement must have 3DS open for the card network in question, and the merchant id, merchant category, and terminal must match the real business. The gateway must wait for the authentication result before authorization, rather than charging first and verifying afterward. An unattended EV charging station, vending machine, or shared device usually has no browser and no screen on which a bank page can appear, so it can use only a merchant-initiated transaction, a small-amount exemption after pre-authorization, or a token the cardholder has already mandated, and those arrangements have to be written into the acquiring contract. Before it creates an order, the charging operation platform should know whether that terminal can complete a challenge. Across a border, the country of the cellular egress, the merchant's country of registration, and the cardholder's billing country are often different. Country, currency, and merchant category in the authentication request must be filled for that transaction, not carried over from a domestic test merchant id. If the terminal can offer only an unstable egress address and has no device identifier that can be recognized again, the issuer has less to judge from and will allow fewer frictionless approvals.
After the challenge flow is opened on an unattended terminal
A common mistake is to treat 3DS as "encrypting the payment message." Encryption deals with confidentiality in transit. 3DS deals with whether this transaction passed cardholder authentication that the issuer accepts. Another mistake is to open the challenge flow on a charger that has no way for a person to interact. The cardholder cannot enter a one-time password, the session sits waiting, the charger times out and retries, and the same card is submitted over and over. A third is that authentication has already returned, but the authorization message drops the authentication value and the indicator, so in a later dispute the acquirer cannot produce the verification record from that moment. In the field it is also easy to leave a test directory-server address in the firmware. The overseas terminal then fails to connect, or it connects to the wrong entry point. Payments fail now and then, while cellular registration itself succeeds. Troubleshooting should start with whether the authentication request went out, which transaction status came back, and whether the authorization message carried the result unchanged, before anyone decides to inspect how the SIM attached.
Another set of conditions is often missed. The wait between the directory server and the issuer needs margin for a cross-border round trip. If the charger sets the limit to the one or two seconds used on a local network, the attempt is cancelled locally before authentication returns. Starting authentication again for the same order without a new transaction reference is treated by the directory server as a replay. If a mandated charge does not keep the mandate identifier from the first authentication, every later charge is challenged again. After a payment module or module serial number is replaced, if the device data is not updated with it, the issuer treats a terminal that used to pass in silence as a device it has never seen. None of this is a coverage or tariff problem, and dialing again does not clear it.