WEBVTT
1
00:00:10.440 --> 00:00:13.920
Hello. Welcome. Thank you for being here. We're excited to have you.
2
00:00:13.980 --> 00:00:16.120
Welcome to Sessions. My name is Alex.
3
00:00:16.220 --> 00:00:18.040
I'm the head of product for core payment at Stripe.
4
00:00:18.540 --> 00:00:20.560
And today I'll be talking about multiprocessor.
5
00:00:20.800 --> 00:00:24.180
So we'll be talking about when to consider it and how to go about it.
6
00:00:25.540 --> 00:00:27.220
Before we start, just a show of hands,
7
00:00:27.380 --> 00:00:31.960
I'm curious who in the room already has multiple PSPs or is actively
8
00:00:32.020 --> 00:00:36.780
considering it. Okay. I see a good amount of hands. You're in the right room.
9
00:00:36.920 --> 00:00:37.753
Perfect.
10
00:00:39.100 --> 00:00:42.580
And this actually matched what we see in industry research.
11
00:00:42.640 --> 00:00:47.280
About 62% of enterprises actually suggest they prefer to use multiple
12
00:00:47.300 --> 00:00:51.120
PSPs. And it's pretty appealing, right? You can avoid vendor lock-in,
13
00:00:51.580 --> 00:00:56.200
you can reduce your payment costs, you can expand globally. The reality though,
14
00:00:56.280 --> 00:01:00.980
maybe many of you in the room know every PSP you add adds a lot of complexity.
15
00:01:01.540 --> 00:01:04.640
And so today we'll really talk about three things to really help you weigh the
16
00:01:04.740 --> 00:01:07.800
trade-off of going multiprocessor. First,
17
00:01:07.860 --> 00:01:10.160
we'll talk about why you might want to go multiprocessor.
18
00:01:10.220 --> 00:01:12.960
What are the common reasons that we hear in the market and from our users?
19
00:01:13.580 --> 00:01:16.620
And then my colleague John will come on stage and talk about the different
20
00:01:16.720 --> 00:01:17.780
implementation paths.
21
00:01:17.860 --> 00:01:20.200
What are the trade-offs between the different options you have?
22
00:01:20.640 --> 00:01:24.240
And then Josh from Canva will join me on stage and we'll have a little fireside
23
00:01:24.260 --> 00:01:24.800
chat.
24
00:01:24.800 --> 00:01:28.400
We'll talk about Canva's experience of going multiprocessor and what they've
25
00:01:28.420 --> 00:01:32.940
learned to share with all of you. So let's get started. Why go multiprocessor?
26
00:01:34.000 --> 00:01:35.080
So we're going to try something here.
27
00:01:35.240 --> 00:01:37.680
This is the first time you're doing this is the first time I'm doing this.
28
00:01:37.760 --> 00:01:40.340
If you can try to scan this QR code, pull your phone,
29
00:01:40.660 --> 00:01:43.940
this should take you into the sessions app.
And I want you to answer this
30
00:01:43.980 --> 00:01:47.360
question: why are you considering a multiprocessor strategy?
31
00:01:47.460 --> 00:01:49.140
Is it redundancy and reliability?
32
00:01:49.800 --> 00:01:54.400
Is it performance and cost optimization or is it geo expansion? In practice,
33
00:01:54.520 --> 00:01:58.300
it may be multiple things, but try to pick the one that resonates the most.
34
00:01:59.920 --> 00:02:03.840
I'm going to see if this is working. I'm seeing some votes coming in.
35
00:02:04.680 --> 00:02:07.220
So please keep trying.
36
00:02:08.880 --> 00:02:12.880
I'm going to give you a minute here. All right.
37
00:02:14.100 --> 00:02:15.280
It's pretty balanced.
38
00:02:20.800 --> 00:02:23.880
All right. Okay. Oh wow. Okay. I see now a lot of responses. Okay.
39
00:02:23.940 --> 00:02:24.773
So it's pretty balanced.
40
00:02:24.820 --> 00:02:27.480
Looks like performance and cost optimization is the winner though.
41
00:02:28.320 --> 00:02:32.600
And no surprises. We hear this a lot from our users as well. So let's dive in.
42
00:02:33.720 --> 00:02:36.040
And so what are the benefits of going multiprocessor?
43
00:02:36.120 --> 00:02:39.320
The first one is to avoid a single point of failure. Let's take an example.
44
00:02:39.680 --> 00:02:44.500
Let's say you have a single PSP and you're having unfortunately an outage on
45
00:02:44.540 --> 00:02:47.180
your biggest day of the year. Maybe it's Black Friday.
46
00:02:47.680 --> 00:02:49.360
Maybe it's a big product launch day for you.
47
00:02:50.160 --> 00:02:54.040
Maybe you've had a marketing campaign all week. What happens? Your sales stop,
48
00:02:54.400 --> 00:02:57.320
your customers are leaving. Maybe they're going to your competitor.
49
00:02:57.740 --> 00:03:00.460
They start complaining on social media. Your internal teams,
50
00:03:00.520 --> 00:03:02.140
your finance team is asking what's happening.
51
00:03:03.000 --> 00:03:06.920
A nightmare scenario that you try to avoid at all cost.
And the damage can,
52
00:03:06.980 --> 00:03:08.020
of course, be really severe.
53
00:03:08.300 --> 00:03:12.880
A survey into large enterprises suggests that about an hour of IT downtime
54
00:03:13.240 --> 00:03:18.140
can be up to $5 million in lost revenue. And it's not just revenue, right?
55
00:03:18.660 --> 00:03:20.900
It can be your reputation, your brand as a company,
56
00:03:21.060 --> 00:03:24.460
it could be your stock price if you're a public company. And so in many cases,
57
00:03:25.260 --> 00:03:29.140
multiprocessor and redundancy is actually a boardroom mandate.
58
00:03:29.220 --> 00:03:33.840
And maybe for some of you, that's the case. And so when you have multiple PSPs,
59
00:03:34.100 --> 00:03:36.100
if your transaction fail on your primary PSP,
60
00:03:36.500 --> 00:03:38.680
you can instantly retry in a second processor.
61
00:03:39.000 --> 00:03:41.960
You saved the sale and you've protected the customer experience.
62
00:03:43.980 --> 00:03:47.240
Moving on to the second reason. A lot of you, and we just saw in the survey,
63
00:03:47.700 --> 00:03:51.520
are actually going multiprocessor for the idea of improving performance.
64
00:03:51.820 --> 00:03:55.300
And you can intelligently route your payments between the different PSPs that
65
00:03:55.320 --> 00:03:56.153
you have.
66
00:03:56.160 --> 00:04:01.040
Maybe you do it by type of cards or by regions or by amount or many more
67
00:04:01.120 --> 00:04:04.040
sophisticated strategies. And to improve your performance,
68
00:04:04.100 --> 00:04:06.640
that means potentially reduce your cost, your processor costs,
69
00:04:06.720 --> 00:04:10.400
your network cost, but also improve your payment success rate,
70
00:04:10.480 --> 00:04:13.300
improve your auth rate. And so we'll take a very simple example here.
71
00:04:13.940 --> 00:04:17.200
Let's say you're a business running about a hundred million dollar a year and
72
00:04:17.220 --> 00:04:20.100
you have a first PSP, which has a 95% auth rate,
73
00:04:20.580 --> 00:04:23.620
but then you decide to run a champion challenger test.
74
00:04:24.180 --> 00:04:28.220
And you find that the other PSP actually has half a percent more authorization
75
00:04:28.280 --> 00:04:29.400
rate. Well,
76
00:04:29.460 --> 00:04:34.460
that means 500,000 in revenue for you directly for your business.
So
77
00:04:34.520 --> 00:04:38.500
it's a very tangible reason why you might want to try to optimize between
78
00:04:38.540 --> 00:04:41.980
different PSPs. And then finally,
79
00:04:42.240 --> 00:04:45.920
we'll go to the third reason, which is geo expansion.
80
00:04:46.760 --> 00:04:49.660
For all of you that are considering geo expansion or maybe actively doing it,
81
00:04:49.840 --> 00:04:53.720
you probably know that the hard part isn't really to figure out where you want
82
00:04:53.760 --> 00:04:54.593
to go next.
83
00:04:55.100 --> 00:04:58.900
It's really the investment required to build that infrastructure,
84
00:04:59.060 --> 00:05:02.360
operate in that country, potentially integrate with a regional PSP,
85
00:05:03.020 --> 00:05:04.940
integrate with the local payment methods.
86
00:05:05.360 --> 00:05:08.300
That can be a month-long projects or maybe a year-long project.
87
00:05:08.640 --> 00:05:11.000
It's a massive amount of time and investment.
88
00:05:12.940 --> 00:05:14.440
But the payoff is pretty clear.
89
00:05:15.620 --> 00:05:20.500
One in three buyer will abandon their cart if they don't find their preferred
90
00:05:20.540 --> 00:05:23.880
payment method at checkout. And even if you make the sale,
91
00:05:24.220 --> 00:05:27.400
the cross-border processing fee can be 10x more than domestic.
92
00:05:27.860 --> 00:05:32.620
That also directly eats into your margin.
And so with a multiprocessor strategy,
93
00:05:33.100 --> 00:05:37.860
you can maximize your reach, and in most cases, do so at the cheapest cost.
94
00:05:40.140 --> 00:05:43.640
So if any of these resonated with you and your company's priority,
95
00:05:44.360 --> 00:05:48.260
the next step is going to be to evaluate the different implementation path.
96
00:05:48.480 --> 00:05:53.040
How should you go about implementing your multiprocessor strategy? And for this,
97
00:05:53.520 --> 00:05:56.120
I'm going to have my colleague Jon Krauss come on stage.
98
00:06:02.080 --> 00:06:05.260
Thanks, Alex. You sold us. We're ready to implement.
99
00:06:05.800 --> 00:06:08.060
We want to go multiprocessor. How do we do it?
100
00:06:08.680 --> 00:06:11.380
So really there are just two paths: you do this in-house.
101
00:06:11.880 --> 00:06:14.660
You figure out what connections do you need, you stand those up,
102
00:06:14.960 --> 00:06:18.340
you maintain your data, or you work with a third-party orchestrator.
103
00:06:18.700 --> 00:06:22.120
So I'm going to dive into those and Stripe supports businesses across both
104
00:06:22.160 --> 00:06:26.060
spectrums. But first, we're going to try this again.
105
00:06:26.560 --> 00:06:29.800
And now you guys are professionals. So please take out your phone.
106
00:06:29.880 --> 00:06:30.780
And I saw earlier,
107
00:06:30.920 --> 00:06:34.500
many of you raised your hands that you've started on this journey already and
108
00:06:34.760 --> 00:06:39.500
share how long have you been working on or did it take you to
109
00:06:39.560 --> 00:06:43.420
integrate an additional payment provider? Was it six months, 12 months,
110
00:06:43.920 --> 00:06:48.020
two years? Still working on it. Please share.
111
00:06:49.260 --> 00:06:53.720
Okay. We have some swift engineering teams represented in this house.
112
00:06:55.660 --> 00:06:58.880
So I think that the bottom line here is it's not a de minimis investment.
113
00:06:59.540 --> 00:07:03.700
So while the benefits are compelling, as Alex outlined,
114
00:07:04.040 --> 00:07:06.860
it's a significant commitment to go multiprocessor.
115
00:07:07.500 --> 00:07:11.640
So let's talk about the build-in-house solution. Why would I do this?
116
00:07:12.840 --> 00:07:14.440
I would do this for maximum control.
117
00:07:15.300 --> 00:07:17.420
Payments is a top priority for my organization,
118
00:07:17.940 --> 00:07:19.800
and I can't afford to outsource this.
119
00:07:20.280 --> 00:07:22.100
I need to be in control of the routing strategy.
120
00:07:22.200 --> 00:07:24.000
I need to be in control of the retry strategy.
121
00:07:24.340 --> 00:07:27.740
It needs to integrate perfectly with my own other systems.
122
00:07:28.440 --> 00:07:33.280
That's why businesses go in-house. However, there's significant trade-off,
123
00:07:33.360 --> 00:07:37.040
and it seems like many in the room understand that, and it's cost.
124
00:07:37.540 --> 00:07:40.540
So you need to stand up this integration yourself.
125
00:07:40.900 --> 00:07:43.420
So you've got a new processor that you want to connect to.
126
00:07:43.800 --> 00:07:46.380
That's a net-new connection for your business,
127
00:07:46.960 --> 00:07:51.140
and you have to maintain the payment data yourself.
The payment data is PCI
128
00:07:51.220 --> 00:07:54.860
sensitive and has the highest degree of scrutiny from a compliance perspective.
129
00:07:55.440 --> 00:07:57.600
And on top of that, you need to maintain that data.
130
00:07:58.380 --> 00:08:02.080
If you want maximum conversion, maximum authorization rate,
131
00:08:02.340 --> 00:08:05.760
you need to use things like network tokenization, card account updater,
132
00:08:06.120 --> 00:08:09.000
and those are independent integrations themselves with the schemes.
133
00:08:09.580 --> 00:08:11.560
And then on top of that, you need to maintain all of this.
134
00:08:11.920 --> 00:08:14.860
So you not only have to stand up this integration,
135
00:08:14.980 --> 00:08:17.240
but the requirements can change over time.
136
00:08:17.480 --> 00:08:19.200
There's an ongoing operational burden.
137
00:08:19.660 --> 00:08:23.580
And one of the misconceptions that we see most often is businesses that feel
138
00:08:23.920 --> 00:08:25.500
compelled to do this themselves.
139
00:08:25.920 --> 00:08:29.740
They start down this journey and they realize they cannot sustain the
140
00:08:29.760 --> 00:08:30.593
investment.
141
00:08:30.600 --> 00:08:34.100
And they're actually in a worse-off position where they're sort of buried with a
142
00:08:34.200 --> 00:08:37.940
sort of half-built solution and they don't have all of the features and
143
00:08:38.420 --> 00:08:43.120
requirements that they need.
So that's where a third-party orchestrator comes
144
00:08:43.160 --> 00:08:47.400
into play. And the benefit is insulation from this technical burden.
145
00:08:47.740 --> 00:08:49.220
So rather than maintaining all the data,
146
00:08:49.460 --> 00:08:51.120
rather than maintaining all the connections,
147
00:08:51.640 --> 00:08:54.280
I integrate to this third-party orchestration layer,
148
00:08:54.800 --> 00:08:57.360
and it's all of those connections are available to me.
149
00:08:57.640 --> 00:09:00.120
All of those optimization features are available to me.
150
00:09:00.480 --> 00:09:04.680
You get speed to market and this greatly reduced technical burden.
151
00:09:06.680 --> 00:09:11.320
But that also has considerations. So first and foremost,
152
00:09:11.560 --> 00:09:13.960
the data is no longer directly in your control.
153
00:09:14.680 --> 00:09:18.160
So if you need to synchronize data across multiple vaults,
154
00:09:18.480 --> 00:09:22.000
if you want to make use of those network token features, card account updater,
155
00:09:22.200 --> 00:09:25.360
you got to make sure that that orchestration provider has all of those
156
00:09:25.480 --> 00:09:28.240
capabilities. In addition to that,
157
00:09:28.640 --> 00:09:32.520
we're adding an additional layer in the transaction journey.
158
00:09:33.280 --> 00:09:36.920
So this can create more latency. So because of that additional step,
159
00:09:37.520 --> 00:09:40.960
there are added milliseconds to the end-to-end transaction flow.
So this is
160
00:09:41.040 --> 00:09:44.160
something that you need to scrutinize when evaluating a third-party
161
00:09:44.240 --> 00:09:49.160
orchestrator. And then lastly, and most importantly is reliability.
162
00:09:50.360 --> 00:09:54.520
An orchestration provider gives us optionality downstream of the orchestrator,
163
00:09:54.920 --> 00:09:57.960
but it creates concentration risk with the orchestrator themselves.
164
00:09:58.320 --> 00:10:02.520
So if the orchestrator goes down, you have a single point of failure. Thus,
165
00:10:03.000 --> 00:10:07.280
the availability of the orchestration layer is probably the most important
166
00:10:07.640 --> 00:10:12.400
component to evaluate. So in summary,
167
00:10:13.000 --> 00:10:15.880
we really have two viable paths. We can do this in-house,
168
00:10:17.200 --> 00:10:22.000
maximum control, full purview, full responsibility for the outcome,
169
00:10:22.320 --> 00:10:24.200
but at that full cost. And again,
170
00:10:24.440 --> 00:10:27.880
not just a point in time cost to stand up that connection to the new processor,
171
00:10:28.360 --> 00:10:32.320
but the ongoing cost of maintaining this more complex setup.
172
00:10:33.680 --> 00:10:37.080
And then the alternative of working with a third-party orchestration
173
00:10:37.240 --> 00:10:42.000
provider-speed to market, insulation from the technical burden, but
174
00:10:44.560 --> 00:10:49.480
a new sort of concentration risk to evaluate along with certain controls
175
00:10:49.600 --> 00:10:51.360
and features that you need to make sure you have.
176
00:10:53.600 --> 00:10:57.240
So I'm pleased to share Stripe has Orchestration.
177
00:10:58.480 --> 00:11:02.720
It's a significant investment that we're continuing to build on.
178
00:11:03.280 --> 00:11:07.520
And I think the main component that we're most excited about is it's built on
179
00:11:07.600 --> 00:11:10.360
Stripe's core infrastructure. So you heard Will,
180
00:11:11.040 --> 00:11:14.880
or maybe it was Patrick sharing that we had
181
00:11:18.990 --> 00:11:22.480
99.999%-five nines, sorry-percent uptime,
182
00:11:23.600 --> 00:11:25.080
and that applies to Orchestration.
183
00:11:25.760 --> 00:11:29.760
So that risk that we need to mitigate around single point of failure,
184
00:11:30.080 --> 00:11:32.760
Stripe is investing heavily to mitigate that.
185
00:11:33.740 --> 00:11:35.640
And in terms of portability,
186
00:11:36.380 --> 00:11:38.860
Stripe supports what we call the forwarding API.
187
00:11:39.380 --> 00:11:43.940
So you are able to extract your payment data to any endpoint that you
188
00:11:44.000 --> 00:11:46.040
require. And if it's PCI sensitive,
189
00:11:46.160 --> 00:11:48.560
that endpoint just needs to be PCI compliant,
190
00:11:48.860 --> 00:11:53.240
and new endpoints can be stood up in a very short period of time. And again,
191
00:11:53.300 --> 00:11:56.460
this all ladders up to this idea of, you're in control.
192
00:11:57.180 --> 00:12:00.680
Stripe Orchestration is an investment in a broader strategy of an open
193
00:12:00.780 --> 00:12:04.620
architecture.
You're not going to have to be locked into Stripe.
194
00:12:04.840 --> 00:12:07.200
You don't have to use every component that we have.
195
00:12:07.480 --> 00:12:10.040
It's just what you need with maximum flexibility.
196
00:12:11.520 --> 00:12:15.820
And an example here, so this is a real world business, 123cards.
197
00:12:15.940 --> 00:12:18.220
So they operate in a hundred plus countries.
198
00:12:18.480 --> 00:12:21.120
They're an online greeting card company and they've adopted Stripe
199
00:12:21.160 --> 00:12:21.993
Orchestration.
200
00:12:22.260 --> 00:12:25.920
So they were able to do this in a very short period of time with minimal
201
00:12:26.040 --> 00:12:30.800
technical infrastructural overhaul. And in about four months,
202
00:12:31.200 --> 00:12:33.840
they were able to double their dunning recovery rate,
203
00:12:34.200 --> 00:12:37.380
so their retry strategy on subscription payments,
204
00:12:37.860 --> 00:12:40.900
and it led to over $140,000 in recovered revenue.
205
00:12:41.160 --> 00:12:45.300
So this was incremental to them, and it was very material. So again,
206
00:12:45.400 --> 00:12:49.980
a proof point in what Alex was talking about earlier on having multiprocessor
207
00:12:50.240 --> 00:12:51.720
can boost revenue and conversion.
208
00:12:55.240 --> 00:12:58.450
Beyond Stripe Orchestration, we're committed to this open architecture.
209
00:12:59.470 --> 00:13:00.800
So I think you heard about it at the keynote.
210
00:13:00.870 --> 00:13:04.300
If you were able to join for the keynote, Radar is now multiprocessor.
211
00:13:04.450 --> 00:13:07.750
So you can use Radar API regardless of whether or not you're using Stripe
212
00:13:07.770 --> 00:13:08.450
Payments.
213
00:13:08.450 --> 00:13:12.950
So you can use our signals about transaction risk and apply them to transactions
214
00:13:13.010 --> 00:13:17.350
processed with other providers. Similarly, Billing and Checkout,
215
00:13:18.110 --> 00:13:22.680
the subscription management and online UX conversion optimization
216
00:13:22.750 --> 00:13:26.950
toolkit is now multiprocessor compatible.
217
00:13:27.170 --> 00:13:28.490
So it is processor agnostic.
218
00:13:28.830 --> 00:13:33.590
So you can use our subscription management tools without having to use
219
00:13:33.610 --> 00:13:35.930
Stripe Payments. Same goes for 3D Secure.
220
00:13:37.090 --> 00:13:40.630
And it's important to call out that all of these have dedicated talks here at
221
00:13:40.710 --> 00:13:44.070
Sessions. So if you are interested in learning more about any one of these,
222
00:13:44.890 --> 00:13:48.670
feel free to check out your app and look for the dedicated talk.
223
00:13:51.670 --> 00:13:56.110
So before we move on to Josh, just in summary,
224
00:13:56.250 --> 00:13:59.990
I encourage you all to think about this, take it back to your teams,
225
00:14:00.650 --> 00:14:05.630
evaluate what would the hour of downtime cost
226
00:14:05.710 --> 00:14:09.470
us, what could the optimization of multiprocessor look like?
227
00:14:10.070 --> 00:14:13.210
And then if you think this is really something that you need to pursue,
228
00:14:13.870 --> 00:14:17.790
think carefully about the trade-offs. Can we do this ourselves,
229
00:14:18.090 --> 00:14:22.750
not just for this initial investment, but on an ongoing basis? And if not,
230
00:14:22.950 --> 00:14:27.130
who's the right provider to work with? And in fact, Slalom,
231
00:14:27.270 --> 00:14:30.930
one of our partners has a booth here and they specialize in multiprocessor
232
00:14:30.970 --> 00:14:34.130
implementation. So if you're interested in carrying on the conversation further,
233
00:14:34.510 --> 00:14:38.090
stop by Slalom's booths and bring up this topic and see what they have to say.
234
00:14:40.250 --> 00:14:43.530
Okay. So with that, we will hear more about a real world journey.
235
00:14:43.650 --> 00:14:46.510
So I'm going to welcome Josh Barton from Canva up to the stage.
236
00:14:46.870 --> 00:14:50.930
Josh is global product lead and Alex is going to come back up as well to talk to
237
00:14:50.950 --> 00:14:52.510
him about Canva's journey.
238
00:14:56.510 --> 00:14:58.050
Thank you, Josh, for being here with us.
239
00:14:58.570 --> 00:14:59.403
Thanks for having me.
240
00:14:59.470 --> 00:15:02.690
Yeah, of course. I was going to complain about my six-hour flight to get here,
241
00:15:02.750 --> 00:15:05.130
but Josh is coming all the way from Australia to be with us.
242
00:15:05.290 --> 00:15:07.570
A little bit longer working hours.
243
00:15:07.770 --> 00:15:10.830
Longer, yeah. Well, we want to hear about your experience.
244
00:15:10.890 --> 00:15:13.730
We want to hear about your journey into the multiprocessor world.
245
00:15:14.830 --> 00:15:17.110
And so maybe to get started, curious about your decision.
246
00:15:17.530 --> 00:15:20.290
Why did Canva and why did you decide to go multiprosser?
247
00:15:20.870 --> 00:15:22.750
Yeah, so we did this quite some time ago,
248
00:15:22.970 --> 00:15:26.490
and I think the real reason why we did this was redundancy.
249
00:15:27.070 --> 00:15:31.270
We accept payments in over 190 countries and having
250
00:15:31.570 --> 00:15:33.690
downtime, and not just full downtime,
251
00:15:33.750 --> 00:15:38.490
but degraded performance would mean that we'd lose a lot of revenue as we saw.
252
00:15:39.130 --> 00:15:41.210
We also knew we'd get some performance benefits,
253
00:15:41.270 --> 00:15:46.250
like when you fall over and get the second PSP to get some uplift there,
254
00:15:46.770 --> 00:15:50.210
and we'd avoid the lock-in, but primarily redundancy.
255
00:15:50.570 --> 00:15:51.690
That makes sense. And then yeah,
256
00:15:51.750 --> 00:15:54.150
that seems to resonate with our audience today when we saw the poll.
257
00:15:54.530 --> 00:15:58.010
Did you actually get the benefits that you thought you were going to get?
258
00:15:58.090 --> 00:16:00.970
Yeah, we did get the good redundancy benefits.
259
00:16:01.210 --> 00:16:06.010
And the easy scenario and the boring scenario is the PSP goes completely
260
00:16:06.090 --> 00:16:10.010
down and you route around it and you go to your other PSP and you're still up.
261
00:16:10.570 --> 00:16:12.850
That's very uncommon in this day and age.
262
00:16:13.270 --> 00:16:17.590
The more interesting scenario where we really got our money's worth is the
263
00:16:17.870 --> 00:16:22.050
degraded performance. Stripe says they have five nines uptimes.
264
00:16:22.250 --> 00:16:25.410
Everyone say they do in the PSP world.
265
00:16:25.630 --> 00:16:26.520
I don't think that's true but...
266
00:16:28.110 --> 00:16:31.950
But what they don't tell you is that doesn't include degraded performance.
267
00:16:32.970 --> 00:16:37.310
If a network goes down in Mexico or if a payment method goes down
268
00:16:37.930 --> 00:16:41.730
in Indonesia, that's not included in your five-9's uptime. So
269
00:16:43.490 --> 00:16:48.470
your orchestration system allows you to compensate for those ones and have
270
00:16:48.570 --> 00:16:51.850
full performance all of the time, which is what we see. That makes sense.
271
00:16:52.040 --> 00:16:54.770
And so those were the benefits you went to Orchestration for.
272
00:16:55.190 --> 00:16:58.830
Is there any other benefits you didn't really expect that ended up
273
00:16:59.870 --> 00:17:00.703
materializing?
274
00:17:00.870 --> 00:17:04.750
Yeah. So other than redundancy, we went in thinking, yes,
275
00:17:04.810 --> 00:17:06.870
we get some performance benefits as well,
276
00:17:07.470 --> 00:17:12.150
and we thought it's going to be fallback. We try on one, it doesn't work,
277
00:17:12.210 --> 00:17:13.043
we try on another,
278
00:17:13.150 --> 00:17:17.050
and we get a few percentage points uplift or fractions of percentage uplift.
279
00:17:17.250 --> 00:17:22.130
What we didn't realize at the time was actually the real power is where you send
280
00:17:22.270 --> 00:17:26.510
the traffic the first time. So we went down this track of, okay, great,
281
00:17:26.710 --> 00:17:31.570
let's route by country. And then that gave us good uplift.
282
00:17:31.830 --> 00:17:33.870
But just when we thought we knew what we were doing,
283
00:17:34.010 --> 00:17:36.670
we realized actually country is not the real signal.
284
00:17:36.990 --> 00:17:41.010
It's going to be BIN and issuer. And then we started routing by BIN and issuer.
285
00:17:41.290 --> 00:17:42.790
And then we realized, wait a minute,
286
00:17:42.930 --> 00:17:45.810
this actually is not the real performance indicator either.
287
00:17:46.710 --> 00:17:51.290
We had to go and create separate mids in multiple PSPs.
288
00:17:51.350 --> 00:17:54.150
So you had a mid for good traffic, a mid for bad traffic,
289
00:17:54.350 --> 00:17:57.330
and then you started getting performance through there. So the honest-.
290
00:17:57.530 --> 00:18:00.490
And all the combinations and you get into the combinatorial of-.
291
00:18:00.800 --> 00:18:01.633
Yeah, exactly.
292
00:18:01.750 --> 00:18:05.970
So we started off with a redundancy system and all of a sudden we've got a full
293
00:18:06.050 --> 00:18:10.290
payments optimization solution. It's a lot of fun,
294
00:18:10.450 --> 00:18:13.410
but it's a lot more difficult than what you think it's going to be.
295
00:18:13.870 --> 00:18:15.690
Let's talk about how you went about in doing it.
296
00:18:15.910 --> 00:18:18.210
So I think you built a system completely in-house, right?
297
00:18:19.690 --> 00:18:21.950
Any challenges that you faced when you did that or?
298
00:18:22.330 --> 00:18:25.650
Yeah, that's correct. So like most startups in this room,
299
00:18:25.710 --> 00:18:29.240
we started off with Stripe and we've been with Stripe for I think close to 10
300
00:18:29.530 --> 00:18:32.270
years now and they've been a great partner,
301
00:18:33.430 --> 00:18:35.850
but we got to a point where we were like, we're doing,
302
00:18:37.150 --> 00:18:40.690
95% of our payments were card payments.
303
00:18:41.170 --> 00:18:42.350
So our first,
304
00:18:43.570 --> 00:18:47.910
we thought we need a second PSP that's specializing in card payments because we
305
00:18:47.970 --> 00:18:51.370
want that redundancy. So we'd put that in. And again,
306
00:18:51.430 --> 00:18:54.430
we didn't think we had an orchestration system yet because it was just two.
307
00:18:55.410 --> 00:18:59.810
It's really when we put the third PSP in that we started to think,
308
00:19:00.810 --> 00:19:01.130
hold on,
309
00:19:01.130 --> 00:19:04.890
we need some more sophisticated logic here because it's not only just fallback
310
00:19:04.950 --> 00:19:07.310
anymore, it's how do I route it around?
311
00:19:07.570 --> 00:19:10.530
And that's when our orchestration system was kind of born.
312
00:19:11.750 --> 00:19:12.690
In terms of challenges,
313
00:19:13.190 --> 00:19:17.170
there's quite a lot of them that you don't think of at the time.
314
00:19:18.130 --> 00:19:19.010
As John mentioned,
315
00:19:19.590 --> 00:19:24.290
it takes maybe six months or more to integrate a new PSP and that's engineering
316
00:19:24.330 --> 00:19:24.670
time.
317
00:19:24.670 --> 00:19:26.090
We have fast teams here. Yeah.
318
00:19:26.370 --> 00:19:30.870
Very fast, yes. And that's the engineering time that you're thinking about.
319
00:19:30.930 --> 00:19:34.770
But what you don't think about and what you don't put on your timelines is all
320
00:19:34.790 --> 00:19:36.650
the commercials that you're going to have to do with the new PSP,
321
00:19:36.960 --> 00:19:40.150
like you're going to have to negotiate contracts, do your KYC,
322
00:19:41.230 --> 00:19:44.130
this that and the other to get to even get you to the started.
323
00:19:44.590 --> 00:19:45.670
Then you do the engineering.
324
00:19:46.590 --> 00:19:50.510
Then what they also don't tell you is you need warm up time when you have
325
00:19:51.130 --> 00:19:52.910
finally started with the-.
326
00:19:52.910 --> 00:19:53.310
The new mid.
327
00:19:53.650 --> 00:19:55.230
A new mid, yes, exactly.
328
00:19:55.290 --> 00:20:00.190
So you're spending three plus months warming up and then after the warm-up time,
329
00:20:00.470 --> 00:20:05.150
you need to start tuning the settings in the PSP and in your own system
330
00:20:05.910 --> 00:20:08.150
before you get that optimized performance.
331
00:20:09.150 --> 00:20:13.010
So when you were saying six months there, it's six months engineering time,
332
00:20:13.130 --> 00:20:17.850
but you end up a lot more than that.
And finally,
333
00:20:18.910 --> 00:20:23.110
the other thing that no one thinks about is all of a sudden when you're doing
334
00:20:23.590 --> 00:20:25.570
chargebacks or you're doing refunds,
335
00:20:26.550 --> 00:20:29.470
your operations team now has to go into a second portal.
336
00:20:30.430 --> 00:20:33.890
So you've got context switching there. Yeah,
337
00:20:34.170 --> 00:20:37.250
it's all the things that no one tells you about before you get started.
338
00:20:37.410 --> 00:20:38.410
Yeah, no, that makes a lot of sense.
339
00:20:38.470 --> 00:20:41.310
And I think we see it on our site too with the customers we work with,
340
00:20:41.790 --> 00:20:45.370
they always take much longer than they think they will. They're like, "Oh yeah,
341
00:20:45.430 --> 00:20:47.690
I want to integrate on Stripe Orchestration, but wait,
342
00:20:47.790 --> 00:20:49.370
I need to work my contract with my,
343
00:20:49.450 --> 00:20:52.830
and my compliance team hasn't agreed to it." And so we see that a lot as well.
344
00:20:53.670 --> 00:20:57.470
Maybe can you give us a sense of the sort of resources you'd had to allocate to
345
00:20:58.010 --> 00:21:02.710
this kind of project sort of reality of the teams that engineering
346
00:21:02.970 --> 00:21:03.370
effort-.
347
00:21:03.370 --> 00:21:06.710
Yeah, we have a lot of people in our payments team at Canva
348
00:21:08.770 --> 00:21:12.190
close to, I mean, once you start including operational people,
349
00:21:13.070 --> 00:21:16.070
it's close to 30 people just working on this.
350
00:21:16.230 --> 00:21:19.490
So it's not a cheap, easy fix to do.
351
00:21:20.530 --> 00:21:21.890
It's something you have to commit yourself to.
352
00:21:22.210 --> 00:21:24.710
And you have to think about the ROI of those resources,
353
00:21:24.910 --> 00:21:27.870
what else could they be deployed to? And that's not always easy to-.
354
00:21:27.990 --> 00:21:32.150
Exactly. Exactly. So there's cost to all of this.
355
00:21:32.330 --> 00:21:36.190
So got to stack it up with your revenues.
356
00:21:36.310 --> 00:21:38.890
Or you think about integrating an orchestrator, right?
357
00:21:38.950 --> 00:21:43.650
And I think you are starting to think about that potentially on your side and
358
00:21:43.850 --> 00:21:46.090
what are the consideration as you're thinking about working with an
359
00:21:46.110 --> 00:21:46.943
orchestrator?
360
00:21:46.950 --> 00:21:47.470
Yeah.
361
00:21:47.470 --> 00:21:51.110
So to put in context of what we are doing and what we're thinking about doing
362
00:21:51.190 --> 00:21:51.330
is,
363
00:21:51.330 --> 00:21:54.870
so we've got our home-built orchestration platform that we're very happy with.
364
00:21:55.630 --> 00:21:56.950
We're not looking to go away from that,
365
00:21:57.110 --> 00:22:00.990
but we want to put a parallel stack beside it where we have a parallel
366
00:22:01.110 --> 00:22:04.730
orchestrator where that six months engineering time, we get rid of it.
367
00:22:04.910 --> 00:22:07.830
We know we're going to still keep the tuning time, this and the other,
368
00:22:08.210 --> 00:22:13.190
but we wanted that parallel stack there where we can test a PSP or test a PSP
369
00:22:13.370 --> 00:22:18.290
on a smaller niche market where maybe the revenue doesn't stack up when we
370
00:22:18.370 --> 00:22:19.410
look at that ROI.
371
00:22:20.210 --> 00:22:24.730
So when we're looking for that orchestration platform,
372
00:22:24.790 --> 00:22:29.210
that external one, there's a few things that come to mind. One, reliability.
373
00:22:30.170 --> 00:22:32.550
You don't want to add another point of failure in there.
374
00:22:32.930 --> 00:22:36.110
So if they don't have the five nines uptime that Stripe does,
375
00:22:37.050 --> 00:22:41.690
all of a sudden you're bringing Stripes up time down because the
376
00:22:42.110 --> 00:22:45.970
orchestrator's how you get there. So you've got to think of that. Also,
377
00:22:46.570 --> 00:22:51.190
a lot of orchestrators out there will tell you they connect to 400 PSPs,
378
00:22:51.690 --> 00:22:54.950
but no one's going to use 400 PSPs.
379
00:22:57.170 --> 00:23:01.730
It's all about the quality of the integration to the PSPs
380
00:23:02.630 --> 00:23:07.490
and depth of that integration rather than the breadth of integrations that they
381
00:23:07.550 --> 00:23:11.950
have. I know we've integrated, we have five PSPs that we've integrated to,
382
00:23:12.570 --> 00:23:15.930
and different integration levels get you different performance.
383
00:23:16.210 --> 00:23:20.790
So make sure you have the best possible integration to the PSP that you want to
384
00:23:20.930 --> 00:23:24.150
use. And then of course, predictability.
385
00:23:25.690 --> 00:23:28.030
When you're choosing a partner, especially in payments,
386
00:23:28.270 --> 00:23:32.630
you want to know that what you see is what you get. Are their documents correct?
387
00:23:34.670 --> 00:23:35.610
When are they going to settle?
388
00:23:36.090 --> 00:23:38.490
There's all of these things that they're going to promise you.
389
00:23:38.610 --> 00:23:40.190
You've got to make sure I trust them,
390
00:23:40.550 --> 00:23:44.510
it's going to be predictable because payments is working with customers money.
391
00:23:45.490 --> 00:23:48.070
It's very sensitive and we've got to get that right.
392
00:23:48.850 --> 00:23:52.330
And it sounds like you're thinking about an orchestration solution also as a way
393
00:23:52.350 --> 00:23:56.130
to sort of quickly test versus the investment of building the entire gradation
394
00:23:56.150 --> 00:23:59.890
yourself and maybe eventually getting there depending on the results you're
395
00:23:59.930 --> 00:24:04.630
seeing from that test. And yeah, that makes sense. Great. Well,
396
00:24:05.270 --> 00:24:09.550
Josh, you have a lot of people here in the room who are on this journey.
397
00:24:10.030 --> 00:24:12.310
They're thinking about it. Maybe some of them have started.
398
00:24:13.290 --> 00:24:15.550
If you were sitting in that audience today,
399
00:24:15.630 --> 00:24:18.130
what would you want to hear from you?
400
00:24:18.890 --> 00:24:23.070
I think firstly, it's worth it, so do it. You're going to think at times,
401
00:24:23.130 --> 00:24:23.890
this is horrible.
402
00:24:23.890 --> 00:24:28.390
I should just go back to one PSP because the engineering resources is a
403
00:24:28.470 --> 00:24:29.303
nightmare,
404
00:24:29.530 --> 00:24:33.810
or the operational resources are a nightmare as well.
405
00:24:34.730 --> 00:24:37.310
But at the end of the day, you look back and
406
00:24:38.930 --> 00:24:42.790
you have a look at the uplift, and that uplift is, wow, really?
407
00:24:42.970 --> 00:24:44.950
So it is worth doing. Don't give up.
408
00:24:46.530 --> 00:24:51.010
But also really take the time to develop good
409
00:24:51.150 --> 00:24:56.010
partnerships with your PSPs and don't be flippant about adding ones in and
410
00:24:56.210 --> 00:25:00.810
out. We've found the best performance have come with working with our PSPs like
411
00:25:00.850 --> 00:25:05.590
Stripe over a long time, over many years to get that really,
412
00:25:05.770 --> 00:25:09.110
really good performance from them. As I mentioned earlier,
413
00:25:09.210 --> 00:25:12.770
it's not just turn a PSP on and you expect best performance from them.
414
00:25:13.810 --> 00:25:17.350
It's not going to happen.
You will get good performance after the three months
415
00:25:17.430 --> 00:25:20.690
warm-up of your mid and then maybe another three months on tuning it,
416
00:25:21.090 --> 00:25:25.410
but it really comes in the years to come when you're working with your PSP
417
00:25:25.630 --> 00:25:28.550
closely, that's when you get the best performance out of them.
418
00:25:29.270 --> 00:25:32.350
Great. Well, Josh, thank you so much for joining us.
419
00:25:32.930 --> 00:25:36.590
Safe travel back to Australia.
Thanks to all of you for joining us today.
420
00:25:36.950 --> 00:25:38.830
Have a wonderful time at Stripe Sessions.
421
00:25:39.190 --> 00:25:41.250
If you're curious about any of the things we talked about today,
422
00:25:41.310 --> 00:25:44.990
you can also go to the payment optimization booth for Stripe and the expo hall.
423
00:25:45.230 --> 00:25:46.190
So thank you so much.