WEBVTT
1
00:00:10.020 --> 00:00:13.900
Hi everyone. I feel like this is the hardest part, is getting on the stools.
2
00:00:15.980 --> 00:00:20.540
But yeah, please no accidents. We're far from the ground. Hi,
3
00:00:20.560 --> 00:00:25.380
everyone. How's everyone's Sessions going? Good. Okay. Amazing.
4
00:00:25.440 --> 00:00:27.080
Wow. Packed room over here.
5
00:00:28.260 --> 00:00:30.840
Thank you for spending your time with us today.
6
00:00:31.060 --> 00:00:34.400
I know it is lunchtime and we really appreciate you all for coming out.
7
00:00:34.680 --> 00:00:38.440
And we have a really, really great panel in store. But hi everyone.
8
00:00:38.600 --> 00:00:39.433
My name is Jen Lee.
9
00:00:39.920 --> 00:00:43.420
I'm one of the product leads for our agentic commerce team here at Stripe.
10
00:00:44.080 --> 00:00:48.360
And today we have a great group of leaders here to chat with you all about
11
00:00:48.420 --> 00:00:51.700
agentic commerce. We have Pablo Fourez,
12
00:00:51.880 --> 00:00:56.880
who is the chief digital officer at Mastercard. And also from Mastercard,
13
00:00:57.000 --> 00:00:58.360
let's welcome Sherri Haymond,
14
00:00:58.500 --> 00:01:02.640
who is the executive vice president of global digital commercialization.
15
00:01:03.680 --> 00:01:05.540
And finally, we have Devang Kothari,
16
00:01:05.760 --> 00:01:08.580
who is the chief technical officer at Wizard AI.
17
00:01:14.800 --> 00:01:15.600
All right.
18
00:01:15.600 --> 00:01:20.160
So a little preamble for me before we get into the frameworks and trust
19
00:01:20.200 --> 00:01:22.200
infrastructure that we're going to be talking about today.
20
00:01:22.900 --> 00:01:27.380
I actually want to ground this conversation in something new and concrete
21
00:01:28.120 --> 00:01:30.840
because earlier today, Mastercard, Stripe,
22
00:01:31.000 --> 00:01:35.100
and Wizard announced new work focused on enabling trusted
23
00:01:35.300 --> 00:01:36.980
agent-initiated payment flows.
24
00:01:37.560 --> 00:01:40.060
These payments are enabled by shared payment tokens,
25
00:01:40.380 --> 00:01:43.540
which work natively with Mastercard's Agent Pay tokens.
26
00:01:44.080 --> 00:01:47.060
And this is what makes today's conversation actually quite timely.
27
00:01:49.400 --> 00:01:50.480
So to kick things off,
28
00:01:50.560 --> 00:01:52.700
I want to start with a quick pulse check from each of you.
29
00:01:53.620 --> 00:01:57.180
When you look at the rise of agentic AI in commerce,
30
00:01:57.320 --> 00:02:01.700
particularly as agents begin to act with delegated authority in real payment
31
00:02:01.760 --> 00:02:03.820
flows, like moving real money around,
32
00:02:04.560 --> 00:02:07.080
what's one shift you're particularly focused on?
33
00:02:07.140 --> 00:02:11.460
And what do you think has changed in the past year that made this feel a little
34
00:02:11.480 --> 00:02:14.760
bit more real rather than something that's purely theoretical?
35
00:02:17.480 --> 00:02:17.840
Start?
36
00:02:17.840 --> 00:02:18.740
Yeah, Pablo, go for it.
37
00:02:20.680 --> 00:02:21.280
I mean,
38
00:02:21.280 --> 00:02:26.200
what we've been listening through the days here is it's real
39
00:02:26.260 --> 00:02:28.380
because it's out there, people are using it.
40
00:02:28.860 --> 00:02:33.500
And so it's actually not just PowerPoint; is actually things that are happening.
41
00:02:33.600 --> 00:02:36.980
And so I think that's a big, well, a change over the last year.
42
00:02:37.700 --> 00:02:40.520
I think another change, I think over, the last year is
43
00:02:42.320 --> 00:02:45.760
we had a lot of protocols over the last year. And
44
00:02:47.580 --> 00:02:51.080
I really see now this thing converging and some of the things that we heard over
45
00:02:51.100 --> 00:02:55.620
the last two days, last two weeks, I think very encouraging seeing,
46
00:02:56.540 --> 00:02:58.840
for example, adoption of UCP.
47
00:03:01.140 --> 00:03:04.560
Earlier this week, we actually, with Google, we contributed,
48
00:03:05.600 --> 00:03:07.540
they contributed AP2 to FIDO.
49
00:03:07.700 --> 00:03:11.660
We contributed verifiable credential-Verifiable Intent-to FIDO to create
50
00:03:11.720 --> 00:03:14.140
standards. So I think as an industry,
51
00:03:14.220 --> 00:03:19.080
we are starting to converge on how to get things done in a practical way
52
00:03:19.920 --> 00:03:22.500
that can scale. And so I think that's a change.
53
00:03:25.180 --> 00:03:29.600
Yeah. So what was the other question? What made it real? I don't know what-.
54
00:03:29.920 --> 00:03:31.120
Yeah. And what do you think has changed...
55
00:03:31.120 --> 00:03:33.400
You mentioned protocols changing the past year. Sherri,
56
00:03:33.480 --> 00:03:35.060
it sounds like you want to chime in there as well.
57
00:03:35.160 --> 00:03:38.500
Yeah. No, just building on what Pablo said. I mean, it's actually happening.
58
00:03:38.560 --> 00:03:41.920
And at Mastercard, we went ahead and kind of early on, we,
59
00:03:42.360 --> 00:03:45.100
and we're going to get into this a little bit later with trust, et cetera, that
60
00:03:48.600 --> 00:03:52.700
we had for many years been working on building a very scaled,
61
00:03:52.760 --> 00:03:56.040
ubiquitous world of tokens, tokenization.
62
00:03:56.100 --> 00:03:59.720
And we actually worked very closely with Stripe for many years to get this off
63
00:03:59.760 --> 00:04:04.200
the ground from mobile commerce to ecommerce, cloud-based commerce, et cetera.
64
00:04:07.260 --> 00:04:10.720
It was obvious to us that we should then do this,
65
00:04:11.380 --> 00:04:15.160
agentic commerce with tokens, like build on that transparent, trusted,
66
00:04:15.820 --> 00:04:19.380
secure infrastructure. So this was obvious to us.
67
00:04:19.440 --> 00:04:22.120
We weren't sure that it was going to be obvious to everybody else.
68
00:04:22.720 --> 00:04:26.220
So we went ahead though and we took the step and we enabled all of our issuers
69
00:04:26.860 --> 00:04:29.620
and we didn't know what was going to happen.
So initially,
70
00:04:31.160 --> 00:04:33.460
we went ahead and we were engaging with partners like you,
71
00:04:33.640 --> 00:04:34.880
you implemented the tokens.
72
00:04:35.640 --> 00:04:40.640
Obviously we're live with a bunch of large LLMs that we talked about that
73
00:04:40.720 --> 00:04:43.180
was talked about on stage yesterday, and now,
74
00:04:43.500 --> 00:04:46.840
with other shopping agents like Wizard, which is super exciting.
75
00:04:48.040 --> 00:04:48.873
But in addition,
76
00:04:49.300 --> 00:04:53.180
what's also so cool is that issuers around the world at Mastercard are so
77
00:04:53.380 --> 00:04:58.200
excited to get testing and get going that there was like demand from
78
00:04:58.720 --> 00:05:02.140
my team to come up with like, "Oh, go find us.
79
00:05:03.480 --> 00:05:06.780
If I'm in the Philippines and I want to start going ahead and testing,
80
00:05:07.160 --> 00:05:10.920
what are we going to do? " So we actually set up, we went out and, for them,
81
00:05:10.980 --> 00:05:15.680
we sourced partners to go ahead and create little
82
00:05:15.720 --> 00:05:20.640
miniecosystems to get it started because there was so much demand for this to
83
00:05:20.700 --> 00:05:24.980
participate in this kind of trusted way of implementing the
84
00:05:25.000 --> 00:05:27.540
technology. So for me, it was just really exciting.
85
00:05:27.800 --> 00:05:31.280
And the big shift was to see that it was just as obvious to the rest of the
86
00:05:31.340 --> 00:05:32.520
universe that it was to us.
87
00:05:33.040 --> 00:05:36.820
Yeah, definitely. And Devang, from the agent side, what have you been seeing?
88
00:05:36.940 --> 00:05:38.240
Yeah. So at Wizard,
89
00:05:38.540 --> 00:05:43.160
we've been building the first AI-native agent purpose-built for ecommerce.
90
00:05:43.220 --> 00:05:46.700
And so we've been thinking about this problem, trying to solve it for years.
91
00:05:47.200 --> 00:05:51.420
Only now with the help of the ecosystem, Mastercard and Stripe,
92
00:05:51.740 --> 00:05:55.300
have we been able to deliver that query to checkout experience,
93
00:05:55.360 --> 00:05:58.320
which we think is essential for agentic commerce.
94
00:05:59.000 --> 00:05:59.833
That's awesome.
95
00:05:59.940 --> 00:06:03.720
I would say in the query to checkout experience-and this is where I want to get
96
00:06:03.780 --> 00:06:05.500
into the meat of what this panel is about.
97
00:06:05.920 --> 00:06:09.320
So AI agents like yours and many, many more,
98
00:06:09.380 --> 00:06:13.620
are starting to act on the behalf of users in actual real commerce flows.
99
00:06:14.200 --> 00:06:17.620
So why does trust become so critical at this moment?
100
00:06:17.920 --> 00:06:22.700
And isn't just making maybe AI smarter the best way to solve it
101
00:06:22.900 --> 00:06:25.680
or, probably not, but let's hear what you all think.
102
00:06:27.200 --> 00:06:31.420
Yeah. I mean, obviously the trust is so important, I would say.
103
00:06:31.760 --> 00:06:36.480
It's important because now you have a new actor that is helping
104
00:06:36.540 --> 00:06:39.540
consumers, it's helping merchants conduct commerce in a different way,
105
00:06:40.420 --> 00:06:42.140
but it poses a lot of questions.
106
00:06:44.120 --> 00:06:48.020
Particularly consumers will say, "Can I trust this?
107
00:06:48.860 --> 00:06:52.440
Are things going to go well? And if they don't go well,
108
00:06:54.280 --> 00:06:55.160
what's going to happen?" Right?
109
00:06:55.840 --> 00:06:58.340
And so that's an element of bringing trust to consumers.
110
00:06:59.540 --> 00:07:01.740
And on the merchant side, likewise, you're saying, "Okay,
111
00:07:01.740 --> 00:07:02.800
I'm shopping through this channel.
112
00:07:03.860 --> 00:07:06.940
How do I know that I can trust this new party?
113
00:07:08.220 --> 00:07:13.180
And how do I know that it has actually the authority to make the purchase
114
00:07:13.220 --> 00:07:17.260
on behalf of the shopper, of the consumer, of the cardholder?
115
00:07:17.320 --> 00:07:20.480
How do I know it's not fraudulent? And then if something goes wrong,
116
00:07:20.940 --> 00:07:24.820
like for some reason, or is it a dispute or whatnot, like,
117
00:07:25.140 --> 00:07:26.920
how is it going to work, and
118
00:07:29.120 --> 00:07:34.120
who will have my back so that I can resolve whatever issues
119
00:07:34.180 --> 00:07:38.320
arise in a fair way and in a quick way?"
And
120
00:07:40.060 --> 00:07:42.920
so I think it's less about-obviously the AI is super smart,
121
00:07:43.000 --> 00:07:44.880
but is the ecosystem that needs to adapt,
122
00:07:45.740 --> 00:07:48.940
to be able to support these new flows in an efficient way.
123
00:07:49.260 --> 00:07:52.920
And so that's what we're working to do is to get...
124
00:07:55.700 --> 00:07:56.620
It's a big change, I think,
125
00:07:57.080 --> 00:08:01.540
for the payment systems to adapt to this new thing so that it does work very
126
00:08:01.640 --> 00:08:02.720
seamlessly and flawlessly.
127
00:08:03.740 --> 00:08:07.860
And a lot of the work that we have been doing over this year is concentrated on
128
00:08:07.880 --> 00:08:10.690
that, getting the base of how it works
129
00:08:12.480 --> 00:08:16.080
that you can trust it basically because it's working fine and it can address not
130
00:08:16.240 --> 00:08:19.600
only when it goes well, but also the edge cases if it doesn't go well, right?
131
00:08:20.400 --> 00:08:21.880
Yeah. I think that makes sense. Actually,
132
00:08:21.960 --> 00:08:23.920
I think when I've been talking to merchants at Stripe,
133
00:08:24.280 --> 00:08:26.880
it's been one of the top questions that I get. I feel like,
134
00:08:27.160 --> 00:08:31.800
I don't know if folks here who are selling things and thinking about how
135
00:08:31.880 --> 00:08:33.080
agents would be purchasing them,
136
00:08:33.440 --> 00:08:35.680
I feel like one of the key things they want to figure out is,
137
00:08:36.120 --> 00:08:40.560
"Is it a good bot or a bad bot coming through?" Sherri or Devang,
138
00:08:40.680 --> 00:08:41.880
did you have a take on this as well?
139
00:08:43.920 --> 00:08:47.080
Yeah. So well, on the good bot, bad bot thing, we're actually
140
00:08:49.080 --> 00:08:53.240
not planned, but we think that's actually a huge...
141
00:08:53.360 --> 00:08:57.040
It's a huge issue, and it's a huge opportunity. And, of course,
142
00:08:58.840 --> 00:09:03.440
we are working with our merchant partners to provide those signals,
143
00:09:03.560 --> 00:09:05.640
as I know you are too. And you talked about that yesterday.
144
00:09:05.840 --> 00:09:10.080
So more of that to come, I think it's actually a really big, important issue.
145
00:09:10.680 --> 00:09:12.120
So Pablo talked a bit about
146
00:09:13.760 --> 00:09:17.720
how the ecosystem is building
147
00:09:18.980 --> 00:09:21.880
trust and why it's important for consumers and et cetera. I mean,
148
00:09:22.400 --> 00:09:26.160
another aspect of it is that consumers have to trust that the agent that they're
149
00:09:26.480 --> 00:09:30.480
working with knows them, understands them, and is going to bring them value.
150
00:09:31.440 --> 00:09:35.800
And then, once they bring them that value, can facilitate a seamless,
151
00:09:37.200 --> 00:09:40.200
trusted experience, when it actually comes time to buy.
152
00:09:41.080 --> 00:09:43.600
So part of our partnership with Wizard is that
153
00:09:45.640 --> 00:09:50.320
we've introduced a capability called Insight Tokens.
So initially,
154
00:09:53.640 --> 00:09:56.620
it's just the base case that we're doing initially with Wizard.
155
00:09:57.060 --> 00:10:01.600
And these are geo-based insights, so ZIP+4 Insights,
156
00:10:01.920 --> 00:10:05.700
similar insights that we've been using actually for ad targeting for many,
157
00:10:05.760 --> 00:10:10.740
many years, like out of our data and services business unit at Mastercard.
158
00:10:13.280 --> 00:10:14.940
And these GeoInsights,
159
00:10:15.520 --> 00:10:18.920
what they do is they're-in an aggregated and anonymized,
160
00:10:18.940 --> 00:10:23.780
privacy-safe way-they can help Wizard know that
161
00:10:24.860 --> 00:10:29.400
I live in Westport, Connecticut, in a certain part of Westport,
162
00:10:29.460 --> 00:10:32.440
Connecticut. And, in that part of Westport, Connecticut,
163
00:10:32.580 --> 00:10:37.320
it means that I'm more likely to want to shop at,
164
00:10:37.860 --> 00:10:41.480
let's say, a boutique to buy the...
165
00:10:41.960 --> 00:10:45.920
Let's say I'm looking for a T-shirt, a white T-shirt.
166
00:10:47.700 --> 00:10:52.100
The kind of white T-shirt that might be surfaced to me from the local
167
00:10:52.160 --> 00:10:56.840
boutiques that are near me might be quite different from what
168
00:10:57.320 --> 00:11:00.980
Wizard would surface for you, Jen, because you live here and
169
00:11:04.120 --> 00:11:05.880
maybe you just like different kinds of T-shirts.
170
00:11:06.000 --> 00:11:07.500
Yeah. And definitely different for Pablo.
171
00:11:08.280 --> 00:11:12.160
And definitely different for Pablo. That's right. And so
172
00:11:13.940 --> 00:11:17.840
because we're working together with Wizard to enable
173
00:11:19.400 --> 00:11:23.440
relevant things that a user would then be like, "Oh,
174
00:11:24.020 --> 00:11:28.560
shopping with Wizard makes... Wizard understands me. And shopping with Wizard,
175
00:11:28.700 --> 00:11:32.460
even though I haven't necessarily, through a chatbot interface,
176
00:11:32.520 --> 00:11:37.320
given Wizard every single detail about the things I'm worried about in the
177
00:11:38.160 --> 00:11:41.560
every day or whatever anybody uses chatbots for..."
178
00:11:43.600 --> 00:11:48.480
We're still able to... Together, we're able to then deliver this really...
179
00:11:49.440 --> 00:11:50.780
An experience that doesn't feel creepy,
180
00:11:51.860 --> 00:11:55.580
but at the same time is beneficial and delightful,
181
00:11:56.580 --> 00:11:58.420
and that also builds trust.
182
00:11:59.720 --> 00:11:59.860
Yeah.
183
00:11:59.860 --> 00:12:04.240
I like to think of it as "frictionless personalization." We can get a lot of
184
00:12:04.280 --> 00:12:08.580
signals about you even before you query to provide that level of trust that this
185
00:12:08.680 --> 00:12:11.900
agent knows what you're looking for. And at Wizard,
186
00:12:11.960 --> 00:12:14.880
we're really thinking about trust across the customer journey.
187
00:12:15.520 --> 00:12:20.180
How do we win consumers over to trust our agent to ultimately,
188
00:12:20.360 --> 00:12:24.300
one day, place a purchase on their behalf, right?
189
00:12:24.360 --> 00:12:28.820
So I think it starts with smart discovery where we really
190
00:12:28.880 --> 00:12:32.220
understand the user's complex queries, it's no longer keyword search.
191
00:12:32.960 --> 00:12:35.120
Then it goes to the native checkout layer.
192
00:12:35.620 --> 00:12:39.180
We're big believers that not only is discovery important,
193
00:12:39.240 --> 00:12:41.760
but you have to be able to place that order. And at Wizard,
194
00:12:41.840 --> 00:12:43.880
we're working closely with Stripe.
195
00:12:43.940 --> 00:12:46.840
We're going to be the first agent that supports the Universal Cart.
196
00:12:46.900 --> 00:12:50.460
So you can add multiple products across retailers. And then, finally,
197
00:12:50.520 --> 00:12:54.320
with personalization, if you trust that the agent knows you,
198
00:12:54.440 --> 00:12:58.900
only then are you going to trust them to make that purchasing decision with or
199
00:12:58.920 --> 00:13:01.640
without you. So that leads to that final stage of automation.
200
00:13:02.080 --> 00:13:06.840
Yeah. Actually, that makes me think about how there's a difference between
201
00:13:07.440 --> 00:13:09.000
delegating and automating,
202
00:13:09.220 --> 00:13:12.680
because we've automated checkout and commerce for years.
203
00:13:13.060 --> 00:13:16.960
What do you think is different when consumers delegate authority to an agent
204
00:13:17.040 --> 00:13:19.280
instead of just having them automate a task?
205
00:13:23.040 --> 00:13:23.873
Sure.
206
00:13:24.600 --> 00:13:28.520
So I think it's an interesting time because usually you'd be the
207
00:13:28.600 --> 00:13:30.220
human-in-the-loop, and you'd say, "Okay,
208
00:13:30.340 --> 00:13:33.580
I approve this transaction." I think the future's going to be very much
209
00:13:34.620 --> 00:13:39.400
policy-driven: this is the wiggle room, this is around the budget,
210
00:13:39.460 --> 00:13:42.880
but here are the exceptions. And I think that itself will grow over time.
211
00:13:42.940 --> 00:13:44.560
These are things that we're starting to think about,
212
00:13:45.640 --> 00:13:50.120
but mainly I think agents are going to make commerce a lot more efficient.
213
00:13:50.380 --> 00:13:51.480
We're big believers of that,
214
00:13:51.560 --> 00:13:55.200
of helping you find that product that meets your needs. And so
215
00:13:57.180 --> 00:13:58.740
originally it'll start with assistance,
216
00:13:58.800 --> 00:14:00.900
but ultimately it'll start with more and more automation,
217
00:14:00.960 --> 00:14:04.040
and I'll bring you into the loop for large purchase items and things that make
218
00:14:04.080 --> 00:14:06.120
sense. But long-term,
219
00:14:06.500 --> 00:14:10.240
it's going to be saving all of us the six to eight hours a week that we waste
220
00:14:10.780 --> 00:14:14.620
doing the same thing. So I think that's-really excited for that future.
221
00:14:16.000 --> 00:14:16.833
I mean, we agree,
222
00:14:20.100 --> 00:14:23.060
and in order to make that possible,
223
00:14:24.640 --> 00:14:26.380
like what we did was take a step back,
224
00:14:27.020 --> 00:14:31.160
and Pablo's going to explain a little bit more about this in detail,
225
00:14:31.220 --> 00:14:34.200
but we took a step back and we said,
226
00:14:35.720 --> 00:14:38.920
"We have billions of transactions in our network all the time, and
227
00:14:40.860 --> 00:14:43.540
people trust us a lot." And so,
228
00:14:45.100 --> 00:14:49.340
there's a real market shift when you're delegating authority basically to a
229
00:14:49.380 --> 00:14:51.400
piece of software to act on your behalf.
230
00:14:52.240 --> 00:14:56.180
It's very different than when you are going yourself to a website or an app
231
00:14:56.520 --> 00:15:01.440
reading all of the product description, reading the terms of sale, reading,
232
00:15:01.510 --> 00:15:05.850
for example, that maybe you're buying something that's final sale.
233
00:15:07.110 --> 00:15:10.750
You're making that decision, you're seeing it with your own eyes. So,
234
00:15:11.790 --> 00:15:16.750
there has to be some way to fill the gap that exists when you're delegating that
235
00:15:16.770 --> 00:15:20.970
authority to a piece of software, which is where Pablo comes in.
236
00:15:25.270 --> 00:15:29.410
So I think, indeed, it's different because one thing is if it's automation,
237
00:15:29.470 --> 00:15:33.230
it's just very clear what it's doing, right? And if I'm delegating,
238
00:15:34.030 --> 00:15:37.870
I'm giving some autonomy to the agent,
239
00:15:39.690 --> 00:15:41.890
and at the core, the question is, "Okay,
240
00:15:41.990 --> 00:15:46.960
but so the autonomy within what boundary?" What's the...
241
00:15:48.530 --> 00:15:50.490
No, because I'm not going to just say,
242
00:15:50.490 --> 00:15:53.330
"Whatever." I'm going to put a boundary around some constraints around it.
243
00:15:54.050 --> 00:15:58.910
And then there needs to be a way to ensure that
244
00:15:59.070 --> 00:16:02.830
actually the agent stays within those boundaries on those constraints.
245
00:16:05.330 --> 00:16:09.280
And so that's basically what it's going to take for this promise of
246
00:16:10.570 --> 00:16:13.510
more autonomous AI shopping, I think,
247
00:16:14.070 --> 00:16:18.270
or commerce to unfold is that we can effectively
248
00:16:19.870 --> 00:16:23.390
capture both the instruction that I'm giving the agent,
249
00:16:23.810 --> 00:16:26.590
the boundaries that I put around the autonomy that it has,
250
00:16:26.910 --> 00:16:31.180
and that can be verified. And so we put a lot of...
251
00:16:32.470 --> 00:16:35.050
This, everybody agrees, I think. It's kind of obvious in a sense.
252
00:16:36.130 --> 00:16:39.890
And so the work that we have spent a lot of time on is to, okay,
253
00:16:39.950 --> 00:16:43.210
so how do you actually implement that in a way that is workable?
254
00:16:46.670 --> 00:16:50.930
And so we developed this specification basically,
255
00:16:51.550 --> 00:16:54.270
ways of doing it and implementation for doing exactly that,
256
00:16:54.810 --> 00:16:59.510
which we call "Verifiable Intent." And it capture actually, firstly,
257
00:16:59.570 --> 00:17:00.403
it captures
258
00:17:01.930 --> 00:17:05.870
it's me that is actually authorizing the agent to do something.
259
00:17:07.170 --> 00:17:11.950
And so if it's a fraudster that is doing it, you can make a difference,
260
00:17:12.030 --> 00:17:15.330
right? And then it captures what is it that I'm asking the agent to do and what
261
00:17:15.390 --> 00:17:17.670
boundaries, what constraints I put in. And so for example,
262
00:17:17.740 --> 00:17:22.050
I would be able to say whether this final sale,
263
00:17:22.150 --> 00:17:23.670
whether I provided this or not,
264
00:17:23.740 --> 00:17:27.220
or whether at which merchant I want it to be shopped,
265
00:17:27.290 --> 00:17:30.030
or like it can be defined depending on the use case,
266
00:17:31.050 --> 00:17:32.450
and then it can be verified.
267
00:17:33.210 --> 00:17:36.950
And so I think that creates the basis for basically then
268
00:17:38.350 --> 00:17:41.550
innovating and coming up with what are the use cases that make sense for
269
00:17:41.590 --> 00:17:44.950
consumers.
And I do believe it's a continuum, right?
270
00:17:45.240 --> 00:17:49.850
And starting with me being in the loop already provides me tremendous
271
00:17:50.150 --> 00:17:53.960
value to be able to discover things immediately and not have to go to the
272
00:17:54.030 --> 00:17:56.390
website, that's super convenient, super valuable.
273
00:17:57.150 --> 00:18:01.790
But if I can actually do more than that, I think we're... Yeah.
274
00:18:02.110 --> 00:18:04.790
And at the end of the day, if something goes wrong,
275
00:18:06.270 --> 00:18:10.890
like a consumer wants to know or a small business wants to know that they can
276
00:18:11.770 --> 00:18:16.630
exercise their same rights and get the same consumer protections as
277
00:18:16.670 --> 00:18:19.730
they would if they were going to the website and reading those terms themselves.
278
00:18:20.190 --> 00:18:21.350
It's this technology
279
00:18:22.890 --> 00:18:27.140
that Pablo just spoke about that then feeds into...
280
00:18:27.430 --> 00:18:28.390
It closes the loop.
281
00:18:28.450 --> 00:18:33.210
It closes that gap I mentioned before between you being there and you
282
00:18:33.290 --> 00:18:34.123
not being there.
283
00:18:34.850 --> 00:18:39.590
It feeds this data object into basically our chargeback system
284
00:18:40.150 --> 00:18:44.150
so that if something does go wrong-and only when, by the way,
285
00:18:44.210 --> 00:18:48.790
something goes wrong-the issuer would have access to this information to be able
286
00:18:48.850 --> 00:18:51.810
to see what happened and understand what authority you did.
287
00:18:51.890 --> 00:18:55.950
So that did give the merchants that we're not enabling also a giant ecosystem
288
00:18:56.670 --> 00:18:59.710
of friendly fraud, which I actually call theft.
289
00:19:02.310 --> 00:19:06.150
Because that would obviously be the last thing that we want to enable.
And so,
290
00:19:07.890 --> 00:19:11.990
yes, for us, it seemed kind of obvious, but to actually put it together was,
291
00:19:12.490 --> 00:19:17.070
it's not a simple task because it involves many parties and
292
00:19:17.590 --> 00:19:20.850
all of that stuff, and then it has to be implemented by the ecosystem.
293
00:19:20.910 --> 00:19:24.850
But that is kind of the glue that we think is going to really bring it all
294
00:19:24.870 --> 00:19:25.703
together.
295
00:19:25.750 --> 00:19:28.650
Yeah, that makes sense. Actually, I have a follow-up question for you, Sherri,
296
00:19:28.730 --> 00:19:32.430
but first actually maybe a question for the audience and raise of hands.
297
00:19:33.030 --> 00:19:36.150
I'm curious, after hearing about all of this, or maybe before,
298
00:19:37.250 --> 00:19:40.650
let's say you're in the market for a white T-shirt,
299
00:19:41.690 --> 00:19:45.210
a raise of hands of who wants to be the one where you still have to click the
300
00:19:45.250 --> 00:19:46.083
button?
301
00:19:49.910 --> 00:19:53.250
And then who wants to just delegate that away?
302
00:19:53.670 --> 00:19:58.630
Let the agent click the button. Okay, interesting. That's cool.
303
00:19:58.710 --> 00:20:00.110
And who still wants to go to the store?
304
00:20:03.530 --> 00:20:05.890
A little bit of both. Maybe I'll have the agent checkout from the store.
305
00:20:06.210 --> 00:20:07.810
Exactly. Well, no, but with Wizard,
306
00:20:08.070 --> 00:20:10.160
you can actually see examples of the store and then...
307
00:20:10.750 --> 00:20:11.583
Exactly.
308
00:20:11.630 --> 00:20:12.150
Yeah.
309
00:20:12.150 --> 00:20:12.983
Well, I have to go there.
310
00:20:13.190 --> 00:20:16.270
Yeah. I think it's going to be a hybrid. I think, personally,
311
00:20:16.590 --> 00:20:20.370
I think every now and then I like to go to the store and feel the object that I
312
00:20:20.390 --> 00:20:22.910
might be buying or see what size it is. And so,
313
00:20:23.590 --> 00:20:26.530
I think it really depends on the use case, that white T-shirt,
314
00:20:27.070 --> 00:20:30.690
maybe I'm really into a style, and there's some subjectivity to it,
315
00:20:30.730 --> 00:20:33.110
and maybe my agent over time will learn my style,
316
00:20:33.230 --> 00:20:36.270
but I think making everything more efficient,
317
00:20:36.450 --> 00:20:38.590
humans can then make those quick decisions.
318
00:20:39.310 --> 00:20:40.850
And so it's fine if we're still in the loop.
319
00:20:41.630 --> 00:20:45.090
For sure. Especially when you're talking earlier, saving that time,
320
00:20:46.230 --> 00:20:47.063
we're so busy.
321
00:20:47.350 --> 00:20:50.650
Yeah. That's the unfun part of shopping.
322
00:20:50.870 --> 00:20:52.830
I think making the purchasing decision could be fun.
323
00:20:53.490 --> 00:20:58.110
Yes. Keep the fun parts fun. Going back to the responsibility part,
324
00:20:58.170 --> 00:21:03.070
I think something that, when I hear merchants thinking about this space,
325
00:21:03.950 --> 00:21:06.850
they hear about the chargebacks, they hear about the friendly fraud,
326
00:21:07.210 --> 00:21:10.670
and they just want to be reassured and basically have an answer to:
327
00:21:10.970 --> 00:21:14.150
who is responsible for the trust in the agent-driven world?
328
00:21:15.310 --> 00:21:18.130
Obviously there's platforms, there's networks, there's someone else,
329
00:21:18.510 --> 00:21:21.150
and there's also your role that you were talking about earlier as well.
330
00:21:23.830 --> 00:21:27.570
How do you think about this space when no single company can, or maybe should,
331
00:21:27.650 --> 00:21:28.850
actually control the agent?
332
00:21:29.590 --> 00:21:32.450
And I think that's actually a lot part of the answer,
333
00:21:32.510 --> 00:21:34.990
that it's everyone's responsibility.
334
00:21:35.970 --> 00:21:38.890
In order for this whole thing to work,
335
00:21:40.150 --> 00:21:41.570
we all have to come together. I mean,
336
00:21:41.670 --> 00:21:43.790
this is a good example of some parties coming together,
337
00:21:43.850 --> 00:21:46.690
but there's also issuers, there's PSPs, there's acquirers,
338
00:21:48.070 --> 00:21:50.850
there's ecommerce platform providers. There's so many different entities.
339
00:21:50.910 --> 00:21:54.150
There's merchants that all come together and have to do their part. And
340
00:21:56.250 --> 00:21:59.710
we're helping to do a lot of the work for these ecosystem participants and so
341
00:21:59.830 --> 00:22:04.610
are you. So that also, we talked about it earlier,
342
00:22:05.050 --> 00:22:05.883
Devang,
343
00:22:06.390 --> 00:22:10.730
that entities like Wizard can more easily take advantage of this kind of
344
00:22:10.750 --> 00:22:11.583
technology,
345
00:22:11.590 --> 00:22:16.350
but it really is everyone being aware that although we're trying to make it easy
346
00:22:16.430 --> 00:22:17.263
and seamless,
347
00:22:17.270 --> 00:22:21.510
it definitely is a shift and a change that does involve people coming to the
348
00:22:21.550 --> 00:22:22.910
table and doing the work.
349
00:22:23.950 --> 00:22:27.770
So we do encourage anybody who's a merchant in the room.
350
00:22:27.770 --> 00:22:28.710
You guys should be doing the work.
351
00:22:30.310 --> 00:22:34.610
Yeah. One thing I would say on this is, for this to work well,
352
00:22:34.850 --> 00:22:38.690
especially on the edge cases, this idea of how you share data
353
00:22:40.550 --> 00:22:44.350
related to the transaction is quite important. You gave the example of
354
00:22:45.990 --> 00:22:48.650
if the issuer needs to help the consumer resolve something, well,
355
00:22:48.710 --> 00:22:50.710
how do they do it if they don't have access to this data?
356
00:22:51.250 --> 00:22:53.730
Same thing on the merchant side. If it's interacting with an agent,
357
00:22:54.130 --> 00:22:55.770
it needs to be able to verify some data.
358
00:22:57.050 --> 00:23:01.370
And so sharing of the data across the ecosystem is one key element of this,
359
00:23:02.450 --> 00:23:06.710
but there's a tension there because you want to do it in a way that is
360
00:23:07.930 --> 00:23:12.610
private, that the data is shared for a purpose, basically.
361
00:23:12.870 --> 00:23:17.670
And the purpose is to make sure that there is no mistakes or the
362
00:23:17.710 --> 00:23:19.710
merchant can validate the transaction.
363
00:23:20.410 --> 00:23:25.170
And so part of what we've done is to build privacy within the
364
00:23:25.230 --> 00:23:29.070
protocols to share this data.
And so there is this
365
00:23:30.550 --> 00:23:32.230
concept that we leverage that is called "selective disclosure."
366
00:23:33.970 --> 00:23:37.630
And so basically all of this data is hashed, and so it's meaningless,
367
00:23:37.790 --> 00:23:42.090
except for the parties that choose to selectively disclose it to each other so
368
00:23:42.150 --> 00:23:44.030
that, for example, a merchant can validate, "Oh yeah,
369
00:23:44.510 --> 00:23:48.510
this is an agent that has a consumer authorized that agent to make that
370
00:23:48.570 --> 00:23:48.930
purchase.
371
00:23:48.930 --> 00:23:52.910
And I can validate that because I am the counterparty." And if you have your
372
00:23:52.950 --> 00:23:55.310
multimerchant basket, well,
373
00:23:58.210 --> 00:24:01.050
it's not going to share the data of one merchant with the other merchant because
374
00:24:01.430 --> 00:24:05.330
it's built in a way that you don't have to do that. And likewise,
375
00:24:05.970 --> 00:24:07.950
if there is a dispute that happens
376
00:24:09.970 --> 00:24:11.470
hopefully very infrequently,
377
00:24:11.870 --> 00:24:15.190
but it's only when it happens that then you can then leverage this data to
378
00:24:15.250 --> 00:24:19.050
resolve it. And so this idea of having privacy built in,
379
00:24:20.130 --> 00:24:22.930
I think it's a very important aspect
380
00:24:24.530 --> 00:24:26.670
for all of us to bring scale and to scale this.
381
00:24:27.170 --> 00:24:28.810
Yeah. I think that makes sense. And also,
382
00:24:29.090 --> 00:24:32.330
I like how you talk about the actual underlying infrastructure.
383
00:24:33.830 --> 00:24:34.663
So I'm curious,
384
00:24:34.750 --> 00:24:37.330
you mentioned some parts of the infrastructure that's already in place,
385
00:24:37.710 --> 00:24:42.610
but where do you think concepts like Verifiable Intent fit? And then also,
386
00:24:43.050 --> 00:24:46.910
I think the spicy part of this is, where do you think they stop being enough?
387
00:24:50.250 --> 00:24:53.730
Where do they fit? I mean, I think what, as Sherri was saying,
388
00:24:56.570 --> 00:25:01.070
securing the transactions on our network, from our perspective,
389
00:25:01.530 --> 00:25:04.110
it's a key obligation, I guess, that we have.
390
00:25:04.470 --> 00:25:06.330
It's really something that I care personally about,
391
00:25:06.570 --> 00:25:11.310
making sure that every cardholder that's using our cards can have trust and that
392
00:25:11.430 --> 00:25:12.310
things will work out,
393
00:25:14.050 --> 00:25:17.230
and then we'll be able to support them if it doesn't.
394
00:25:17.870 --> 00:25:19.710
And same thing on the merchant side,
395
00:25:19.770 --> 00:25:24.470
I think it's our job to make sure that the merchant can trust this new way of
396
00:25:24.510 --> 00:25:27.710
interacting with users and this new channel and that they will get paid.
397
00:25:28.970 --> 00:25:30.030
And then, if there is an issue,
398
00:25:30.110 --> 00:25:32.810
that it will be resolved fairly and in a good way.
399
00:25:32.890 --> 00:25:36.950
And so the technologies that we bring is
400
00:25:37.650 --> 00:25:39.270
verifying the identity of the user. "Is it me?"
401
00:25:42.310 --> 00:25:45.910
Making sure that the transaction is linked to my identity and we do that with
402
00:25:45.930 --> 00:25:50.930
tokens and making transactions basically unique and they cannot
403
00:25:50.970 --> 00:25:54.210
be replayed, very difficult to do fraudulent transactions.
404
00:25:54.870 --> 00:25:58.230
And within that Verifiable Intent place, this role of providing,
405
00:25:58.370 --> 00:26:02.390
allowing the agent to prove to the merchant that they have this authority from
406
00:26:03.050 --> 00:26:06.270
the shopper-which is in our case, would be the cardholder,
407
00:26:06.330 --> 00:26:09.930
but this is an open standard that will support any different types of payment
408
00:26:09.970 --> 00:26:14.490
methods-and be able then to prove that they have this authority and that the
409
00:26:14.530 --> 00:26:18.370
merchant can trust this interaction and can start moving from a
410
00:26:18.510 --> 00:26:21.430
human-in-the-loop to a more autonomous type of purchase.
411
00:26:21.810 --> 00:26:22.810
And so I think it's very core,
412
00:26:23.270 --> 00:26:27.430
and it's very core also to the life cycle of what might happen in
413
00:26:27.930 --> 00:26:30.810
the... When all goes well, it's fantastic,
414
00:26:32.470 --> 00:26:35.570
but I know I have experience, I guess, in my family,
415
00:26:35.630 --> 00:26:37.610
what happens when things don't go very well,
416
00:26:37.870 --> 00:26:40.270
and then you have a real fraud that happens,
417
00:26:40.970 --> 00:26:43.690
and it is very unpleasant experience,
418
00:26:44.610 --> 00:26:46.350
and sometimes you don't recover the money,
419
00:26:47.910 --> 00:26:50.970
and it can be devastating for people and for families.
420
00:26:50.970 --> 00:26:53.510
And what we're trying to do is to protect against that.
421
00:26:54.990 --> 00:26:59.050
And these technologies, the consumers won't have to know about it,
422
00:26:59.350 --> 00:27:02.330
but the fact that we are doing the work together so that that is something that
423
00:27:02.650 --> 00:27:05.550
we don't need to think about. Yeah.
424
00:27:06.710 --> 00:27:09.830
Yeah. I think that makes a lot of sense. And then we're coming up on time here.
425
00:27:09.890 --> 00:27:12.110
So I have one final question for all of you.
426
00:27:13.550 --> 00:27:18.090
What do you think is the responsibility of leaders and builders in this room
427
00:27:18.370 --> 00:27:20.130
as agentic commerce evolves?
428
00:27:21.030 --> 00:27:24.950
And we'd love to maybe start with Devang and go through the row.
429
00:27:25.010 --> 00:27:28.850
Yeah. I think you've heard trust is basically throughout.
430
00:27:29.250 --> 00:27:33.110
And I think what agentic commerce allows us to do is rethink the things that we
431
00:27:33.210 --> 00:27:34.730
learned from traditional ecommerce.
432
00:27:34.870 --> 00:27:38.970
It gives us that opportunity to bring it not only on the ecosystem level,
433
00:27:39.070 --> 00:27:41.810
which Stripe and Mastercard are really helping establish,
434
00:27:42.130 --> 00:27:43.470
but also the customer journey.
435
00:27:43.530 --> 00:27:47.670
How do we rethink trust to win the consumer's trust to start
436
00:27:48.570 --> 00:27:51.470
basically solving shopping, which really excites me.
437
00:27:54.290 --> 00:27:58.430
I think everyone also just needs to lean in and not wait.
438
00:27:59.570 --> 00:28:01.990
I mean, I gave the example earlier of,
439
00:28:02.950 --> 00:28:07.090
and actually I think it was either Will or, it was Will, I think,
440
00:28:07.110 --> 00:28:08.470
that mentioned it yesterday on stage:
441
00:28:10.490 --> 00:28:15.190
it's okay that it's not scaling wildfire yet on the big
442
00:28:15.390 --> 00:28:18.830
LLMs. We're seeing so many examples of, well, number one,
443
00:28:18.890 --> 00:28:19.770
they're all participating,
444
00:28:19.830 --> 00:28:24.250
but we're seeing so many examples of shopping agents,
445
00:28:24.470 --> 00:28:27.350
merchant agents. There's other things going on,
446
00:28:28.790 --> 00:28:30.130
and just don't wait
447
00:28:31.870 --> 00:28:35.770
because these things tend to go like that.
448
00:28:37.570 --> 00:28:39.330
And if I'm an issuer,
449
00:28:39.470 --> 00:28:44.010
I'm also finding out what my consumers want.
450
00:28:44.090 --> 00:28:45.410
If I'm anyone in the ecosystem,
451
00:28:45.470 --> 00:28:47.810
I'm finding out what my customers and what end users want,
452
00:28:48.870 --> 00:28:51.230
and I'm going ahead and getting involved.
453
00:28:52.950 --> 00:28:55.790
Yeah. I would say the builder piece, I couldn't agree more.
454
00:28:55.850 --> 00:28:57.690
So going doing the things, and
455
00:28:59.490 --> 00:29:03.610
if you have ideas or feedback or things that you want to see changed because you
456
00:29:03.630 --> 00:29:07.730
have a use case or you have something that you want to happen and somehow it's
457
00:29:07.810 --> 00:29:11.750
not there, I think you can always engage.
458
00:29:12.390 --> 00:29:15.170
And we put, for example,
459
00:29:15.650 --> 00:29:20.210
this spec and et cetera on GitHub, we have contributed to FIDO. Anybody,
460
00:29:20.270 --> 00:29:23.990
it's open there, you can go in there and you can submit,
461
00:29:24.070 --> 00:29:27.830
you can actually build on it, you can develop,
462
00:29:27.890 --> 00:29:29.670
you can make contributions and
463
00:29:31.210 --> 00:29:34.770
enable those use cases that you want to do for your business.
464
00:29:35.490 --> 00:29:38.370
And we are there to support, basically,
465
00:29:38.370 --> 00:29:40.770
to support it from our perspective,
466
00:29:41.930 --> 00:29:45.250
but we can do it like it's really done by the builders. Yes.
467
00:29:46.270 --> 00:29:50.970
Yeah. That's awesome. All right. Perfect timing. Thank you all for the time.
468
00:29:51.290 --> 00:29:54.010
And it sounds like we all just have to just get started.
469
00:29:54.130 --> 00:29:58.370
So hopefully you all enjoyed the session with us today,
470
00:29:58.690 --> 00:30:00.950
and thank you all for coming to our panel.
471
00:30:01.110 --> 00:30:01.350
Thank you.