WEBVTT 1 00:00:09.680 --> 00:00:11.400 Hello everyone. Thanks for coming to this talk, 2 00:00:12.220 --> 00:00:15.480 "Architecting multiparty premium flows." And my name is Javier, 3 00:00:15.980 --> 00:00:20.220 and I'm a solutions architect at Stripe. If this talk is successful, 4 00:00:20.420 --> 00:00:25.360 today you will get four key framework areas so 5 00:00:25.480 --> 00:00:28.740 you can think about how to architect those multiparty payment flows. 6 00:00:30.780 --> 00:00:34.540 But to do this, I want you to have a quick of an example. 7 00:00:35.700 --> 00:00:38.540 There is a company called, a fictional company called CreatorCamp. 8 00:00:39.180 --> 00:00:43.740 They sell courses that they create and their customers 9 00:00:44.500 --> 00:00:49.080 subscribe to those courses for $20 and consume them. Kind of like a boring, 10 00:00:49.460 --> 00:00:50.293 simple use case. 11 00:00:52.340 --> 00:00:54.700 But things have to evolve, 12 00:00:54.900 --> 00:00:57.900 and the company wants to grow a little bit more. 13 00:00:58.260 --> 00:01:02.720 So the business team decided that they wanted to become a marketplace and offer 14 00:01:02.780 --> 00:01:06.420 their own software to other creators who want to join the company. 15 00:01:07.220 --> 00:01:10.240 So how [will] they work? Well, they said from the $20, 16 00:01:10.980 --> 00:01:15.140 we can get 15% for us as a CreatorCamp company, 17 00:01:15.800 --> 00:01:18.940 and the rest we can give it to the creators. Seems fine, right? 18 00:01:19.720 --> 00:01:22.700 They gave those requirements to the developer team and they said, "Well, 19 00:01:22.800 --> 00:01:26.460 we can do this in around two days." They shipped it, 20 00:01:27.220 --> 00:01:31.240 and it exploded. It was really nice. Everyone was starting to use it. 21 00:01:32.500 --> 00:01:37.320 But things started to be a little bit problematic because they just 22 00:01:37.340 --> 00:01:40.800 divided the amount without thinking a lot of different things that you have to 23 00:01:40.840 --> 00:01:42.420 keep in mind when you are building a marketplace. 24 00:01:43.160 --> 00:01:47.400 So things like the payouts were failing, the FX cost was piling. 25 00:01:47.480 --> 00:01:49.160 And if you know more or less this, 26 00:01:49.560 --> 00:01:54.140 FX is the exchange conversion between two currencies and that was eating their 27 00:01:54.160 --> 00:01:54.880 margin. 28 00:01:54.880 --> 00:01:59.120 And then the owner of the funds sometimes wasn't really clear who was the owner 29 00:01:59.140 --> 00:02:02.300 of those funds. And regarding the files and reconciliation, 30 00:02:02.460 --> 00:02:07.280 they have like a 500 megabyte Excel file that they weren't able to 31 00:02:07.340 --> 00:02:11.580 reconcile. And things failed not because of the load, 32 00:02:11.740 --> 00:02:16.480 not because of the bags. It failed because they didn't ask four key questions. 33 00:02:18.380 --> 00:02:19.213 The first one: 34 00:02:19.340 --> 00:02:23.000 how your business is and how is it evolving with the new requirements? 35 00:02:23.920 --> 00:02:24.753 Second one: 36 00:02:25.420 --> 00:02:29.640 who is legally responsible for the funds and in case of refunds or disputes, 37 00:02:30.160 --> 00:02:34.740 who actually has to take care of it? Regarding the FX, 38 00:02:35.520 --> 00:02:39.420 what's the FX of the transactions, how those are implying my business, 39 00:02:39.920 --> 00:02:44.040 and how these FX will aid my margins? And finally, 40 00:02:44.680 --> 00:02:48.440 where the money sits-where is it guardrailed so I can distribute it? 41 00:02:49.800 --> 00:02:52.380 So today with the framework that I will give you, 42 00:02:52.780 --> 00:02:56.500 you will be able to answer all these questions in the right way and make the 43 00:02:56.580 --> 00:03:01.420 right decisions. Let's get started with the first one. And it's, 44 00:03:01.880 --> 00:03:05.480 what is my business actually? What am I building? Remember, 45 00:03:05.540 --> 00:03:08.120 CreatorCamp was just a simple business with a subscription. 46 00:03:09.020 --> 00:03:12.640 Certainly they evolved to a marketplace and they didn't think about it. 47 00:03:12.840 --> 00:03:16.340 You have to take care of FX, you have to take care of the KYC, 48 00:03:17.580 --> 00:03:20.280 liability, lots of different things. Typically, 49 00:03:20.620 --> 00:03:24.280 we're talking about Connect when it comes to model this into Stripe. 50 00:03:25.020 --> 00:03:26.560 And so in Connect, 51 00:03:26.960 --> 00:03:30.420 there are certain things that you need to keep in mind depending on the kind of 52 00:03:30.460 --> 00:03:31.360 business that you're building. 53 00:03:31.480 --> 00:03:35.180 If you're a SaaS platform like is the case of Shopify, Mindbody, 54 00:03:35.900 --> 00:03:39.300 usually the merchant of record. And just quick pause here, 55 00:03:39.420 --> 00:03:43.340 the merchant of record is in the names of Stripe, who is in the descriptor, 56 00:03:43.500 --> 00:03:45.680 like who figures in the descriptor of the transaction, 57 00:03:46.160 --> 00:03:50.960 but also it implies where the money is landing and what payment 58 00:03:50.980 --> 00:03:55.940 methods are available. So the merchant of record will be the connected account, 59 00:03:56.460 --> 00:03:59.580 the seller, the creator in this case. Typically, 60 00:03:59.680 --> 00:04:03.920 also they are offering software and services and they monetize through 61 00:04:04.100 --> 00:04:06.680 application fees and external subscriptions as well. 62 00:04:07.580 --> 00:04:09.960 But if you are building a marketplace, that's a little bit different. 63 00:04:10.860 --> 00:04:14.860 The front of the marketplace usually is the brand of the marketplace itself. 64 00:04:15.740 --> 00:04:19.100 So the way they earn money is by demand generation. 65 00:04:19.280 --> 00:04:22.880 They get a lot of customers and take a little bit of a fee for every 66 00:04:22.920 --> 00:04:23.753 transaction, 67 00:04:23.920 --> 00:04:28.040 getting that way the right amount of money for their business. 68 00:04:30.300 --> 00:04:34.300 And I'm saying that we are modeling this with Connect. In the Connect world, 69 00:04:34.500 --> 00:04:39.080 the platform is CreatorCamp and the connected accounts are the 70 00:04:39.660 --> 00:04:43.380 connected accounts. Sorry, the creators. So there, 71 00:04:43.980 --> 00:04:48.620 what happens is what we are modeling here is how these roles interact 72 00:04:48.680 --> 00:04:52.600 together between the platform and the connected accounts and all the hidden 73 00:04:52.680 --> 00:04:54.840 trades that are in this business model. 74 00:04:56.640 --> 00:05:01.040 First lesson I want you to take away from here is that the fund flows are your 75 00:05:01.100 --> 00:05:05.440 business model. They represent exactly what your business model is. 76 00:05:05.940 --> 00:05:10.680 So it's not just a minor detail regarding how money moves in your 77 00:05:10.840 --> 00:05:14.660 last mile. OK. Let's go to the second part. 78 00:05:15.480 --> 00:05:18.040 And this is all about the traits. If you're familiar with Connect, 79 00:05:18.480 --> 00:05:22.160 they used to have types like Standard, Express, Custom. 80 00:05:22.840 --> 00:05:25.420 We changed this a little bit like past year. 81 00:05:26.000 --> 00:05:30.640 And what you have now is traits. Those traits are the Dashboard. 82 00:05:30.800 --> 00:05:32.440 So what is the UI, 83 00:05:32.580 --> 00:05:36.040 the representation that you are giving to your connected accounts and the 84 00:05:36.060 --> 00:05:39.720 experience they have, which can be full, express, or none, 85 00:05:40.140 --> 00:05:42.120 depending on how white-label you want to build. 86 00:05:42.720 --> 00:05:44.420 The second one is the economic model, 87 00:05:45.000 --> 00:05:48.660 which determines who is paying the fees to Stripe. 88 00:05:49.380 --> 00:05:52.960 And the third one, and this is the one I want you to pay a special attention, 89 00:05:53.340 --> 00:05:58.180 is merchant risk management represented by the losses_collector property 90 00:05:58.440 --> 00:05:59.273 in the API. 91 00:06:00.680 --> 00:06:03.460 And here it could be Stripe or application. 92 00:06:04.260 --> 00:06:07.860 And this is important because liability gates the fund flows that you can 93 00:06:07.920 --> 00:06:12.840 currently use. If you use Stripe, that's Stripe Managed Risk. 94 00:06:13.060 --> 00:06:17.580 You're delegating your risk transaction for the transaction risk, 95 00:06:17.640 --> 00:06:19.640 and you're delegating also the merchant risk. 96 00:06:20.700 --> 00:06:24.820 If you choose to use application, you're getting all that responsibility. 97 00:06:25.240 --> 00:06:28.580 And that means also designing refunds and dispute fund flows. 98 00:06:30.760 --> 00:06:33.360 So here is the second lesson I want you to take away today: 99 00:06:34.030 --> 00:06:38.400 liability gates your fund flows. So pick it first, not last. 100 00:06:40.200 --> 00:06:44.600 OK. Let's go to the third part of the framework. It's geography. 101 00:06:45.400 --> 00:06:46.680 When you're building a company, 102 00:06:46.920 --> 00:06:49.720 usually you have an actual business in one place, 103 00:06:50.160 --> 00:06:53.320 but sometimes you have to expand to other places and have it there. 104 00:06:53.800 --> 00:06:56.240 So when it comes to a marketplace or a platform, 105 00:06:56.440 --> 00:06:59.720 you need to decide how the money moves and where it lands, 106 00:07:00.000 --> 00:07:02.680 depending on how your business is. Option A, 107 00:07:03.280 --> 00:07:07.360 you have a company with a single place that sells globally. That's fine, 108 00:07:07.520 --> 00:07:08.680 but you have another option, 109 00:07:08.800 --> 00:07:13.320 which is having one company in every place and creating a marketplace or a 110 00:07:13.400 --> 00:07:17.000 platform in that specific place. Choosing one or another, 111 00:07:17.240 --> 00:07:20.000 it really depends on the needs that you have as a business, 112 00:07:20.520 --> 00:07:25.520 and it all comes down to operational cost and transaction cost. If 113 00:07:25.600 --> 00:07:28.040 you have many places where you're operating, 114 00:07:28.200 --> 00:07:31.400 you have extra operating costs at the cost of transaction. While, 115 00:07:31.600 --> 00:07:33.160 if you are selling globally, 116 00:07:33.440 --> 00:07:37.200 you may have more FX cost and more cross-border cost. 117 00:07:37.680 --> 00:07:42.320 So you have to choose wisely. In the case of CreatorCamp, 118 00:07:42.320 --> 00:07:43.113 they were starting, 119 00:07:43.360 --> 00:07:47.800 so they have just a single platform in the US in this case, 120 00:07:47.960 --> 00:07:49.560 and they are selling everything globally. 121 00:07:51.480 --> 00:07:53.800 So here's the third lesson for today: 122 00:07:54.520 --> 00:07:56.880 architecture constrains your geographic scale. 123 00:07:57.680 --> 00:07:59.760 It's not that there is no demand in those places, 124 00:08:00.000 --> 00:08:04.480 but it's just the architecture wasn't designed to be able to consume those 125 00:08:04.600 --> 00:08:07.840 demands. So make sure that whatever you are designing, 126 00:08:08.160 --> 00:08:10.920 you are creating those right fund flows, 127 00:08:11.120 --> 00:08:15.320 or at least you make them extensible. OK. 128 00:08:15.600 --> 00:08:16.840 So with these three things, 129 00:08:17.160 --> 00:08:19.840 we are able already to create our connected accounts. 130 00:08:20.200 --> 00:08:22.240 And the connected accounts, nowadays, 131 00:08:22.760 --> 00:08:27.600 we recommend to create them in the v2 APIs. This is our v2 API, 132 00:08:27.800 --> 00:08:31.280 but especially I want you to pay attention to the default responsibilities, 133 00:08:31.600 --> 00:08:33.920 which define exactly the traits that we saw before. 134 00:08:34.280 --> 00:08:37.880 This is what CreatorCamp selected. So fees_collector, the platform, 135 00:08:38.320 --> 00:08:42.360 liability on Stripe, and the Dashboard being "none." 136 00:08:45.200 --> 00:08:48.100 And now we want to onboard those connected accounts. So to do so, 137 00:08:48.240 --> 00:08:51.340 we have to use two APIs. The first one is the account sessions, 138 00:08:51.660 --> 00:08:56.260 which unlocks a client secret that you can pass to the frontend to build 139 00:08:56.600 --> 00:08:58.960 your components. And because they wanted to have 140 00:09:01.080 --> 00:09:02.320 white-labeled experience, 141 00:09:02.800 --> 00:09:07.760 what they did is create an onboarding component and passing the client secret 142 00:09:08.060 --> 00:09:11.400 to that onboarding component to allow people to onboard. 143 00:09:11.760 --> 00:09:15.680 The great thing about those components is that we take care of updating them. 144 00:09:16.060 --> 00:09:20.340 So whenever the regulation changes, we will take care of the KYC screening, 145 00:09:20.800 --> 00:09:24.660 the AML, and everything that is required to make sure that it's compliant. 146 00:09:27.740 --> 00:09:29.700 And now we come to the actual fund flows. 147 00:09:29.860 --> 00:09:31.860 That's what we try to understand in here. 148 00:09:31.960 --> 00:09:36.380 So those arrows and how they interact between each other is what the fund flows 149 00:09:36.740 --> 00:09:39.220 are about. To do that, 150 00:09:39.540 --> 00:09:41.900 we're going to have four different requirements, 151 00:09:41.920 --> 00:09:46.180 and we will evolve those requirements so you can fully understand when it makes 152 00:09:46.200 --> 00:09:50.760 sense to pick one or another. So let's get started with direct charges. 153 00:09:51.960 --> 00:09:54.800 Direct charges make the platform, sorry, 154 00:09:54.860 --> 00:09:56.720 the connected account the merchant of record. 155 00:09:57.840 --> 00:10:01.420 But let's understand what are the requirements that right now they have. 156 00:10:02.400 --> 00:10:05.400 They have a single transaction, they have a seller, 157 00:10:06.160 --> 00:10:10.500 so the buyer wants to pay directly for a course. In these kinds of situations, 158 00:10:11.060 --> 00:10:14.200 it's just the money landing directly to this connected account, 159 00:10:14.460 --> 00:10:17.640 so the creator. So let's just see how the fund flow goes. 160 00:10:18.740 --> 00:10:23.340 We have a PaymentIntel with $100, which goes directly to the connected account. 161 00:10:23.340 --> 00:10:25.500 It creates a charge and it goes to the balance. 162 00:10:26.100 --> 00:10:29.640 But now the platform wants to keep that application fee that we mentioned 163 00:10:29.660 --> 00:10:31.180 before. So for that, 164 00:10:31.540 --> 00:10:35.640 a platform fee is created and it's transferred to the platform straight away. 165 00:10:36.160 --> 00:10:38.480 In this case, because the application is paying the fees, 166 00:10:38.920 --> 00:10:42.060 the fees from Stripe are charged to the platform directly. 167 00:10:44.640 --> 00:10:48.340 How does it work on the API? Well, it's just a payment intent API. 168 00:10:48.460 --> 00:10:49.293 You already know this. 169 00:10:49.700 --> 00:10:54.080 So you have a Stripe account header and you have the application_fee_amount. 170 00:10:54.500 --> 00:10:57.820 Those two things are defined in it. But keep in mind one thing. 171 00:10:58.300 --> 00:11:01.080 The Stripe account, when you are using that header, 172 00:11:01.300 --> 00:11:05.140 every object is creating the connected account. So payment methods, customers, 173 00:11:05.460 --> 00:11:07.920 the payment itself is created on the connected account. 174 00:11:08.460 --> 00:11:10.320 And because the connected account is the merchant of record, 175 00:11:10.560 --> 00:11:13.120 we're using the currency of the connected account, 176 00:11:13.660 --> 00:11:16.710 and also we're landing those fees and, sorry, 177 00:11:16.770 --> 00:11:18.350 those charges on the connected account. 178 00:11:20.130 --> 00:11:24.910 Use these direct charges as the easiest payment flow that you can 179 00:11:24.990 --> 00:11:29.890 have. And many of the companies still remain in this kind of flow for years, 180 00:11:29.950 --> 00:11:33.590 and it's perfectly fine. But if you start evolving your requirements, 181 00:11:33.770 --> 00:11:36.890 you may do some changes. So here it goes. 182 00:11:36.970 --> 00:11:40.850 The business team just comes here and decides that they want to have a little 183 00:11:40.870 --> 00:11:43.930 bit more touch with the end customer, right? So to do that, 184 00:11:44.330 --> 00:11:49.130 they want to offer a buyer protection to those end customers. 185 00:11:50.550 --> 00:11:54.730 That buyer protection means that the losses_collector liability might be more on 186 00:11:54.750 --> 00:11:56.630 the platform and not on the connected account. 187 00:11:57.010 --> 00:12:00.670 So that's the first change we have to do. But in terms of the fund flow itself, 188 00:12:01.130 --> 00:12:05.800 it's called destination charge. Let's look how the money moves. So in this case, 189 00:12:05.870 --> 00:12:06.770 in destination charges, 190 00:12:07.180 --> 00:12:09.490 the platform is the merchant of record of the transaction. 191 00:12:10.050 --> 00:12:12.670 And the $100 move to the platform, 192 00:12:13.290 --> 00:12:17.650 creates the fee that is charged from Stripe, and at the end, leaves the balance. 193 00:12:18.300 --> 00:12:21.490 After that, we have a transfer directly and atomically, 194 00:12:21.590 --> 00:12:23.300 and this is very important to the connected account. 195 00:12:23.850 --> 00:12:26.770 Destination charges is an atomic operation. 196 00:12:26.770 --> 00:12:30.670 It defines where the charge is created and where it 197 00:12:30.790 --> 00:12:34.290 lands later on. Once the transfer is done, 198 00:12:35.010 --> 00:12:39.610 we create a platform fee and this automatically goes to the platform given 199 00:12:39.770 --> 00:12:43.290 exactly the amount that the platform is earning. API-wise, 200 00:12:44.730 --> 00:12:46.230 it's pretty much the same as we had before, 201 00:12:46.450 --> 00:12:49.470 but without the Stripe account header. 202 00:12:50.270 --> 00:12:53.210 We're adding also the transfer_data_[destination], 203 00:12:53.930 --> 00:12:56.680 which defines what is the connected account where money is landing. 204 00:12:57.590 --> 00:13:01.570 Use this one when you want to control the relationship of the transactions while 205 00:13:01.800 --> 00:13:06.050 only having a single receptor for the transaction itself. 206 00:13:06.270 --> 00:13:10.530 So it's of course still a buyer sending the money to a connected account. 207 00:13:12.550 --> 00:13:13.350 OK. 208 00:13:13.350 --> 00:13:17.670 As this keeps evolving and it gets a lot of traction, 209 00:13:18.130 --> 00:13:21.910 people from different places in the world want to start using the platform. 210 00:13:22.300 --> 00:13:23.790 So in this case, 211 00:13:24.470 --> 00:13:28.920 someone from Germany who operates in euros has 8,000 212 00:13:29.150 --> 00:13:31.150 subscribers that they want to onboard, 213 00:13:31.510 --> 00:13:35.710 but they are not accepting the FX that can happen in this. 214 00:13:36.450 --> 00:13:39.810 And with destination charges, this is the flow exactly that we saw before. 215 00:13:40.250 --> 00:13:44.890 If you present in dollars and the customer pays in dollars, 216 00:13:45.490 --> 00:13:49.030 there might be two FX, one for the payment on the presentment currency, 217 00:13:49.290 --> 00:13:52.570 and one for the transfer. There are two ways to resolve this. 218 00:13:52.970 --> 00:13:54.710 One is called multicurrency settlement, 219 00:13:55.150 --> 00:13:59.070 which basically allows the platform to have multiple balances in different 220 00:13:59.090 --> 00:14:03.070 currencies. In this case, they could have one in euro and one in dollar. 221 00:14:03.950 --> 00:14:07.190 But here, we want to touch on another option that we have, 222 00:14:07.370 --> 00:14:09.170 and it's called on_behalf_of. 223 00:14:11.150 --> 00:14:12.430 So in this kind of fund flows, 224 00:14:12.550 --> 00:14:16.250 what happens is we're making the connected account the merchant of record. 225 00:14:16.630 --> 00:14:17.430 And remember, 226 00:14:17.430 --> 00:14:21.210 being the merchant of record means as well that the funds are landing in the 227 00:14:21.290 --> 00:14:24.050 country of the merchant of record. So in this case, 228 00:14:24.450 --> 00:14:27.670 funds are being a straightaway landing in Germany. 229 00:14:28.370 --> 00:14:32.910 That means that we can charge euros and send euros or have euros in Germany 230 00:14:33.310 --> 00:14:34.143 straight away. 231 00:14:34.350 --> 00:14:37.830 The only gotcha here is the platform will have an application fee as well in 232 00:14:37.910 --> 00:14:41.790 euros. So they may end up with two balances, one in dollars and one in euros. 233 00:14:42.230 --> 00:14:45.870 In this case, what can the platform do? They can have two bank accounts, 234 00:14:46.050 --> 00:14:48.410 one in dollar, one in euros, and get them paid out. 235 00:14:48.770 --> 00:14:51.170 And if they don't want to have a bank account in euros, 236 00:14:51.570 --> 00:14:55.170 they can also convert and send to their bank account straight away. 237 00:14:55.170 --> 00:14:58.470 You can use this whenever it makes sense the connected account is the merchant 238 00:14:58.490 --> 00:15:01.990 of record. API-wise, 239 00:15:02.490 --> 00:15:06.990 if you looked at the destination charge API, it's pretty much the same, 240 00:15:07.430 --> 00:15:10.010 but we are adding the on_behalf_of 241 00:15:11.510 --> 00:15:14.650 property into the transaction. One gotcha here. 242 00:15:15.270 --> 00:15:20.110 You can't have an on_behalf_of for one connected account while having the 243 00:15:20.310 --> 00:15:22.310 transfer destination to another connected account, 244 00:15:22.990 --> 00:15:24.370 because that will be a little bit strange, 245 00:15:24.730 --> 00:15:28.210 making someone liable for the transaction while at the same time the money is 246 00:15:28.250 --> 00:15:32.310 landing somewhere else, and we don't allow it. OK. 247 00:15:33.230 --> 00:15:37.670 Let's go to the fourth requirement that came to CreatorCamp. And this is, 248 00:15:38.390 --> 00:15:39.590 we want to create bundles. 249 00:15:40.410 --> 00:15:45.010 We want to be able to sell things that come from multiple sellers. 250 00:15:45.590 --> 00:15:50.490 So in this case, a bundle could be a masterclass from Creator One or Creator A. 251 00:15:51.350 --> 00:15:54.470 It could be a tutorial series from Creator C. 252 00:15:55.670 --> 00:15:59.850 Or even we can have a brush pack that needs to be uploaded and created directly 253 00:16:00.230 --> 00:16:02.150 from Creator B. In this case, 254 00:16:02.270 --> 00:16:06.950 there might be a delay between the time you do the transaction and the time you 255 00:16:07.030 --> 00:16:08.830 want to transfer to that connected account. 256 00:16:09.590 --> 00:16:12.870 So we can't use all the charges that we saw before. 257 00:16:13.270 --> 00:16:17.910 The way to do this is separate charges and transfers. So if you look this, 258 00:16:18.090 --> 00:16:20.730 it's similar to what happened with destination charges. 259 00:16:21.290 --> 00:16:24.550 Money lands directly on the platform and the merchant of record is the platform, 260 00:16:25.210 --> 00:16:26.470 but there is no transfer. 261 00:16:26.530 --> 00:16:30.370 This is not an atomic operation as it used to happen in destination charges. 262 00:16:31.170 --> 00:16:32.370 It needs to be scheduled. 263 00:16:32.710 --> 00:16:37.270 So the way you do this is by executing a call to the v1 transfer API, 264 00:16:37.650 --> 00:16:40.550 which will transfer the amount exactly that you want to transfer to the 265 00:16:40.590 --> 00:16:42.610 connected account. But keep in mind here, 266 00:16:42.670 --> 00:16:44.430 there are no application fees as it is. 267 00:16:45.430 --> 00:16:48.430 All the money that is landing is exactly what you sent. 268 00:16:48.430 --> 00:16:50.070 So that part of the ledger is lost. 269 00:16:53.030 --> 00:16:56.410 API-wise is a little bit different. We are still using the PaymentIntent, 270 00:16:56.810 --> 00:17:00.470 but we are adding a transfer group property called a transfer_group, 271 00:17:00.910 --> 00:17:04.090 and you can pass there a name, for example, the order ID. 272 00:17:06.270 --> 00:17:10.570 And at the same time, we're creating two other API calls, 273 00:17:10.850 --> 00:17:12.830 one for one transfer and one for another, 274 00:17:13.170 --> 00:17:15.430 depending on when you want to execute those transfers, 275 00:17:15.750 --> 00:17:19.690 the responsibility to do those executions is on your side. So at the end, 276 00:17:19.950 --> 00:17:23.570 you have to decide when that happens based on your own business rules. 277 00:17:24.470 --> 00:17:28.390 Use this whenever you have multiseller or delayed transactions. 278 00:17:32.790 --> 00:17:35.810 OK, but we came here to see a little bit of architecture. 279 00:17:35.890 --> 00:17:38.850 So when you are on separate charge and transfer, 280 00:17:39.150 --> 00:17:42.770 things get a little bit more complicated, so this is how it looks like. 281 00:17:43.130 --> 00:17:46.210 Come with me and follow all the funds flows all along. 282 00:17:47.170 --> 00:17:48.890 Starting with a client application. 283 00:17:49.330 --> 00:17:51.970 The client application usually will call an API gateway, 284 00:17:52.350 --> 00:17:55.270 which will help you with the onboarding in one of the services, 285 00:17:55.330 --> 00:17:56.950 but also you may want to do a payment. 286 00:17:57.330 --> 00:18:00.210 So let's see how the payment actually gets routed all around. 287 00:18:00.770 --> 00:18:03.230 When you have a payment service that creates a PaymentIntent, 288 00:18:03.610 --> 00:18:08.110 should be and has to be confirmed by the client application with your user. 289 00:18:08.490 --> 00:18:12.350 So the customer will click on the application to do the payment, 290 00:18:12.970 --> 00:18:16.210 and money will land at the end on Stripe, but it doesn't end up here. 291 00:18:16.410 --> 00:18:20.390 We said that we have to transfer the funds to all the connected accounts 292 00:18:20.410 --> 00:18:23.310 depending on the different business rules. So, how we do this? 293 00:18:24.090 --> 00:18:25.170 We listen to webhooks. 294 00:18:25.650 --> 00:18:29.330 Whenever the payment result is correct and we are happy with it, 295 00:18:29.970 --> 00:18:34.870 this will go to a webhook service that will listen for those payments. 296 00:18:35.570 --> 00:18:39.090 And at the end, probably we want to notify different services, 297 00:18:39.150 --> 00:18:41.810 especially if we are in a multiservice architecture. 298 00:18:42.270 --> 00:18:44.210 So we may want to have a message broker. 299 00:18:44.590 --> 00:18:48.190 That message broker will send those messages to each of the different services. 300 00:18:48.690 --> 00:18:52.290 So for example, we want to update the card order, 301 00:18:53.390 --> 00:18:56.910 or we want to annotate the result in a ledger, and this is important. 302 00:18:57.410 --> 00:18:58.670 In these kind of situations, 303 00:18:58.750 --> 00:19:02.350 you probably want to have your own ledger. And third, 304 00:19:02.990 --> 00:19:05.790 maybe we want to grant access for a specific course that someone paid, 305 00:19:07.150 --> 00:19:08.490 but this isn't it. Remember, 306 00:19:08.590 --> 00:19:12.870 we have another person that needs to get paid out at the end, 307 00:19:15.390 --> 00:19:17.210 whenever the time is right. 308 00:19:17.210 --> 00:19:21.150 So we probably also need a cron scheduler that listens for 309 00:19:21.250 --> 00:19:26.250 different needs and sends the transfer with a transfer broker to 310 00:19:26.270 --> 00:19:29.970 the platform. So Stripe at the end does the transfer whenever it's needed. 311 00:19:33.550 --> 00:19:35.610 So here's the fourth lesson for today: 312 00:19:36.670 --> 00:19:39.750 all the incidents that you may have in this kind of fund flows live in the 313 00:19:39.830 --> 00:19:43.830 edges, not in the boxes. The boxes is something that typically you engineer, 314 00:19:43.990 --> 00:19:46.970 the message broker, the transfer schedule, 315 00:19:47.270 --> 00:19:50.090 all of that are typical services that you have to build whenever you are 316 00:19:50.130 --> 00:19:53.230 handling payments. But when it comes to the actual incidents, 317 00:19:53.630 --> 00:19:58.030 it's on all these little arrows that happen between the communication with each 318 00:19:58.050 --> 00:20:01.130 of the services where all your business is actually baked in. 319 00:20:03.570 --> 00:20:08.330 OK. So we've talked about all these different fund flows, 320 00:20:08.910 --> 00:20:13.050 but this is the diagram I want you to have in your wall whenever you are 321 00:20:13.070 --> 00:20:13.903 designing. 322 00:20:14.930 --> 00:20:18.970 If you are OK to get the losses collector, 323 00:20:19.910 --> 00:20:21.230 you can go on the right side. 324 00:20:21.390 --> 00:20:25.970 But if you want the losses collector and all the liability on Stripe, 325 00:20:26.530 --> 00:20:31.250 you have to make sure that you're using direct charges. Let's say that's not the 326 00:20:31.290 --> 00:20:32.123 case. 327 00:20:32.230 --> 00:20:36.690 Think about if you have delayed payments or you have a multiparty transaction. 328 00:20:37.070 --> 00:20:40.050 If that's the case, separate charges and transfer is your actual fund flow. 329 00:20:40.770 --> 00:20:43.230 If that's not the case, it's destination charges. 330 00:20:43.850 --> 00:20:48.270 And whether you use on behalf of or not will depend if it makes sense for your 331 00:20:48.310 --> 00:20:52.330 business and your need to use destination on behalf of and the merchant of 332 00:20:52.370 --> 00:20:56.130 record being the connected account. OK. 333 00:20:56.310 --> 00:21:00.810 Let's do a quick summary of what we've seen today in the framework. First one, 334 00:21:01.570 --> 00:21:06.350 the fund flows are your business model. Whenever your business model changes, 335 00:21:06.410 --> 00:21:07.710 like it's the case of CreatorCamp, 336 00:21:08.090 --> 00:21:11.890 they build a normal business and then they move to a marketplace and they have 337 00:21:11.930 --> 00:21:16.070 to close it for three months just because they didn't adapt their business to 338 00:21:16.130 --> 00:21:20.670 the actual change. Second one, pick your liability first, 339 00:21:20.930 --> 00:21:25.610 not last. It gates your fund flow. So whenever you are designing the fund flow, 340 00:21:25.750 --> 00:21:28.710 think about what is the appetite, what is the risk? 341 00:21:28.910 --> 00:21:32.890 Do you have the actual teams to take care of it? If that's not the case, 342 00:21:33.450 --> 00:21:36.030 leave it to Stripe. Third, 343 00:21:36.770 --> 00:21:38.970 the architecture constrains your geographic scale. 344 00:21:39.730 --> 00:21:43.010 Usually whenever you are opening a new country, you know there is demand. 345 00:21:43.210 --> 00:21:44.870 There are customers there to pay, 346 00:21:45.650 --> 00:21:49.510 but if your business is not adapted and all the fund flows are not adapted to 347 00:21:49.550 --> 00:21:53.550 that, then it's very likely that it breaks. And fourth, 348 00:21:53.930 --> 00:21:55.790 incidents live in the edges, not the boxes. 349 00:21:56.390 --> 00:22:00.910 Take time designing those edge cases that happen between the different systems 350 00:22:01.290 --> 00:22:05.830 and not as much designing the system itself. So whenever you are 351 00:22:05.850 --> 00:22:10.010 designing your next marketplace platform, SaaS platform, whatever it is, 352 00:22:10.550 --> 00:22:13.430 just follow these rules, follow these four traits, 353 00:22:13.750 --> 00:22:17.850 and you will make better decisions. Don't make this after your Excel file, 354 00:22:18.230 --> 00:22:20.990 make it before your PaymentIntent. Thank you so much. 355 00:22:21.970 --> 00:22:23.930 And if you need any questions, you have any questions, 356 00:22:24.030 --> 00:22:26.570 I will be in the Money Management booth, so happy to answer all of them. 357 00:22:27.070 --> 00:22:27.330 Thank you.