Once we submit that payment information up to strike, we get back this object right here that has the
I.D. inside of it.
That I.D. is the token that we want to provide to our payment service.
Let's go take a quick look at our payment service.
Just a quick get a quick reminder on what we have to do next.
So inside my payment service, I'm going to find the SIRC roots directory.
And then inside their new.
Yes.
So we need to make a post request to API slash payments and we need to include the token, which is
the I.D. inside that object along with the order I.D..
That's pretty much it.
Let's go back over to our order show component.
Here it is right here.
So we have our callback right there that we are passing off to the token prop of stripe checkout.
So once we get that token, all we really care about it is the I.D. So I'm going to get started by D..
Structuring out just the I.D..
And right now, I'll just update the council log to I.D..
Now we need to make sure that we take that I.D. and the I.D. off of the order that we received as a
prop and make that request off to our payment service.
Once again, we're going to make use of the U.S.
Request hook that the very top of the file.
I will import U.S. request from up to directories, folks use request.
And then right after.
Are you state going to add in due request?
Eres.
And that will come from calling use request with our Eurail of API slash payments.
The method is most.
The body is going to contain our order I.D..
As order dot idee and now in this scenario, we're in just a little bit of a challenging spot right
here.
So in all the things we've looked at so far around this year's request hook, we really just provided
some body properties to the thing.
And I was pretty much it that loaded up or kind of created a request that was ready to go.
And as soon as we called do request, it would then execute the request.
But in this case, at the instant that we get that token inside this token callback right here, the
instant we get that little I.D. thing, we want to make our request.
And we don't really have the opportunity to go back and set any states or add that property into body
right here.
What would be really nice is if we could provide this extra token property off to the do request function
and have to do request function, just automatically merge in this additional property to the request
itself.
So in other words, what I would really like to do instead of this council log right here, I would
like to call do request and then passan an object that has a token, which is the idea off that object
and then have the request function merged.
This little object right here together with the body object right here.
And so we should end up with two properties being sent off to our back and API, both the order I.D.
and the token.
So to make this work, we're going have to make a little change to our user request hook and just make
sure that if we pass any additional properties off to do request, it should merge those into the eventual
request that we send off.
Let's open up our Hoke's file, find a user request.
I'll find the do request function right here.
So I going to say that this thing is going to receive some additional props or properties we want to
send along.
I'm going to default that to be an empty object just in case we decide not to provide any.
Which is how we've already made use of this hoax several times throughout this project.
Then I'm going to take those props and I'm going to merge them in with the body that we had provided
to the hook originally.
So in total, I'm going to remove body.
I'm going to put in a new line here just to give myself a little bit of space.
I'll then create a new object.
I'll put in dot, dot, dot, body and dot, dot, dot props.
Like so.
And that should be it.
They'll say the file.
And I guess it really wants it to be on one line after all.
So now whenever we make use of our use request hook, when we call do request, we can pass in some
additional properties to include with the request body.
And so now the code that we just added in over back inside of order show specifically the call to do
request right here should work as expected.
OK, so now last thing to do.
When we call a user request after the body, we also have to provide the on success callback.
We're going to receive as a response the payments object.
So remember, whenever we create a payment, we send back some information about payment that was just
made.
And really, I think it just includes the I.D. and maybe the order I.D. as well.
Right now, let's just do a console log of that payment.
And then finally, let's take the ears, J.S. ex right there and make sure that we show it somewhere
inside of our return, J.S. X block down here as well.
They'll just stick in ears anywhere inside their.
Let's save this and go test it out.
Now, I do want to know the first time we'd run this code.
We are going to see an error.
This is just a tiny little gotcha.
We're gonna fix it up.
I just want you to see the air in action.
OK.
So I kind of look back over a map, my list of tickets.
I'm going to try to create a new order.
So click on purchase.
And as soon as I do, I see a nasty error right here.
Like I said, just a little.
Gotcha.
Nothing we can't fix.
So we just made a change to our user request hook.
Here it is right here.
And we said that when we call use or Simmi, when we call do request, we can optionally provide in
some additional properties to include with requests body.
That means that ain't me called do request.
If we provide any argument whatsoever, that argument is going to be merged into the request body.
And why is that relevant?
Well, you might recall just a moment ago when we were working inside of our ticket show component,
which is really tickets ticket idea, that file right there.
We had made use of the used request hook.
So we got that do request function.
And then I kind of made a big deal about putting the button element right here, giving it the on click
callback.
And then as soon as someone clicked on that thing, we were going to invoke do request.
Well, remember, anytime that we put something in as an event handler, that function right there is
going to be given a first argument of the event object.
So right now, with the change we just made to the do request function.
We're going to essentially receive the event object as this props argument and then merge it into the
request body.
So we are trying to take an event and send it off as a request body, which is why we're seeing that
nasty air.
But it picks us up.
All we can do is go back over to our ticket show.
Finally on Klick, we're going to wrap that with an arrow function.
So now, even though this does get called with an event object, we're not going receive it.
We're not going to pass it through to do request or anything like that.
OK.
Such a fix there.
So let's say this.
I to flip back over.
I'm going to create an order.
There we go.
I'll pay with my card.
Or two for two, for two, for two.
A 20 dollars.
And we should make a request to our payment and point their dues payments.
Now, we have purchased this order or at least provided some payment in theory.
Now, just so you know, if we now do any follow up payments, it is extremely likely they will end
up see an error because the payment service will probably say something like, hey, that order has
already been paid for.
Or something like that.
We can verify.
Make sure that the payment has been processed.
If we go back over to scaffold.
Back inside of that scaffold, we could take a look at these series of events that have been emitted
and received and try to pass or get an idea of the series of actions that just went on behind the scenes.
So first off, it looks like that right there is probably where we initially created the order.
We published an order create events.
The expiration service started up a timer.
Then the payment service received that and knew that it needed to start to watch for an incoming payment
for that order.
Later on, it looks like we had a ticket updated.
So that's where we successfully reserve the ticket by setting its order I.D. property.
It looks like the order service itself got acknowledgment that the ticket was reserved.
Then a little bit later.
And these two events for me right here are out of order.
This is where we submitted the payment.
So the payment service, alleged events say that the payment was created.
The order service received that event.
And so at that point time, it marked that order as probably being paid for or completed.
I think is what we called it.
Then a little bit later, once again, out of order right here, I see expiration.
Complete.
So that's where our expiration service says, hey, it's been 60 seconds.
Hopefully this thing has been paid for.
And it looks like the order service received that and said, oh, well, this order has already been
paid for.
So I don't have to worry about canceling it or anything like that.
All right, let's say it looks pretty good now just to confirm, if we do go back over and tried to
repurchase this ticket again.
So here's the ticket.
If I click on purchase, I probably see something.
It says ticket is already reserved.
So this is the ticket I just paid for.
It's never going to become unreserved or anything like that.
So we should probably figure out some way of maybe filtering this list right here and only show tickets
that are available.
We're alternately we could just mark tickets that have already been purchased on this list as well.
Something like that.
Something does make it really clear which tickets we can still purchase.
Well, I think we saw a little bit of work to do.
So let's get to it in just a moment.