WEBVTT 00:00.000 --> 00:00.270 Okay. 00:00.270 --> 00:01.950 Welcome to section ten. 00:01.950 --> 00:08.040 And now it's time to take a look at our checkout and payment system in our application. 00:08.040 --> 00:12.420 And take in payments in our application is not something to be taken lightly. 00:12.420 --> 00:16.170 So let's take a look at what's coming up in this section. 00:16.200 --> 00:18.870 Of course, first of all we're going to take a look at taking payments. 00:18.870 --> 00:25.110 That means user entering their credit card details into a form and us processing the payment. 00:25.110 --> 00:30.990 I say us in air quotes because it's not really going to be us taking the payment as we need to account 00:30.990 --> 00:38.910 for payment card industry compliance, as there's a reason that the internet is kind of a trusted place 00:38.910 --> 00:45.690 where people do enter their credit card details into e-commerce stores with some confidence that it's 00:45.690 --> 00:47.700 not going to be a fraudulent transaction. 00:47.700 --> 00:52.650 We're also going to take a look at strong customer authentication, which is actually a European standard 00:52.650 --> 00:53.970 for taking payments. 00:53.970 --> 00:58.860 But that pretty much means that for a typical e-commerce store, you might as well use this for every 00:58.860 --> 01:04.140 transaction The payment processor we're going to use, because it's pretty much impossible for us to 01:04.170 --> 01:07.590 meet in a training course, the payment card industry compliance standards. 01:07.590 --> 01:09.030 We need to use a payment processor. 01:09.060 --> 01:10.920 The one that we're going to use is stripe. 01:10.920 --> 01:15.870 It comes with a lot of excellent functionality that we can take advantage of in our application. 01:15.870 --> 01:17.460 So we'll also take a look at that. 01:17.460 --> 01:21.120 And one of the things that stripe gives us is a secret key. 01:21.120 --> 01:26.310 So we also need to think about where we're storing these kind of secrets in our code. 01:26.310 --> 01:30.870 So when it comes to taking payments we need to think about PCI compliance. 01:30.870 --> 01:37.590 And this refers to adhering to the Payment Card Industry Data Security Standard, or PCI, DSS to give 01:37.590 --> 01:44.880 it its full abbreviation, which is a set of industry standards designed to protect cardholder data 01:44.910 --> 01:52.530 during processing, storage and transmission, and it increases the protection for payment card information. 01:52.530 --> 01:59.810 And this set of standards applies to any organization that accepts processes Is or stores payment card 01:59.810 --> 02:05.330 information and ensures secure handling to prevent data breaches and fraud. 02:05.450 --> 02:12.380 So we're not going to go into detail about what this is because it's a 100 page document, but it does 02:12.380 --> 02:18.320 relate to six main themes, all of which have more detail inside those documents. 02:18.320 --> 02:25.580 But it relates to things like building and maintaining a secure network, protecting cardholder data, 02:25.970 --> 02:34.460 and maintaining things like a vulnerability management program and implementing strong access control 02:34.460 --> 02:35.270 measures. 02:35.300 --> 02:38.540 Okay, so you've protected your network, but what about your data center? 02:38.570 --> 02:39.470 How secure is that? 02:39.500 --> 02:42.860 Can somebody just walk in off the street and get access to the servers in there? 02:42.860 --> 02:45.350 So then we're talking about physical security as well. 02:45.350 --> 02:50.990 All of these things are literally impossible to demonstrate on a training course, of course. 02:51.050 --> 02:57.550 And also we need an information security policy and also to regularly test and monitor the network. 02:57.550 --> 03:03.820 So a huge range of things encompasses PCI compliance, not just what we do in our code, but also the 03:03.820 --> 03:09.040 physical security around where our data is located. 03:09.070 --> 03:11.830 So not something that we're going to cover on this training course. 03:11.860 --> 03:17.980 And this is really just to point out that you absolutely, really do not want to take people's payment 03:17.980 --> 03:22.450 details directly on your server where you deploy your code. 03:22.480 --> 03:28.390 Otherwise you can be punished and punishment costs money. 03:28.420 --> 03:35.200 So if you're taking payment card details and you experience a hack or a data breach, then there's penalties. 03:35.200 --> 03:37.990 And these penalties range from all sorts of things. 03:38.020 --> 03:41.740 Monthly penalties of 5 to $100,000 a month. 03:41.740 --> 03:43.270 Infringement consequences. 03:43.270 --> 03:50.530 So that's going to cost you 50 to $90 per cardholder that's had their data breached. 03:50.950 --> 03:56.940 Also, compensation costs come along with this as well as legal action, reputation damage revenue loss, 03:56.940 --> 04:01.020 and federal audits can all become involved, so don't do it. 04:01.050 --> 04:04.560 Is the general guidance on taking payment cards? 04:04.560 --> 04:11.970 Unless you're the likes of Amazon and you can meet the PCI compliance standards, then fine. 04:11.970 --> 04:18.660 But if you're not something like Amazon, then the next best thing to do when you do want to take payment 04:18.690 --> 04:26.100 details from someone using your e-commerce store is to use a payment provider like stripe. 04:26.100 --> 04:28.260 This is the one that we are going to use. 04:28.290 --> 04:30.180 Obviously this isn't free of charge. 04:30.180 --> 04:38.640 There is a cost and for each successful card charge, then stripe will take 2.9% of that payment plus 04:38.640 --> 04:39.300 $0.30. 04:39.300 --> 04:41.490 There really is no free way to take money. 04:41.520 --> 04:44.400 We can't take cash on our servers. 04:44.400 --> 04:49.350 That would be the only free way nowadays where you're not paying for receiving money. 04:49.620 --> 04:56.880 Now, another thing that comes along with taking payments online and this is a European Union standard 04:56.880 --> 04:59.100 for authenticating payments. 04:59.100 --> 05:05.880 And even though it's an EU standard, it pretty much applies globally, except for the USA and Canada. 05:05.940 --> 05:12.090 It's possible to take payments in USA and Canada without using strong customer authentication. 05:12.090 --> 05:16.140 But typically, if you're creating an online store, you would accommodate global payments, because 05:16.140 --> 05:20.580 we can use this in the USA and Canada as well as the rest of the world. 05:20.580 --> 05:22.710 So that's what we will be implementing. 05:22.710 --> 05:27.540 But what this really means is that we require two of the following three things. 05:27.540 --> 05:30.660 Something the user knows, such as their password or their Pin. 05:30.660 --> 05:37.170 Something the user has, such as their phone or a hardware token, and something the user is. 05:37.200 --> 05:40.890 And that would be some kind of biometric authentication. 05:40.890 --> 05:46.890 And banks will typically decline payments that require strong customer authentication and do not meet 05:46.890 --> 05:47.940 this standard. 05:48.510 --> 05:53.100 So before we begin getting our hands dirty, let's just take a look at a couple of flows. 05:53.130 --> 05:59.230 The first one only applies to the USA and Canada because it's without strong customer authentication. 05:59.260 --> 06:03.640 The second one is how we're going to implement it, which does utilize this. 06:03.820 --> 06:09.130 So in the first scenario then not the one that we're going to implement, but the possibly simpler one 06:09.130 --> 06:10.270 that doesn't require that. 06:10.270 --> 06:15.340 But you could only sell things in USA and Canada if you were going to implement this kind of flow. 06:15.370 --> 06:19.900 So the user creates an order and that order is sent to our API. 06:19.900 --> 06:22.840 And if successful, the API will send a response back. 06:22.870 --> 06:28.750 At this point the user makes their payment and this would all be within the same form on the client 06:28.750 --> 06:29.620 interface. 06:29.770 --> 06:35.140 The user is not doing two separate things here, but then the user would effectively their credit card 06:35.140 --> 06:37.270 details would be passed up to stripe. 06:37.300 --> 06:44.020 Stripe would then process that payment and return to the user a token, and this token is returned to 06:44.050 --> 06:49.090 the client browser, which then gets sent up to our API, which is then passed on to stripe to check 06:49.090 --> 06:53.880 the token is valid, and if it is, then effectively stripe is going to acknowledge that the payment 06:53.880 --> 06:57.720 has been received and send a notification back to our API. 06:58.170 --> 07:01.710 At that point, we can go back to the user and say, great, we've received your payment. 07:01.710 --> 07:05.040 Everything is fine with the order and the order is on the way. 07:05.040 --> 07:09.540 And the reason this system works is due to that token, because that token will be signed by stripe 07:09.570 --> 07:13.710 using the secret key that's stored on our API server that we get from stripe. 07:13.740 --> 07:19.560 Our API knows it can trust stripe to say, yep, that's the payment that's been received and it's not 07:19.560 --> 07:22.980 the user doing something mischievous. 07:22.980 --> 07:26.130 So how about with strong customer authentication then? 07:26.130 --> 07:28.320 Well, slightly different flow in this case. 07:28.320 --> 07:33.510 So the flow starts with the user going to the checkout before they've actually confirmed they're going 07:33.540 --> 07:36.810 to make an order when they reach the checkout. 07:36.810 --> 07:39.360 At least that's how we're going to implement it in our approach. 07:39.360 --> 07:45.240 When they get to the checkout, then we're going to make a request to our API to create what's referred 07:45.270 --> 07:48.450 to as a payment intent, an intent to pay. 07:48.480 --> 07:54.550 At some future point, we send that payment intent request to Stripe and stripe will create for us a 07:54.550 --> 08:00.730 payment intent ID and a client secret, which then gets returned to the API, which we're going to put 08:00.730 --> 08:04.930 into the customer's shopping cart and return it to the user. 08:04.960 --> 08:09.340 Now at this point, the user can go away, they can come back, they can add things, remove things 08:09.340 --> 08:11.950 from their shopping cart or their baskets. 08:11.980 --> 08:13.060 And that's fine. 08:13.060 --> 08:18.280 Anytime that they come back to the checkout, we're going to repeat that process to update that payment 08:18.280 --> 08:24.850 intent and keep repeating that process up until the point where the user decides that they're going 08:24.880 --> 08:26.950 to make the payment for their order. 08:26.980 --> 08:32.050 At this point, they do enter their credit card details, and this information, along with the client 08:32.050 --> 08:34.120 secret, is sent up to stripe. 08:35.410 --> 08:41.710 Stripe will receive the payment and return successful notification to the client the browser. 08:42.190 --> 08:47.110 At this point, then the order can be created and that can be created on our API. 08:47.110 --> 08:50.730 And our API will acknowledge the successful order the creation. 08:50.730 --> 08:56.460 But what we've got at the moment is no communication directly between the API and stripe. 08:56.460 --> 09:02.190 So the API at this point has got no way of knowing for sure that stripe has successfully received that 09:02.190 --> 09:02.640 payment. 09:02.640 --> 09:07.020 We don't trust the client to tell us that we need to get that information from stripe directly. 09:07.020 --> 09:12.000 So after this stage, our order is going to be in a state of pending payment. 09:12.030 --> 09:19.050 Now at some future points and this happens very quickly, then stripe is going to contact our API directly 09:19.050 --> 09:21.090 using a webhook. 09:21.420 --> 09:27.750 And our API is going to trust what's coming from stripe, because it's going to share a webhook secret 09:27.780 --> 09:30.630 on the API that we get from stripe. 09:30.750 --> 09:37.350 So as long as that webhook secret matches, then our API can acknowledge that and we can update the 09:37.350 --> 09:39.570 payment to be payment received. 09:39.570 --> 09:44.730 And then we can notify the user that their order is on the way. 09:44.760 --> 09:48.510 So that's the flow that we are going to implement to take payments. 09:48.570 --> 09:50.040 And let's begin.