How 3D Secure Works With UniLink Payments (Reduce Fraud and Liability Shift)

Understand how 3D Secure authentication protects your UniLink store from fraudulent chargebacks — and how to balance security with conversion rate.

If you have ever bought something online and been prompted to enter a one-time code from your bank before the payment went through, you have experienced 3D Secure. For sellers on UniLink, 3DS is not a configuration you toggle manually — Stripe handles it automatically behind the scenes. But understanding how it works, when it triggers, and what the liability shift means for your chargeback exposure will help you make smarter decisions about your payment settings and fraud strategy. This guide explains everything you need to know.

What 3D Secure Does

3D Secure is an authentication protocol developed by the card networks (Visa calls it Visa Secure, Mastercard calls it Identity Check) that adds a verification step between the buyer submitting their card details and the payment being approved. The "3D" refers to the three domains involved: the card network, the issuing bank, and the acquiring bank (Stripe). When 3DS is triggered, the buyer is redirected to their bank's authentication page or receives a push notification in their banking app to approve the payment.

The most important consequence of 3DS for sellers is liability shift. Normally, if a buyer disputes a charge as fraudulent (claiming they did not make the purchase), you as the seller bear the loss. When a 3DS-authenticated payment is disputed on fraud grounds, the liability shifts to the card issuer — not you. The dispute may still be filed, but because the buyer authenticated with their bank, the card issuer is responsible for the loss rather than your Stripe account. This is the primary reason merchants enable 3DS for high-value or high-risk transactions.

Stripe's implementation of 3DS through UniLink uses a version called 3DS2, the modern standard. 3DS2 is significantly less disruptive than the original 3DS. It performs a risk assessment in the background using device fingerprinting, transaction history, and behavioral data. Most low-risk transactions complete without any visible authentication prompt — the bank approves them silently in a "frictionless flow." Only transactions flagged as higher risk trigger the visible authentication step that the buyer has to complete.

How to Get Started With 3DS in UniLink

1. Verify Stripe is connected to your UniLink store — 3DS is handled at the Stripe level; it is active by default for all Stripe-powered payments. No separate activation is needed in UniLink.
2. Check your Stripe Radar settings — go to dashboard.stripe.com → Radar → Rules. Here you can see and configure when Stripe requests 3DS. The default rules request 3DS for transactions Stripe's risk model flags as elevated risk.
3. Review the default 3DS rule — Stripe's default Radar rule is "Request 3DS for card present transactions that Stripe evaluates as high risk." You can also add custom rules, such as "Request 3DS for transactions over $100."
4. Confirm SCA compliance settings for European buyers — if you sell to buyers in the European Economic Area (EEA), Strong Customer Authentication (SCA) regulations require 3DS for most card payments. Stripe automatically applies 3DS for EEA transactions.
5. Test 3DS in Stripe test mode — use Stripe's test cards that simulate 3DS challenges (card number 4000 0027 6000 3184 in test mode triggers a 3DS challenge). Confirm the checkout flow in UniLink handles the 3DS redirect and returns correctly after authentication.
6. Monitor authentication rates in Stripe Radar — after going live, check your Stripe Radar overview for 3DS authentication rates, challenge rates, and failure rates. High failure rates indicate your buyers are abandoning at the 3DS step.
7. Adjust Radar rules based on data — if 3DS is triggering too frequently on low-risk transactions and hurting conversion, tighten the Radar rule threshold. If you are seeing fraud disputes on lower-value transactions, consider lowering the 3DS threshold.

How to Use Liability Shift to Your Advantage

1. Identify your highest-value products — liability shift is most valuable where your exposure is highest. If you sell products priced above $50–100, configuring 3DS to trigger consistently for those amounts protects your largest revenue transactions.
2. Add a Radar rule for high-value transactions — in Stripe Radar → Rules, add: "Request 3DS if :amount_in_usd: > 75" (adjust the threshold to match your product pricing). This ensures high-value purchases always get the liability shift benefit.
3. Target high-risk geographies — if your analytics show elevated fraud rates from specific countries, add a Radar rule to require 3DS for transactions from those regions. Stripe lets you filter by IP country.
4. Review dispute history for 3DS patterns — in Stripe, check whether disputed transactions were 3DS-authenticated. If you are losing disputes on non-authenticated transactions, it is a signal to lower your 3DS trigger threshold.
5. Communicate the authentication step to buyers — add a note in your checkout confirmation page (or the product page) that buyers may be asked to verify their payment with their bank. Unprepared buyers sometimes abandon at the 3DS prompt thinking it is suspicious.

Key Settings Explained

How to Get the Most Out of 3D Secure

The frictionless flow is 3DS2's biggest advantage over the original 3DS standard. In the old system (3DS1), nearly every transaction triggered a visible redirect and password prompt. Conversion rates suffered significantly — studies showed 3DS1 increased cart abandonment by 10–20%. With 3DS2, the vast majority of low-risk transactions (typically 85–95% in practice) complete without any visible challenge. Your buyers authenticate seamlessly and you still get the liability shift benefit. The key to maximizing this is making sure your Stripe integration sends the right device and session data with each payment request, which UniLink handles automatically when you use the standard Stripe Elements checkout.

SCA compliance is non-negotiable for European markets. The EU's Revised Payment Services Directive (PSD2) requires Strong Customer Authentication for most card-not-present payments involving EEA buyers. Stripe handles this automatically, but understanding that it is a legal requirement — not just a technical option — helps you set expectations with EU customers. If an EU buyer's bank rejects a frictionless flow and requires a challenge, that is the bank complying with regulation, and there is no way to bypass it legitimately.

Use your dispute history data to calibrate 3DS settings. If you are seeing a pattern of fraud disputes on transactions under $50 from a specific card type or region, that is a data-driven signal to lower your 3DS trigger threshold for those parameters. Conversely, if you are seeing no fraud disputes on low-value domestic transactions and your conversion on those is healthy, there is no reason to add 3DS friction. Let the data drive your Radar rules rather than applying blanket policies.

Remember that liability shift applies to fraud disputes only — not to "product not received" or "product not as described" disputes. A buyer who authentically purchased your product and then disputes it as "not as described" is not covered by 3DS liability shift. For those dispute types, strong product descriptions, clear refund policies, and delivery logs are still your primary defence. 3DS is specifically a fraud tool, not a general dispute prevention mechanism.

Troubleshooting Common Issues