1 00:00:01,730 --> 00:00:04,820 We've now got a vague idea of how all this stripe stuff works. 2 00:00:04,870 --> 00:00:08,570 It's now going to start to work on the payment service and we're really just going to implement kind 3 00:00:08,570 --> 00:00:11,390 of this portion of the diagram right here. 4 00:00:11,390 --> 00:00:16,220 So we're going to implement a request handler that's going to handle this incoming request right here 5 00:00:16,580 --> 00:00:21,380 where we take the token that was provided to us from the stripe j ust library and send off to our payment 6 00:00:21,380 --> 00:00:25,820 service and then the payment service we're gonna take that token and make a public request to the stripe 7 00:00:25,850 --> 00:00:28,820 API to actually charge the users credit card. 8 00:00:28,820 --> 00:00:32,870 Let me show you a diagram of the request handler that we're going to put together to implement this 9 00:00:32,870 --> 00:00:35,910 part of the flow. 10 00:00:35,950 --> 00:00:40,000 So we're gonna receive that that request and inside the body the requests we're going to include the 11 00:00:40,000 --> 00:00:41,870 token that the user just receives. 12 00:00:42,130 --> 00:00:46,660 And we're also going to include the order I.D. or the idea of the order that the user is trying to purchase 13 00:00:48,800 --> 00:00:50,270 then inside of our request handler. 14 00:00:50,280 --> 00:00:52,640 We're gonna go through the following series of steps. 15 00:00:52,950 --> 00:00:57,060 We're gonna first try to find the order that the user is attempting to pay for and we're gonna do some 16 00:00:57,120 --> 00:00:58,830 validation around that order. 17 00:00:58,830 --> 00:01:03,270 For example we're gonna make sure that the person who is trying to purchase the order is the or paper 18 00:01:03,270 --> 00:01:09,810 the order is the same person who tried to originally create the order rolls can make sure that the order 19 00:01:09,810 --> 00:01:10,680 is still valid. 20 00:01:10,680 --> 00:01:17,070 So in other words it is still in the created state and it's not in the cancelled state we'll also make 21 00:01:17,070 --> 00:01:23,130 sure that the amount of money that we are displaying inside the order the price of the order is equal 22 00:01:23,130 --> 00:01:28,820 to the amount of money that the user just authorized us to charge their credit card for after that. 23 00:01:28,840 --> 00:01:33,100 We're going to make a request to these stripe API to actually charge the users credit card. 24 00:01:33,370 --> 00:01:38,700 That's what we're going to actually a bill the user and then immediately after we will create a charge 25 00:01:38,760 --> 00:01:44,160 record inside of our database and this charge record is what's going to actually say that we have successfully 26 00:01:44,160 --> 00:01:47,400 billed the user for some amount of money so that's it. 27 00:01:47,410 --> 00:01:49,870 That's pretty much what we can do inside of some request handler. 28 00:01:49,870 --> 00:01:55,240 And as I mentioned we're going to build to test out this entire flow using just alone where our automated 29 00:01:55,240 --> 00:01:59,500 test runner we are not going to have to implement anything in the browser just yet to make sure that 30 00:01:59,500 --> 00:02:01,130 this stuff works as expected. 31 00:02:02,040 --> 00:02:02,740 Yes let's get to it. 32 00:02:02,750 --> 00:02:05,540 Let's build a request handler that goes through these series of steps 33 00:02:08,280 --> 00:02:14,620 so back inside of my editor I'm going to find my payment service and inside there I'm going to find 34 00:02:14,620 --> 00:02:23,330 the SRT directory and I'll make a new folder called Roots I'll then make a new file inside there of 35 00:02:23,330 --> 00:02:29,390 new dot t yes then calling this new because we're creating a new charge object or new charge record 36 00:02:29,420 --> 00:02:34,010 inside of our database then at the very top we merely add in a couple of different imports. 37 00:02:34,020 --> 00:02:36,690 And I love these imports are going to look very familiar right away. 38 00:02:36,810 --> 00:02:43,760 I'm going to import Express and the request and response types from Express I'm going to get the body 39 00:02:43,820 --> 00:02:52,230 validator from Express validator and then we're going to get a couple of different middle wears in ear 40 00:02:52,230 --> 00:02:57,120 objects from our common module that we'll get require off validate request 41 00:02:59,950 --> 00:03:01,240 bad Request air 42 00:03:05,170 --> 00:03:07,490 and not bound air. 43 00:03:07,600 --> 00:03:12,970 Now that's going to come from our coming module. 44 00:03:13,050 --> 00:03:15,220 Then after that I will import my order model. 45 00:03:15,270 --> 00:03:23,690 We created just a little bit ago from up one directory models order and I think that should be enough 46 00:03:23,690 --> 00:03:31,490 for right now that we can create a new router object using express or a new router from Express dot 47 00:03:31,550 --> 00:03:38,250 router and then we will associate a post request handler with this thing so I can say that eight times 48 00:03:38,250 --> 00:03:45,600 someone makes a post request to API payments we're going to handle it inside of this request handler 49 00:03:48,680 --> 00:03:56,800 immediately add on the rack as request and rest as response and then right after the actual path right 50 00:03:56,800 --> 00:04:01,510 there we'll add in a couple of different middleware so we adjust imported so first we definitely want 51 00:04:01,510 --> 00:04:03,680 to make sure that the user is actually authenticated. 52 00:04:03,730 --> 00:04:07,850 If you're not authenticated you should not be making a request to this handler. 53 00:04:07,960 --> 00:04:13,720 We'll put in our require off middleware then after that we'll put in a validation step and just make 54 00:04:13,720 --> 00:04:21,020 sure that the user is actually submitting a token and an order I.D. as well so I'll put in a validator 55 00:04:21,050 --> 00:04:31,210 of body token and we want to check and make sure that this thing is not empty or not is empty then same 56 00:04:31,210 --> 00:04:32,720 thing for the order idea as well. 57 00:04:33,490 --> 00:04:38,460 Order I.D. not is empty and natural if you want to. 58 00:04:38,460 --> 00:04:40,740 You could also put a custom message on there if you wish. 59 00:04:40,740 --> 00:04:45,060 Totally up to you. 60 00:04:45,420 --> 00:04:49,140 Then inside of the actual handler I gonna mark this thing as async because we're definitely enough to 61 00:04:49,200 --> 00:04:53,060 reach into our database at some point and for right now just to get started. 62 00:04:53,070 --> 00:04:59,800 I'm gonna put in a resort send with a success through like so just to get started. 63 00:04:59,810 --> 00:05:05,210 We will replace this really really quickly and they're going to make sure that I export this router 64 00:05:05,210 --> 00:05:09,470 at the bottom of the file so remember we've been doing it named exports. 65 00:05:09,470 --> 00:05:13,110 Or we renamed the experts on the fly for all the different routers we put together. 66 00:05:13,160 --> 00:05:18,020 So I will export router as create charge router 67 00:05:21,790 --> 00:05:26,520 I'm going to say this file and I'm going to go in wired up inside of my apt yes file it's back inside 68 00:05:26,520 --> 00:05:27,020 of APT. 69 00:05:27,040 --> 00:05:36,240 Yes at the very top I will import create charge router from our out directory. 70 00:05:36,240 --> 00:05:36,500 New 71 00:05:39,350 --> 00:05:40,650 and then right after 72 00:05:43,580 --> 00:05:48,560 our appetite use call right here for current user mix you're right after that right above the app dot 73 00:05:48,560 --> 00:05:54,420 all statement we'll put in an adult use or the recharge router that we just imported 74 00:05:57,530 --> 00:05:59,790 and that should get us started. 75 00:05:59,830 --> 00:06:04,690 Now we are now handling requests that are coming to this route but remember we have not yet added anything 76 00:06:04,690 --> 00:06:09,910 into our ingress engine ex config to make sure that requests to API payments get directed to our payment 77 00:06:09,910 --> 00:06:10,940 service. 78 00:06:10,940 --> 00:06:12,700 So we still have to make that quick change. 79 00:06:12,700 --> 00:06:14,620 Let's do that right now as well. 80 00:06:14,890 --> 00:06:19,930 Inside of my infra directory I'll find the K its folder and then inside there I went to find our ingress 81 00:06:19,990 --> 00:06:23,160 service config. 82 00:06:23,340 --> 00:06:26,460 I'm going to add a new path in here and I'll just add it at the very top. 83 00:06:26,480 --> 00:06:32,860 I'm going to duplicate the API users pasted in so there's my duplicate I'll fix up some indentation 84 00:06:35,510 --> 00:06:42,560 and I'll change this to API slash payments like so any time we receive a request going to API slash 85 00:06:42,560 --> 00:06:43,140 payments. 86 00:06:43,190 --> 00:06:50,740 I want to send it off to the payments SRB plus the IP service is let's save that as well. 87 00:06:50,740 --> 00:06:57,690 And now in theory we could make a request to API slash payments and see a response back of success true 88 00:06:58,380 --> 00:07:04,430 let's test that out right now back inside a postman the back in post man I can open up a new tab. 89 00:07:05,780 --> 00:07:08,880 I can make a request to H2 G.P.S. ticketing dot dev 90 00:07:12,740 --> 00:07:16,740 and then API slash payments. 91 00:07:16,880 --> 00:07:18,710 I'll make sure I am making a post request 92 00:07:22,530 --> 00:07:23,130 or headers. 93 00:07:23,130 --> 00:07:32,160 I will add in that content type of application Jason and then as usual over on the buddy tab select 94 00:07:32,170 --> 00:07:33,130 raw. 95 00:07:33,210 --> 00:07:37,100 It's like Jason out front now put in an empty object. 96 00:07:37,100 --> 00:07:42,020 Now we do have some actual validation to make sure that we provide a token and an order I.D. which we 97 00:07:42,020 --> 00:07:42,760 are not doing. 98 00:07:42,830 --> 00:07:46,910 So when we submit this request we should definitely see an error come back they'll send this off. 99 00:07:48,440 --> 00:07:54,370 And oh we're not seeing an error because we never actually wired up the validate requests middleware 100 00:07:54,380 --> 00:07:55,190 right there. 101 00:07:55,190 --> 00:07:58,440 So although we failed that validation we never actually handled it. 102 00:07:58,550 --> 00:08:01,380 And so we just went through to the actual request handler. 103 00:08:01,410 --> 00:08:06,530 Let's let's wire up validate request right now because I know I will forget that right after the 2 validation 104 00:08:06,530 --> 00:08:14,080 steps will add and validate request save this and now if we flip back over and try to make that same 105 00:08:14,080 --> 00:08:20,260 request now we get that appropriate error where we are told that we have to provide a token and an order 106 00:08:20,270 --> 00:08:22,110 I.D.. 107 00:08:22,300 --> 00:08:24,070 So a little bit of progress here. 108 00:08:24,190 --> 00:08:25,080 We'll take a quick pause. 109 00:08:25,090 --> 00:08:29,260 Come back next video and then we're going to start to implement a couple of different steps of business 110 00:08:29,260 --> 00:08:31,330 logic inside the actual root handler.