3-D Secure on PayPal: A Merchant's Setup Guide
PayPal supports 3-D Secure in two payment flows. Here is how to pick an SCA setting, set the return and cancel URLs, and track liability shift.
You sell online. Some of your card payments need an extra check before the bank lets them through. PayPal can run that check for you, but you have to turn it on the right way. This guide walks through 3-D Secure on PayPal, from the two settings to the URLs your server must send.
What 3-D Secure on PayPal means for your checkout
3-D Secure is a check that asks the cardholder's bank to confirm the person paying is the real customer. When it runs, the buyer may see a prompt from their bank before the sale finishes. If the sale was fraudulent, a later chargeback can land on you, so the check is one way to manage that risk.
PayPal's JavaScript SDK v6 supports Strong Customer Authentication and 3-D Secure in two payment flows. If you want background on the standard itself, read about EMV 3-D Secure first. This page stays on the PayPal side of it.
The two payment flows: one-time payments and vaulted cards
PayPal splits card payments into two flows.
One-time payments process a single transaction with 3DS when required. The buyer enters a card, the check runs if it must, and the sale completes.
Vaulting stores cards for future purchases. The buyer saves the card once, then pays again later without retyping it. PayPal's SDK supports 3DS in both flows.
Choosing between SCA_ALWAYS and SCA_WHEN_REQUIRED
PayPal gives you two settings.
Use SCA_ALWAYS to attempt 3DS for eligible cards and regions. Every payment that can run the check will try to. Use SCA_WHEN_REQUIRED to rely on network or regulatory mandates. The check runs only where a rule says it must.
Neither setting is right for every store. SCA_ALWAYS attempts the check on every eligible card, not only where a rule requires it. If you want the lightest checkout, SCA_WHEN_REQUIRED keeps the extra step out of the way until a rule forces it. Pick one, apply it the same way each time, and watch what happens to your completed sales.
Server-side setup and the return/cancel URLs you must include
Where do you configure 3DS settings? Not in the browser. PayPal's documentation says to define SCA and 3DS settings on your server and supply return and cancel URLs.
Include both the return_url and cancel_url in all 3DS requests. The return URL is where the buyer lands after the bank's check finishes. The cancel URL is where they land if they abandon it.
Other gateways handle 3-D Secure in their own way, covered in 3-D Secure payment gateway.
Tracking liability shift to manage risk
When the bank's check runs and passes, responsibility for a fraudulent sale can move away from you. That movement is liability shift.
PayPal's docs say to track the liability shift in data to manage risk. This is worth doing. Record whether each payment had the check, and whether the shift happened. Over time you learn which of your orders carry the risk and which do not, and you can set your own rules around that. A payment without the shift is not automatically bad. It just means you keep the risk, so weigh it with everything else you know about the order.
The check itself is not a wall. No tool stops all fraud. For how the handshake between your store, PayPal and the bank actually works, see the 3-D Secure protocol.
Currencies, regions, and what 3DS does not do
PayPal supports multiple currencies and countries, but 3DS does not run everywhere. The check depends on the card and the bank behind it.
So do not treat the setting as a fraud filter. It is a check that some payments can use and others cannot. For what having 3-D Secure on means at checkout, see 3-D Secure enabled.
Set it up server-side, send both URLs, pick the SCA setting that fits your buyers, and track the shift. That is the whole job.