WEBVTT 00:02.580 --> 00:09.000 So last time I said that I would talk about the ignored first return value, when you call refund knew 00:09.000 --> 00:10.460 from strike, and I never did that. 00:11.100 --> 00:13.050 So let's look over the documentation. 00:14.790 --> 00:17.370 And this is the documentation we were looking at last time. 00:17.370 --> 00:24.180 And, of course, strip refund programs is passed to refund new and that returns are and they don't 00:24.180 --> 00:25.400 talk about our here at all. 00:25.830 --> 00:31.740 But if you go to the API reference and look at the refund object by clicking on refund object here, 00:31.920 --> 00:34.480 it actually describes what you get back from the refund. 00:34.830 --> 00:39.690 Now, all of this information might be useful in certain situations, but we're not using any of it. 00:39.870 --> 00:44.670 I just wanted to let you know what kind of information you're getting back in the refund in case you 00:44.670 --> 00:46.680 need to do something with it at some point in the future. 00:47.340 --> 00:47.580 All right. 00:47.580 --> 00:48.240 Let's go back to work. 00:49.320 --> 00:53.610 So we've written this refund function inside the cards package. 00:53.610 --> 00:58.460 And, of course, we need to have a handler on our API that calls this to process a refund. 00:58.860 --> 01:02.790 So let's go to our API folder and open the handlers. 01:04.500 --> 01:06.000 And here I'll just go to the very bottom. 01:08.640 --> 01:16.770 And I'll create a new handler to process a refund, so thank receiver Appointer to application and I'll 01:16.770 --> 01:20.220 call it refund charge and it's a handler. 01:20.220 --> 01:25.260 So we give it a response writer and it's pointed to a request. 01:30.090 --> 01:35.100 Now, this is going to receive Jason and I'm going to assume we're getting certain information here, 01:35.100 --> 01:43.380 so I'll create a variable charge to refund and it will be a struct and it will have the following fields. 01:43.890 --> 01:46.370 First of all, it's going to have an ID to be an integer. 01:46.380 --> 01:50.700 And in Jason, I'll call that ID and that will be the ID of the order. 01:50.710 --> 01:57.480 We want to refund, but we'll have payment intent, which we need to do a refund and that's a string. 01:57.630 --> 02:00.690 And in Jason, I'll just call that t'ai for payment intent. 02:01.710 --> 02:02.850 We'll also have the amount. 02:02.880 --> 02:03.810 Now, this is optional. 02:03.810 --> 02:09.900 If you don't specify an amount when you do a refund, then the full amount of the underlying charge 02:09.900 --> 02:10.860 will be refunded. 02:11.250 --> 02:13.460 But at some point you might want to do a partial refund. 02:13.470 --> 02:16.530 So that's why I included it in the cards package. 02:16.530 --> 02:17.670 In the refund function. 02:17.670 --> 02:19.110 They're all included here as well. 02:19.800 --> 02:24.480 It will be an integer and in JSON, I will call that amount. 02:26.950 --> 02:34.270 And finally, what currency is it, so that'll be a string and in JSON we'll call that currency and 02:34.270 --> 02:38.860 again, we're not using that with our refund function, but at some point you might be supporting multiple 02:38.860 --> 02:39.420 currencies. 02:39.430 --> 02:42.470 So you may as well put it in here right now and plan for the future. 02:43.510 --> 02:48.050 Now, at this point, I would actually do something that I'm not going to bother doing right now. 02:48.100 --> 02:52.030 I would validate the amount against the underlying order. 02:52.690 --> 02:57.400 So I would call the database with the ID for the order, look up the amount, compare the amount that's 02:57.400 --> 03:02.590 in the database with the amount that's specified in this JSON payload, and make sure that, first of 03:02.590 --> 03:05.560 all, the amount I'm trying to refund isn't greater than the amount. 03:05.920 --> 03:09.950 And secondly, that maybe that they're equal, whatever logic you want to implement there. 03:09.970 --> 03:13.750 Now, I'm not going to bother doing that because that's trivial and you should have no difficulty doing 03:13.750 --> 03:14.340 that on your own. 03:15.040 --> 03:19.570 And also, the refunds here are all coming from a secure back end. 03:19.570 --> 03:24.550 And the only person that can has access to that is the authorized user, in our case, admin at example, 03:24.550 --> 03:25.110 dot com. 03:25.660 --> 03:30.700 So I'm going to assume that admin at example dot com is an honest person and isn't going to try to cheat 03:30.700 --> 03:36.460 himself now will create a card from our cards package. 03:36.490 --> 03:40.110 We're going to call cards dot card and specify its fields. 03:40.510 --> 03:44.500 So the secret that's equal to abduct config, 03:47.860 --> 03:52.780 dot, strike, dot secret the key which we don't use. 03:52.780 --> 03:58.510 But I put it in there because I might at some point in the future, abduct config, dot straight dot 03:58.510 --> 04:05.140 key and the currency which is charge to refund the currency. 04:05.890 --> 04:09.230 So that gives me my card variable and now I can call all the methods on it. 04:09.610 --> 04:13.390 We also of course, have to read our Jason into that variable. 04:13.390 --> 04:21.970 So error is assign the value of APT JSON and we hand it W r and we're reading into charge to refund 04:23.110 --> 04:23.980 and we check for an error. 04:26.050 --> 04:33.610 If error is not equal to nil, then apt bad request or an error and return. 04:34.090 --> 04:34.840 Don't go any further. 04:37.820 --> 04:43.670 So we have our variable we've read our Jason and populated a variable, optionally we can do some validation 04:43.670 --> 04:48.500 here and now we've created a code variable, so let's try to refund it. 04:49.340 --> 04:53.570 Error is sign the value of or is equal to her refund. 04:54.230 --> 05:00.620 And it requires the payment intent, which is charged to refund payment intent, and it requires the 05:00.620 --> 05:04.040 amount charged to refund that amount. 05:05.270 --> 05:06.340 And again, we check for an error. 05:06.350 --> 05:07.580 So I'll just copy this code 05:10.790 --> 05:13.460 and paste it here and now. 05:13.880 --> 05:15.530 Everything probably went all right. 05:15.530 --> 05:22.820 So we'll create a response variable resp to disrupt and it has an error field, which is a ball. 05:24.530 --> 05:32.780 And in JSON that's called error and it has a message which is a string. 05:33.980 --> 05:36.650 And in JSON we call that message. 05:37.160 --> 05:41.420 Now, I've never done anything with message here, but I put that in because when you're writing your 05:41.420 --> 05:44.450 code, you may want to specify some kind of message and send it back. 05:44.830 --> 05:48.400 OK, so we'll specify one here just for fun. 05:49.100 --> 05:56.540 So restaurant error is equal to defaults because there are no errors and the message is equal to charge 05:56.540 --> 05:57.230 refunded. 05:58.970 --> 06:00.740 And we write Jason Topdog. 06:00.740 --> 06:01.340 Right, Jason. 06:02.270 --> 06:05.660 And that requires some status of status. 06:05.670 --> 06:08.540 OK, and the response. 06:10.700 --> 06:12.350 So there's our handler. 06:12.650 --> 06:15.610 And now, of course, we need to set up a route for it. 06:16.370 --> 06:23.450 So let's go to Root Stasch API and write down here in the protected section because this is a protected 06:23.450 --> 06:32.090 route post and we'll just call it slash admins or API slash admin refund and we'll call the handler 06:32.120 --> 06:33.560 after a refund charge. 06:34.760 --> 06:39.320 OK, so we have our cards logic in place to do a refund. 06:39.320 --> 06:43.520 We have a handler to call that kurds' package and then we have a root to the handler. 06:43.940 --> 06:50.060 So now we need to go update our front end code to call that route, which fires off the handler and 06:50.060 --> 06:50.780 does the refund. 06:50.900 --> 06:53.180 And we'll get started on that in the next lecture.