WEBVTT
1
00:00:09.960 --> 00:00:10.793
Welcome everyone.
2
00:00:11.400 --> 00:00:14.360
I'm Amandeep and I lead the payments performance team at Stripe.
3
00:00:14.860 --> 00:00:18.640
So if I were to ask a room full of payments experts in 2020,
4
00:00:19.360 --> 00:00:23.440
"What's the first thing that comes to your mind when you think about 3D Secure?"
5
00:00:23.960 --> 00:00:28.740
I'm sure everyone would say, "Friction." Well,
6
00:00:29.240 --> 00:00:31.060
in 2020, they weren't wrong,
7
00:00:32.540 --> 00:00:34.420
but payments evolve fast.
8
00:00:35.260 --> 00:00:39.040
3DS of 2026 is no longer the 3DS of 2020.
9
00:00:39.940 --> 00:00:42.620
Authentication today is much more seamless.
10
00:00:43.700 --> 00:00:48.480
Machine learning now helps us decide in real time when and how to
11
00:00:48.560 --> 00:00:50.240
apply the different 3DS flows,
12
00:00:50.460 --> 00:00:54.300
especially with an option of a challenge pathway and a frictionless pathway.
13
00:00:55.560 --> 00:00:59.700
The protocol has evolved to a lot more frictionless flow types.
14
00:01:00.240 --> 00:01:04.880
We have exemptions pathway that exist in mandated markets where 3DS is a
15
00:01:04.940 --> 00:01:06.020
regulatory requirement,
16
00:01:06.620 --> 00:01:09.860
and we have the data only pathway which is available more globally.
17
00:01:11.120 --> 00:01:15.680
So the protocol has evolved, but the perception has not. Today,
18
00:01:16.000 --> 00:01:20.500
we are here to close that perception gap. So let's start with a quick poll,
19
00:01:20.840 --> 00:01:22.060
maybe a quick show of hands.
20
00:01:23.480 --> 00:01:26.380
Raise your hands if you are using 3D Secure today.
21
00:01:28.480 --> 00:01:32.520
Oh, wow. Keep them raised. There's another question coming.
22
00:01:34.220 --> 00:01:37.280
Wow. We have a lot of people using 3DS. Great. Now,
23
00:01:37.640 --> 00:01:41.460
lower your hands if you're only using it for compliance reasons
24
00:01:42.940 --> 00:01:44.860
or for high-risk transactions only.
25
00:01:48.640 --> 00:01:50.340
Great. Look around you.
26
00:01:53.500 --> 00:01:57.200
There's not many hands raised when I asked the second question. So great.
27
00:01:57.340 --> 00:02:00.640
Thank you. You can all put them down. By end of this session,
28
00:02:00.860 --> 00:02:05.800
we want more of you having your hands raised wanting to try 3D Secure
29
00:02:06.300 --> 00:02:11.100
because 3DS isn't just a compliance checkbox. Used well,
30
00:02:11.640 --> 00:02:15.980
it's one of the most effective and perhaps the most underused revenue levers
31
00:02:16.100 --> 00:02:17.560
available in your payment stack.
32
00:02:19.400 --> 00:02:22.700
So here's how we're going to spend the next 25 minutes. First,
33
00:02:22.760 --> 00:02:24.980
we're going to talk about the 3DS paradox.
34
00:02:25.620 --> 00:02:30.360
Why 3DS hurts conversion in some markets, but helps in other markets.
35
00:02:31.580 --> 00:02:35.260
Second, what 3DS can unlock for you and your business.
36
00:02:36.840 --> 00:02:41.320
Third, we'll talk about how Stripe can help you there. And finally,
37
00:02:41.880 --> 00:02:46.240
your questions. So please scan this QR code and keep them questions coming.
38
00:02:47.940 --> 00:02:52.040
So let's start with the 3DS paradox. In 2024,
39
00:02:52.800 --> 00:02:57.440
we ran an experiment in the United States requesting 3DS on a set of
40
00:02:57.480 --> 00:02:59.120
transactions for select businesses.
41
00:03:00.420 --> 00:03:04.240
Most of these transactions were approved by the issuers frictionlessly,
42
00:03:04.700 --> 00:03:07.900
meaning there was no redirects, no one-time codes,
43
00:03:07.980 --> 00:03:12.880
or anything that a cardholder could see in their checkout experience. Yet,
44
00:03:13.120 --> 00:03:17.520
we saw the conversion rates dropped on those transactions from 87%
45
00:03:18.240 --> 00:03:22.120
to 82%. Five percentage point drop.
46
00:03:23.260 --> 00:03:28.020
Zero friction added. Just a 3DS flag. Well,
47
00:03:28.080 --> 00:03:31.920
if you are a US business looking at this, your reaction would be obvious.
48
00:03:32.560 --> 00:03:34.340
Why would I ever turn this on?
49
00:03:36.640 --> 00:03:41.500
Here's what happened behind the scenes. In markets where 3DS is optional,
50
00:03:41.600 --> 00:03:44.800
such as the United States, the usage is very low.
51
00:03:45.940 --> 00:03:47.740
Because the usage is low,
52
00:03:48.280 --> 00:03:52.480
issuers haven't had to invest much to improve the user experience
53
00:03:53.540 --> 00:03:56.860
in the checkout journey. In the experiment that I was showing you earlier,
54
00:03:57.620 --> 00:04:02.420
one major US bank was processing 100% of the 3DS transactions
55
00:04:02.480 --> 00:04:07.040
frictionlessly. They were not even attempting to challenge the cardholders.
56
00:04:08.920 --> 00:04:11.200
And there's something more counterintuitive here.
57
00:04:12.020 --> 00:04:16.660
When the US issuers see a 3DS request associated to a transaction,
58
00:04:17.300 --> 00:04:19.980
many treat that as a risk signal. Well,
59
00:04:20.180 --> 00:04:24.600
if a merchant is requesting 3DS on this transaction, something must be off.
60
00:04:25.460 --> 00:04:30.280
So they decline at a higher rate, which leads to poor conversion rates overall.
61
00:04:31.480 --> 00:04:33.060
That becomes this vicious cycle.
62
00:04:33.360 --> 00:04:38.100
So the protocol designed to reduce fraud was being used as a
63
00:04:38.200 --> 00:04:42.340
signal of fraud. That is what we are calling as the paradox.
64
00:04:43.840 --> 00:04:48.100
Now, let's look at the markets where 3DS is a mandate. Starting with Japan.
65
00:04:48.280 --> 00:04:52.320
Japan rolled out the 3DS mandate very recently in April 2025.
66
00:04:53.480 --> 00:04:55.760
The result post-mandate have been striking.
67
00:04:56.660 --> 00:05:00.300
So the transactions that started to go through 3D Secure since the mandate
68
00:05:00.320 --> 00:05:04.140
started remained steady on the conversion rates,
69
00:05:04.440 --> 00:05:07.720
which is roughly about 93%. We saw no change in the conversion.
70
00:05:08.780 --> 00:05:12.720
And 60% of these 3DS requests were also going frictionlessly.
71
00:05:13.640 --> 00:05:14.473
And cherry on top,
72
00:05:15.280 --> 00:05:20.040
we saw the dispute rates fell down by more than 50% since the mandate has kicked
73
00:05:20.820 --> 00:05:23.780
in. Another example is United Kingdom,
74
00:05:24.560 --> 00:05:29.000
where strong customer authentication exists since 2020 as part of PSD2
75
00:05:29.280 --> 00:05:32.940
requirements. So in market as mature as United Kingdom,
76
00:05:33.820 --> 00:05:35.900
3DS adoption and penetration is high.
77
00:05:36.980 --> 00:05:40.540
The merchants are not using it selectively, but using it more broadly.
78
00:05:40.920 --> 00:05:42.680
The issuers have invested more in it.
79
00:05:43.020 --> 00:05:46.840
So we see the authentication success rates and the authorization success rates
80
00:05:47.380 --> 00:05:50.840
work together and are proportional to each other. They go hand in hand.
81
00:05:51.800 --> 00:05:54.580
Same protocol, different ecosystem,
82
00:05:55.300 --> 00:05:56.820
better conversion when it's a mandate.
83
00:06:00.340 --> 00:06:02.640
Here's one of the reasons why this might be happening.
84
00:06:03.340 --> 00:06:08.300
So we tried to compare the nonmandated markets and the mandated markets and
85
00:06:08.340 --> 00:06:11.820
saw how issuers are authenticating their cardholders side by side.
86
00:06:12.660 --> 00:06:15.600
Starting with the US, where 3DS is optional,
87
00:06:16.080 --> 00:06:20.800
we see over half of the challenges that are presented to the cardholders are
88
00:06:20.860 --> 00:06:25.780
going by one-time passcodes over SMSs. Mere,
89
00:06:25.790 --> 00:06:28.740
24% of those transactions are going through biometrics flow,
90
00:06:29.260 --> 00:06:33.620
which is a more seamless flow. That number is gradually going up,
91
00:06:33.900 --> 00:06:38.700
especially starting 2025, but still it's pretty low. Now,
92
00:06:39.280 --> 00:06:43.700
you look at the markets such as a French market, where 3DS is a mandate.
93
00:06:43.820 --> 00:06:46.840
It's one of the European markets which comes under the SCA rules,
94
00:06:47.400 --> 00:06:51.800
and it requires almost 100% of their transactions to go via 3DS flows.
95
00:06:53.080 --> 00:06:55.100
The ratio is inverse over there:
96
00:06:55.660 --> 00:06:59.460
80% of the challenges are going through some form of biometrics.
97
00:07:00.100 --> 00:07:05.020
Only 6% use an OTP.
So when every transaction needs
98
00:07:05.060 --> 00:07:09.420
authentication, issuers invest in making the experience more seamless.
99
00:07:10.260 --> 00:07:14.360
When it is optional, nobody optimizes for something they would not use.
100
00:07:16.100 --> 00:07:18.720
Remember this vicious cycle that I had shown you a minute ago?
101
00:07:19.860 --> 00:07:22.760
That hints that the protocol might be broken. No.
102
00:07:23.500 --> 00:07:24.940
The protocol isn't broken.
103
00:07:25.620 --> 00:07:29.720
The ecosystem around it looks different depending upon where your business is
104
00:07:29.980 --> 00:07:31.300
and where your consumers are.
105
00:07:32.100 --> 00:07:36.640
This vicious cycle becomes a virtuous cycle with the mandate.
106
00:07:37.180 --> 00:07:41.700
In regulated markets, mandate accelerated the investments across the board.
107
00:07:42.340 --> 00:07:45.680
Issuers built more seamless flows when it comes to authentication.
108
00:07:46.880 --> 00:07:50.780
Merchants are using it more broadly, and data improves for everybody.
109
00:07:51.400 --> 00:07:53.600
It almost creates a flywheel effect.
110
00:07:54.900 --> 00:07:59.260
So the question is not that whether 3DS works or not.
111
00:07:59.960 --> 00:08:02.680
It clearly does. The question rather is,
112
00:08:02.980 --> 00:08:07.440
how would you make 3DS work for you? And to discuss about that,
113
00:08:07.720 --> 00:08:09.360
I'm going to invite Cip on the stage.
114
00:08:11.640 --> 00:08:14.040
All right. Hi, everyone. I'm Cip.
115
00:08:14.240 --> 00:08:17.920
I'm the product manager for intelligence commerce and I lead Stripe's
116
00:08:17.960 --> 00:08:19.000
authentication products.
117
00:08:20.160 --> 00:08:25.120
Let's explore how 3DS can actually drive your payment
118
00:08:25.320 --> 00:08:28.520
performance goals. And we're going to cover how we can prevent fraud,
119
00:08:29.080 --> 00:08:32.560
reduce our transaction costs, and even boost conversion.
120
00:08:34.080 --> 00:08:38.520
Let's start with the most common goal, and that is of preventing fraud.
121
00:08:39.080 --> 00:08:40.600
To make matters concrete,
122
00:08:40.760 --> 00:08:44.920
let's put ourselves in the shoes of a company that sells adult light-up
123
00:08:45.000 --> 00:08:48.600
sneakers. Mark my words. These are having a comeback.
124
00:08:48.880 --> 00:08:51.120
Give it until fall and you'll see everyone wearing them.
125
00:08:52.840 --> 00:08:57.400
You sell the sneakers for $100 on your ecommerce website in the US and
126
00:08:57.520 --> 00:09:00.560
Europe. So fraud.
127
00:09:01.400 --> 00:09:04.520
Authentication is the strongest tool we have against fraud,
128
00:09:04.720 --> 00:09:06.760
short of outright blocking that transaction.
129
00:09:07.320 --> 00:09:10.880
This is because we're verifying the cardholder's identity during the purchase,
130
00:09:11.280 --> 00:09:12.280
but there's a trade-off.
131
00:09:13.640 --> 00:09:17.080
Verifying adds friction and friction costs sales.
132
00:09:19.600 --> 00:09:23.680
Let's imagine a customer in the US order's a pair of sneakers for $100.
133
00:09:24.480 --> 00:09:28.760
It's the first time you see this card and you're getting some suspicious
134
00:09:28.760 --> 00:09:32.480
signals, such as a mismatched CVC. What do you do?
135
00:09:34.540 --> 00:09:37.260
Do you add 3DS and verify the identity,
136
00:09:37.440 --> 00:09:40.080
but risk losing that sale due to the friction? Or
137
00:09:41.680 --> 00:09:44.440
do you skip 3DS? Take on any fraud risk,
138
00:09:44.600 --> 00:09:47.380
but you ensure the transaction is successful.
139
00:09:48.020 --> 00:09:51.880
And how do you even know if the issuer will handle 3DS well or not?
140
00:09:52.160 --> 00:09:54.120
As we've just seen, this can vary quite a lot.
141
00:09:55.200 --> 00:09:59.820
That's where Adaptive 3DS comes in. This lives inside Radar,
142
00:09:59.920 --> 00:10:04.300
and it's a new feature that calculates a risk score for every
143
00:10:04.320 --> 00:10:09.120
transaction and is also trained on past issuer behavior and is
144
00:10:09.180 --> 00:10:13.460
able to model exactly how well that issuer will handle 3DS for that type of
145
00:10:13.520 --> 00:10:17.700
transaction. If you have an issuer that doesn't handle 3D as well,
146
00:10:18.200 --> 00:10:21.960
it's more likely to go straight to authorization.
If on the other hand,
147
00:10:22.020 --> 00:10:24.460
you have an issuer that does handle 3DS well,
148
00:10:24.740 --> 00:10:28.600
and that transaction is looking to be towards the higher-risk spectrum,
149
00:10:29.260 --> 00:10:31.940
then you will actually authenticate that transaction.
150
00:10:33.600 --> 00:10:36.080
This means you get a protection only where it matters.
151
00:10:36.540 --> 00:10:39.580
And for merchants that have been using Adaptive 3DS,
152
00:10:40.180 --> 00:10:45.160
we've measured fraud reduction with no loss in conversion at all.
153
00:10:46.240 --> 00:10:48.860
And the best part? There's no integration work required.
154
00:10:49.340 --> 00:10:54.180
It's just a toggle in your Radar dashboard. Next,
155
00:10:54.240 --> 00:10:58.440
let's talk about cost reduction, and here we're referring to interchange costs.
156
00:10:59.720 --> 00:11:03.620
Networks are incentivizing authentication on both sides of the Atlantic.
157
00:11:04.420 --> 00:11:05.253
In Europe,
158
00:11:05.300 --> 00:11:09.540
we've got Visa and Mastercard that charge extra for nonauthenticated
159
00:11:09.560 --> 00:11:10.393
transactions.
160
00:11:10.940 --> 00:11:14.920
Visa hiked this fee up to 7.5 basis points last October,
161
00:11:15.680 --> 00:11:20.280
and MasterC\card will be doing the same this October. Over in the US,
162
00:11:20.760 --> 00:11:25.420
we've got Visa that last week launched DCAP or the
163
00:11:25.560 --> 00:11:27.340
Digital Commerce Authentication Program.
164
00:11:28.080 --> 00:11:33.020
This gives you a five basis points saving on your interchange
165
00:11:33.060 --> 00:11:33.893
costs.
166
00:11:35.680 --> 00:11:39.500
So a few cents here and a few cents there for every pair of sneakers that you
167
00:11:39.580 --> 00:11:41.460
sell, but at the scale that you're running,
168
00:11:41.520 --> 00:11:45.120
this can add up to make a real difference to your bottom line. However,
169
00:11:45.380 --> 00:11:50.280
how do you know if these cost incentives are actually worth the authentication
170
00:11:50.360 --> 00:11:51.980
friction that you're adding in the checkout flow?
171
00:11:53.200 --> 00:11:58.040
Is there a way to get a cost incentive and not add any friction?
In fact,
172
00:11:58.100 --> 00:11:59.760
there is, and it's called "Data Only."
173
00:12:02.100 --> 00:12:06.720
This means we're sharing enriched data with the issuer over 3DS rails,
174
00:12:07.320 --> 00:12:11.760
such as postcode, IP address, phone number, and so on.
175
00:12:12.440 --> 00:12:16.760
And what's different than a regular 3DS flow is that the issuer can't actually
176
00:12:17.140 --> 00:12:20.360
trigger a challenge on that flow. So there's no friction,
177
00:12:20.780 --> 00:12:24.980
but you still satisfy the network requirements and get that cost incentive.
178
00:12:26.800 --> 00:12:28.000
Now, this sounds like a free lunch.
179
00:12:28.180 --> 00:12:32.180
Should you just apply this on all of your transactions? No, there's a catch.
180
00:12:34.060 --> 00:12:37.060
When applied indiscriminately to all transactions,
181
00:12:37.460 --> 00:12:42.220
this year we've measured 17 basis points of conversion degradation in the
182
00:12:42.320 --> 00:12:43.153
US.
183
00:12:44.380 --> 00:12:48.620
So we're going to show you how Stripe works around that in a moment. But before,
184
00:12:48.960 --> 00:12:53.180
let's cover the third and the more surprising goal that 3DS can help drive that
185
00:12:53.200 --> 00:12:55.460
of actually boosting your conversion.
186
00:12:57.760 --> 00:13:02.600
Did you know that one in five completed checkouts gets declined by the
187
00:13:02.720 --> 00:13:06.500
issuer on the first try? One in five.
188
00:13:07.280 --> 00:13:12.060
And what's worst is that most of those are actually legitimate transactions,
189
00:13:12.320 --> 00:13:17.000
but the issuer simply did not have enough information to have the confidence to
190
00:13:17.040 --> 00:13:17.873
approve that.
191
00:13:20.500 --> 00:13:22.440
That's where Authorization Boost comes in.
192
00:13:22.880 --> 00:13:27.740
This is Stripe's auth optimization product that has something we
193
00:13:27.800 --> 00:13:32.500
call "3DS retries." What it will do is it will take these decline transactions,
194
00:13:33.280 --> 00:13:37.060
perform 3DS on them, and then resubmit them to the issuer.
195
00:13:37.880 --> 00:13:42.100
But this time with an added layer of data and security.
196
00:13:42.980 --> 00:13:44.790
On transactions we've done this in the US,
197
00:13:44.900 --> 00:13:49.840
we've measured 90 basis points of conversion uplift. That's almost 1%
198
00:13:51.350 --> 00:13:54.930
more of your orders that otherwise would have never shipped.
199
00:13:56.050 --> 00:13:58.990
And remember Data Only from earlier? That gave us the cost savings.
200
00:13:59.800 --> 00:14:04.570
It can also boost conversion because we're sharing enriched data signals with
201
00:14:04.590 --> 00:14:09.450
the issuers and this gets them approving at higher rates.
This works very
202
00:14:09.490 --> 00:14:10.323
well in Europe.
203
00:14:10.450 --> 00:14:15.230
We've seen 3.2% uplift on conversion
204
00:14:15.590 --> 00:14:20.170
on transactions where we share Data Only signals with the issuers versus
205
00:14:20.210 --> 00:14:24.270
transactions where we don't. So those are transactions over €250.
206
00:14:24.510 --> 00:14:27.890
That's your highest-value orders converting at higher rates.
207
00:14:30.690 --> 00:14:35.330
Let's recap what we've seen just now. We've seen how 3DS can prevent fraud,
208
00:14:36.630 --> 00:14:41.470
lower our network costs, and even help increase our conversion.
209
00:14:42.850 --> 00:14:45.150
But as a sneaker company,
210
00:14:46.130 --> 00:14:50.170
your job is to create the coolest sneakers this decade has ever seen.
211
00:14:50.870 --> 00:14:54.230
So you shouldn't have to get into the weeds of 3DS if you don't want to.
212
00:14:55.790 --> 00:14:58.610
Let's show you how Stripe helps get you there.
213
00:15:00.710 --> 00:15:03.130
Let me introduce to you the authentication engine.
214
00:15:04.110 --> 00:15:07.230
This abstracts all the complexity away for you.
215
00:15:08.090 --> 00:15:12.710
What it does is takes in hundreds of data points to understand the context of a
216
00:15:12.770 --> 00:15:16.030
transaction, then enables you to be compliant.
217
00:15:16.850 --> 00:15:19.230
That's table stakes. But after that,
218
00:15:19.570 --> 00:15:24.130
its AI inference model models the optimal path between
219
00:15:24.380 --> 00:15:27.010
20 different types of flows that it can take.
220
00:15:27.330 --> 00:15:31.050
You've got various types of 3DS flows, various types of Data Only,
221
00:15:31.610 --> 00:15:36.550
and different types going directly to authorization.
And that's really
222
00:15:36.610 --> 00:15:41.210
key here, that 3DS is not just on or off. Rather,
223
00:15:41.850 --> 00:15:46.470
think of it as a dial with many more options than most people realize.
224
00:15:47.310 --> 00:15:51.690
The engine will pick the optimal path out of this 20 for that specific issuer,
225
00:15:51.810 --> 00:15:56.510
for that specific transaction, and balance across cost, conversion,
226
00:15:56.630 --> 00:15:57.910
and fraud altogether.
227
00:15:59.050 --> 00:16:02.970
How does it actually balance across all of those and make that optimal decision?
228
00:16:03.610 --> 00:16:04.690
Let's go one level deeper.
229
00:16:06.990 --> 00:16:11.330
On a $100 order where you have a 20% margin,
230
00:16:11.790 --> 00:16:15.630
what the model will do is it will actually calculate the probability of
231
00:16:15.710 --> 00:16:19.510
conversion, any network costs and incentives,
232
00:16:20.110 --> 00:16:22.830
probability of fraud, and many other factors,
233
00:16:23.230 --> 00:16:28.050
putting them all together to come up with a expected net profit for
234
00:16:28.290 --> 00:16:30.290
each one of the 20 different paths.
235
00:16:30.650 --> 00:16:33.450
And then it will pick the one that has the highest profit.
236
00:16:36.470 --> 00:16:40.790
What's also really cool about this is that it's continuously self-learning.
237
00:16:41.210 --> 00:16:46.070
It's testing new paths, discovering better outcomes, and scaling what works.
238
00:16:47.110 --> 00:16:48.630
If you're using Authorization Boost,
239
00:16:49.090 --> 00:16:52.270
the engine is applied to all of your Stripe payments by default.
240
00:16:53.250 --> 00:16:56.090
But what if you're using other PSPs to process?
241
00:16:57.630 --> 00:16:59.370
That's where standalone 3DS comes in.
242
00:17:00.170 --> 00:17:03.330
This is Stripe's dedicated authentication API.
243
00:17:04.210 --> 00:17:08.790
It allows you to do 3DS on Stripe and process that transaction with any PSP
244
00:17:09.350 --> 00:17:10.183
on your own terms.
245
00:17:11.350 --> 00:17:15.450
You also get much deeper control.
You can set challenge preferences,
246
00:17:15.730 --> 00:17:18.670
control what data to share with the issuer. Actually,
247
00:17:18.730 --> 00:17:22.350
there's more than 30 different parameters that you can tune over the API to get
248
00:17:22.370 --> 00:17:24.110
exactly the 3DS flow that you want.
249
00:17:24.890 --> 00:17:27.290
But if you don't want to mess with 30 different parameters,
250
00:17:28.030 --> 00:17:31.430
you can also tell the API the reason you are doing 3DS,
251
00:17:31.990 --> 00:17:35.930
so fraud prevention, cost reduction, compliance, and so on.
252
00:17:36.490 --> 00:17:40.270
And the engine will actually tune those 30 different parameters for you.
253
00:17:41.370 --> 00:17:45.390
With Standalone 3DS, you can centralize your authentication in one integration,
254
00:17:46.130 --> 00:17:46.963
one dashboard,
255
00:17:47.170 --> 00:17:50.430
and you get all the Stripe intelligence-no matter who you process the payment
256
00:17:50.490 --> 00:17:53.930
with. In terms of how we can actually help get you there.
257
00:17:54.730 --> 00:17:58.650
All the benefits we discussed today are available with three Stripe products.
258
00:17:59.490 --> 00:18:03.430
You've got Radar for fraud prevention with Adapted 3DS.
259
00:18:04.270 --> 00:18:09.070
You've got Auth Boost for conversion and cost savings with Data Only
260
00:18:10.070 --> 00:18:14.690
and 3DS retries, and then Standalone 3DS if you're using multiple PSPs.
261
00:18:16.990 --> 00:18:20.830
We started this session by asking how many of you use 3DS and why.
262
00:18:21.730 --> 00:18:23.050
And here's what we hope has changed.
263
00:18:23.950 --> 00:18:28.750
3DS isn't just compliance or just friction. When used well,
264
00:18:28.930 --> 00:18:32.850
it can fight fraud, lower costs, or improve conversion,
265
00:18:33.190 --> 00:18:34.570
or even all three at the same time.
266
00:18:35.050 --> 00:18:39.630
And today the tools are available to get 3DS working for you. The question is,
267
00:18:40.730 --> 00:18:43.130
are you using them? Thank you.
268
00:18:47.310 --> 00:18:48.970
All right. Let's go to the Q&A.
269
00:18:52.090 --> 00:18:55.690
Cool. I'm seeing some submissions coming. Okay.
270
00:18:57.770 --> 00:18:58.130
Well,
271
00:18:58.130 --> 00:19:03.110
there is a theme of questions that are centric around agentic commerce and
272
00:19:03.130 --> 00:19:07.610
authentication. So how do you see authentication evolving with agentic commerce?
273
00:19:08.110 --> 00:19:12.750
It's a good question and also a very hot topic right now. Well,
274
00:19:13.310 --> 00:19:17.270
if you look at 3D Secure in particular, the framework of 3D Secure,
275
00:19:17.610 --> 00:19:20.050
especially for cardholder-initiated transactions,
276
00:19:20.670 --> 00:19:25.410
is built on one key assumption that the cardholder is part of the journey.
277
00:19:25.970 --> 00:19:29.130
So you are authenticating the human actually doing that transaction.
278
00:19:30.050 --> 00:19:34.750
Agentic definitely challenges that assumption because the agents can act on your
279
00:19:34.810 --> 00:19:38.670
behalf and make a purchase when you are not in the checkout journey.
280
00:19:39.830 --> 00:19:42.050
So we see that with the gentech commerce,
281
00:19:42.290 --> 00:19:44.710
there is going to be an evolution in how you authenticate.
282
00:19:45.470 --> 00:19:48.110
Especially for 3D Secure and EMV 3DS,
283
00:19:48.230 --> 00:19:50.590
the protocol that governs the rules around it,
284
00:19:51.370 --> 00:19:55.470
there does exist decoupled authentication and it exists for many years.
But I
285
00:19:55.510 --> 00:19:59.530
think with agentic commerce, it will find its mainstream use case.
286
00:19:59.590 --> 00:20:03.730
So that's one of the options which we can see evolve over time with agentic
287
00:20:03.770 --> 00:20:07.350
commerce taking the mainstream. That's one of the things. And also,
288
00:20:07.530 --> 00:20:08.810
if you look at the card schemes,
289
00:20:09.730 --> 00:20:13.490
most card schemes are building their programs right now purely for
290
00:20:13.530 --> 00:20:18.030
authentication in agentic commerce space with passkeys as their baseline.
291
00:20:18.370 --> 00:20:23.270
So they are the two options which we think could evolve and become new modes
292
00:20:23.450 --> 00:20:27.690
of how you authenticate with an agent around you. Okay.
293
00:20:29.110 --> 00:20:31.230
Another question is... Okay.
294
00:20:31.630 --> 00:20:32.463
I can take that one.
295
00:20:33.150 --> 00:20:35.930
Isn't 3DS outdated? Will it be relevant in 10 years?
296
00:20:37.310 --> 00:20:41.190
So yeah, that's a fun one. I don't think it will be outdated.
297
00:20:41.390 --> 00:20:44.390
And I'm not just saying that because I'm the product manager for 3DS.
298
00:20:47.530 --> 00:20:48.950
I think 3DS is here to stay.
299
00:20:49.710 --> 00:20:54.550
And the reason for that is that the governance structure that
300
00:20:54.590 --> 00:20:58.030
exists around it is extremely evolved.
301
00:20:58.190 --> 00:21:01.050
We've got dispute resolution, liability shift,
302
00:21:01.630 --> 00:21:04.850
near universal adoption by networks,
303
00:21:04.950 --> 00:21:07.470
regulators and issuers almost globally.
304
00:21:07.990 --> 00:21:12.330
And that's something that's very hard to unwind and it's also very hard to
305
00:21:12.890 --> 00:21:16.290
build up in an alternative system. But having said that,
306
00:21:16.650 --> 00:21:18.250
I'm not saying that 3DS will not change.
307
00:21:18.510 --> 00:21:21.530
We've got upcoming protocol versions and Aman,
308
00:21:21.590 --> 00:21:24.650
you just mentioned passkeys for agentic commerce.
309
00:21:25.570 --> 00:21:29.070
Authentication methods keep evolving and the data keeps getting better.
310
00:21:29.450 --> 00:21:30.630
So what we're going to see is,
311
00:21:31.190 --> 00:21:34.170
I think we're going to see an evolution of better authentication methods,
312
00:21:34.570 --> 00:21:38.850
but these will be actually built on top of the 3DS rails rather than
313
00:21:39.330 --> 00:21:41.810
necessarily replace those rails.
314
00:21:41.990 --> 00:21:46.770
So it's an area that I think is of continued excitement and worth
315
00:21:46.810 --> 00:21:49.070
investing in. And yeah, we're certainly doing that.
316
00:21:49.870 --> 00:21:50.430
Cool.
317
00:21:50.430 --> 00:21:54.710
I have another question related to the data we were showing in the first half
318
00:21:54.870 --> 00:21:57.310
that where do you see the paradox shifting?
319
00:21:57.790 --> 00:22:02.610
Will the United States catch up with the regulated markets? Good question again.
320
00:22:03.850 --> 00:22:05.270
So if we look at United States,
321
00:22:05.330 --> 00:22:08.370
the usage of 3DS is pretty low right now as we were talking about.
322
00:22:09.090 --> 00:22:11.200
But we are seeing, especially starting of 2025,
323
00:22:12.230 --> 00:22:16.030
that the uptick in usage of 3DS directly by merchants have gone up.
324
00:22:17.410 --> 00:22:21.010
There's also a signal that you can see from Visa's new program,
325
00:22:21.230 --> 00:22:23.230
DCAP that Cip was talking about.
326
00:22:23.970 --> 00:22:28.110
I think this is the first time any scheme has come up with a program that
327
00:22:28.610 --> 00:22:31.770
incentivizes merchants for using 3D Secure.
328
00:22:32.210 --> 00:22:36.770
Because the main thing that 3D Secure brings in the table when it comes to the
329
00:22:36.830 --> 00:22:41.250
data pipe is like it is data rich in comparison to the authorization message
330
00:22:41.270 --> 00:22:43.750
rails.
So if you're giving more data,
331
00:22:44.530 --> 00:22:48.790
you will be incentivized by lowering network costs now by Visa.
332
00:22:49.330 --> 00:22:52.050
And I think other schemes might follow the same suit.
333
00:22:52.750 --> 00:22:56.730
So I think with that and economic incentives coming in play,
334
00:22:57.450 --> 00:23:01.410
there will be an uptake in the usage of 3DS when it comes to United States.
335
00:23:02.850 --> 00:23:05.530
Whether US will become a regulated market or not,
336
00:23:06.290 --> 00:23:11.050
I think my near-term answer would be probably not. Even now,
337
00:23:11.230 --> 00:23:16.070
I think merchants as well as the whole ecosystem in the US wants to stay
338
00:23:16.210 --> 00:23:20.070
away from 3DS as much possible, but these incentives might change things.
339
00:23:21.110 --> 00:23:24.710
I showed you a slide around how issuers are authenticating cardholders.
340
00:23:25.350 --> 00:23:29.410
We are seeing like many issuers now in the United States are investing in
341
00:23:29.470 --> 00:23:30.890
biometrics-based authentication.
342
00:23:31.510 --> 00:23:36.350
I think that will also change the game because ultimately you as a merchant
343
00:23:36.570 --> 00:23:38.950
do not want that your cardholders,
344
00:23:39.390 --> 00:23:43.070
which have acquired spending millions making your checkout experience the best
345
00:23:43.470 --> 00:23:46.910
to go through some form of a friction that you lose that transaction.
And
346
00:23:46.970 --> 00:23:47.803
biometrics,
347
00:23:47.830 --> 00:23:52.410
especially in-app or app-to-app redirects have become so seamless now.
348
00:23:53.010 --> 00:23:55.590
If issuers are going to invest in that, your cardholders,
349
00:23:55.650 --> 00:23:59.710
your consumers are not going to even feel the difference when they're making a
350
00:23:59.770 --> 00:24:03.530
purchase and they only have to do a face ID or biometrics as part of it.
351
00:24:03.870 --> 00:24:08.510
We see more issuers actually adopting that, and that uptick will also,
352
00:24:09.230 --> 00:24:09.650
in my way,
353
00:24:09.650 --> 00:24:14.570
is also a signal that usage of 3DS will go up and the experience will get
354
00:24:14.630 --> 00:24:17.490
better at it. So if we have a-.
355
00:24:17.890 --> 00:24:21.070
Yeah, a couple on DCAP, so I can combine these. So the first one is,
356
00:24:21.690 --> 00:24:24.970
"What do I need to qualify for DCAP? How does it work?" And the next one is,
357
00:24:24.970 --> 00:24:29.550
"Why would you use Visa DCAP if it doesn't provide liability shift?" So this is
358
00:24:29.690 --> 00:24:33.430
a program that's just launched last week in the US from Visa.
359
00:24:33.490 --> 00:24:37.330
It's the first of its kind to incentivize higher authentication and data sharing
360
00:24:37.370 --> 00:24:42.190
over 3DS. In order to qualify, you have to send specific data points,
361
00:24:42.250 --> 00:24:46.450
so billing address, email address, IP address over the 3DS rails,
362
00:24:46.910 --> 00:24:50.410
and then Visa will actually give you this five basis points interchange saving
363
00:24:51.030 --> 00:24:54.270
on eligible transactions. So there's a few requirements-for example,
364
00:24:54.770 --> 00:24:58.410
not Apple Pay or Google Pay authenticated or MITs,
365
00:24:59.630 --> 00:25:03.210
but we do see actually a lot of merchants have been taking a lot of advantage of
366
00:25:03.250 --> 00:25:07.530
this because it can actually really make a difference at large scale.
367
00:25:08.310 --> 00:25:10.070
Why use it if there's no liability shift?
368
00:25:11.530 --> 00:25:16.490
So that's why actually Visa is adding this incentive in the
369
00:25:16.570 --> 00:25:21.250
US specifically because 3DS adoption is lower than in other
370
00:25:21.350 --> 00:25:23.110
markets, as we've just discussed.
371
00:25:24.350 --> 00:25:26.510
So they actually launch DCAP globally,
372
00:25:26.670 --> 00:25:30.430
but it's only in the US and it will be in Canada as well where there's a cost
373
00:25:30.490 --> 00:25:33.090
incentive. Because these are the markets that need the most help.
374
00:25:34.710 --> 00:25:39.350
Even without the cost incentives-so, for example, we are doing Data Only flows,
375
00:25:39.470 --> 00:25:44.150
which is this type of flow that qualifies in all markets that we operate in and
376
00:25:44.750 --> 00:25:46.490
there's no cost incentive, but it's still,
377
00:25:46.710 --> 00:25:50.330
the authentication engine is still picking this as a pathway because it does
378
00:25:50.390 --> 00:25:54.730
provide a conversion uplift given we are sharing this data with the issuers and
379
00:25:55.010 --> 00:25:57.810
gives them that confidence to approve, like I was discussing earlier.
380
00:25:58.950 --> 00:26:02.890
So in an ideal world, you'd be incentivized to do Data Only,
381
00:26:03.410 --> 00:26:05.770
share data with the issuers without the cost incentive,
382
00:26:05.890 --> 00:26:08.290
but for now-for the next couple of years,
383
00:26:08.350 --> 00:26:13.190
hopefully Visa will have this in place to get us to that state of
384
00:26:13.310 --> 00:26:18.290
higher 3DS adoption in the US and better data sharing and a safer
385
00:26:18.330 --> 00:26:22.730
ecosystem for all. So it shouldn't be just for liability shift that to do 3DS,
386
00:26:22.850 --> 00:26:26.610
it's about getting that safer ecosystem for everyone involved and for the
387
00:26:26.670 --> 00:26:27.810
transaction as a whole.
388
00:26:28.590 --> 00:26:29.570
The authentication engine,
389
00:26:29.650 --> 00:26:32.430
how can I override the logic of the authentication engine?
390
00:26:33.070 --> 00:26:33.450
Yep.
391
00:26:33.450 --> 00:26:37.990
So the authentication engine does abstract the complexity away for you if you
392
00:26:38.030 --> 00:26:38.770
want that,
393
00:26:38.770 --> 00:26:42.510
but you still have different access points to actually control it yourself and
394
00:26:42.750 --> 00:26:43.583
tune it.
395
00:26:45.290 --> 00:26:48.950
The simplest way is always to just request 3DS via the Stripe Payments API,
396
00:26:49.550 --> 00:26:53.030
but then, for example, Adaptive 3DS, as part of Radar,
397
00:26:53.430 --> 00:26:58.190
you can actually tune a risk preference depending on more or less risk averse
398
00:26:58.210 --> 00:27:01.170
that you are. So be more or less aggressive with your 3DS.
399
00:27:01.930 --> 00:27:05.990
And you've also got Radar for Fraud Teams where you can kind of set your custom
400
00:27:06.070 --> 00:27:07.430
rules-for example,
401
00:27:08.410 --> 00:27:12.910
"Trigger 3DS for every transactions over $50 coming from
402
00:27:13.630 --> 00:27:15.450
crossborder," or something like that.
403
00:27:16.930 --> 00:27:19.650
And there's of course Standalone 3DS as well where you've got a multitude of
404
00:27:19.690 --> 00:27:24.650
parameters where you can kind of tune more what you want rather than treat it
405
00:27:24.710 --> 00:27:27.570
as a kind of black box, do all the magic for me.
406
00:27:29.310 --> 00:27:31.810
Brilliant. I think there were a few more questions,
407
00:27:31.890 --> 00:27:33.350
but we are running short of time.
408
00:27:33.450 --> 00:27:36.830
So thank you everybody for coming and attending this session.