We've now got a vague idea of how all this stripe stuff works.
It's now going to start to work on the payment service and we're really just going to implement kind
of this portion of the diagram right here.
So we're going to implement a request handler that's going to handle this incoming request right here
where we take the token that was provided to us from the stripe j ust library and send off to our payment
service and then the payment service we're gonna take that token and make a public request to the stripe
API to actually charge the users credit card.
Let me show you a diagram of the request handler that we're going to put together to implement this
part of the flow.
So we're gonna receive that that request and inside the body the requests we're going to include the
token that the user just receives.
And we're also going to include the order I.D. or the idea of the order that the user is trying to purchase
then inside of our request handler.
We're gonna go through the following series of steps.
We're gonna first try to find the order that the user is attempting to pay for and we're gonna do some
validation around that order.
For example we're gonna make sure that the person who is trying to purchase the order is the or paper
the order is the same person who tried to originally create the order rolls can make sure that the order
is still valid.
So in other words it is still in the created state and it's not in the cancelled state we'll also make
sure that the amount of money that we are displaying inside the order the price of the order is equal
to the amount of money that the user just authorized us to charge their credit card for after that.
We're going to make a request to these stripe API to actually charge the users credit card.
That's what we're going to actually a bill the user and then immediately after we will create a charge
record inside of our database and this charge record is what's going to actually say that we have successfully
billed the user for some amount of money so that's it.
That's pretty much what we can do inside of some request handler.
And as I mentioned we're going to build to test out this entire flow using just alone where our automated
test runner we are not going to have to implement anything in the browser just yet to make sure that
this stuff works as expected.
Yes let's get to it.
Let's build a request handler that goes through these series of steps
so back inside of my editor I'm going to find my payment service and inside there I'm going to find
the SRT directory and I'll make a new folder called Roots I'll then make a new file inside there of
new dot t yes then calling this new because we're creating a new charge object or new charge record
inside of our database then at the very top we merely add in a couple of different imports.
And I love these imports are going to look very familiar right away.
I'm going to import Express and the request and response types from Express I'm going to get the body
validator from Express validator and then we're going to get a couple of different middle wears in ear
objects from our common module that we'll get require off validate request
bad Request air
and not bound air.
Now that's going to come from our coming module.
Then after that I will import my order model.
We created just a little bit ago from up one directory models order and I think that should be enough
for right now that we can create a new router object using express or a new router from Express dot
router and then we will associate a post request handler with this thing so I can say that eight times
someone makes a post request to API payments we're going to handle it inside of this request handler
immediately add on the rack as request and rest as response and then right after the actual path right
there we'll add in a couple of different middleware so we adjust imported so first we definitely want
to make sure that the user is actually authenticated.
If you're not authenticated you should not be making a request to this handler.
We'll put in our require off middleware then after that we'll put in a validation step and just make
sure that the user is actually submitting a token and an order I.D. as well so I'll put in a validator
of body token and we want to check and make sure that this thing is not empty or not is empty then same
thing for the order idea as well.
Order I.D. not is empty and natural if you want to.
You could also put a custom message on there if you wish.
Totally up to you.
Then inside of the actual handler I gonna mark this thing as async because we're definitely enough to
reach into our database at some point and for right now just to get started.
I'm gonna put in a resort send with a success through like so just to get started.
We will replace this really really quickly and they're going to make sure that I export this router
at the bottom of the file so remember we've been doing it named exports.
Or we renamed the experts on the fly for all the different routers we put together.
So I will export router as create charge router
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
of APT.
Yes at the very top I will import create charge router from our out directory.
New
and then right after
our appetite use call right here for current user mix you're right after that right above the app dot
all statement we'll put in an adult use or the recharge router that we just imported
and that should get us started.
Now we are now handling requests that are coming to this route but remember we have not yet added anything
into our ingress engine ex config to make sure that requests to API payments get directed to our payment
service.
So we still have to make that quick change.
Let's do that right now as well.
Inside of my infra directory I'll find the K its folder and then inside there I went to find our ingress
service config.
I'm going to add a new path in here and I'll just add it at the very top.
I'm going to duplicate the API users pasted in so there's my duplicate I'll fix up some indentation
and I'll change this to API slash payments like so any time we receive a request going to API slash
payments.
I want to send it off to the payments SRB plus the IP service is let's save that as well.
And now in theory we could make a request to API slash payments and see a response back of success true
let's test that out right now back inside a postman the back in post man I can open up a new tab.
I can make a request to H2 G.P.S. ticketing dot dev
and then API slash payments.
I'll make sure I am making a post request
or headers.
I will add in that content type of application Jason and then as usual over on the buddy tab select
raw.
It's like Jason out front now put in an empty object.
Now we do have some actual validation to make sure that we provide a token and an order I.D. which we
are not doing.
So when we submit this request we should definitely see an error come back they'll send this off.
And oh we're not seeing an error because we never actually wired up the validate requests middleware
right there.
So although we failed that validation we never actually handled it.
And so we just went through to the actual request handler.
Let's let's wire up validate request right now because I know I will forget that right after the 2 validation
steps will add and validate request save this and now if we flip back over and try to make that same
request now we get that appropriate error where we are told that we have to provide a token and an order
I.D..
So a little bit of progress here.
We'll take a quick pause.
Come back next video and then we're going to start to implement a couple of different steps of business
logic inside the actual root handler.