1
00:00:01,130 --> 00:00:04,970
Once we submit that payment information up to strike, we get back this object right here that has the

2
00:00:04,970 --> 00:00:05,990
I.D. inside of it.

3
00:00:06,320 --> 00:00:09,440
That I.D. is the token that we want to provide to our payment service.

4
00:00:09,860 --> 00:00:11,660
Let's go take a quick look at our payment service.

5
00:00:11,780 --> 00:00:14,810
Just a quick get a quick reminder on what we have to do next.

6
00:00:15,480 --> 00:00:19,700
So inside my payment service, I'm going to find the SIRC roots directory.

7
00:00:19,850 --> 00:00:21,140
And then inside their new.

8
00:00:21,220 --> 00:00:21,630
Yes.

9
00:00:22,550 --> 00:00:27,800
So we need to make a post request to API slash payments and we need to include the token, which is

10
00:00:27,800 --> 00:00:30,950
the I.D. inside that object along with the order I.D..

11
00:00:31,820 --> 00:00:32,580
That's pretty much it.

12
00:00:34,070 --> 00:00:35,930
Let's go back over to our order show component.

13
00:00:36,200 --> 00:00:36,830
Here it is right here.

14
00:00:37,880 --> 00:00:43,300
So we have our callback right there that we are passing off to the token prop of stripe checkout.

15
00:00:43,910 --> 00:00:49,260
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..

16
00:00:49,310 --> 00:00:50,930
Structuring out just the I.D..

17
00:00:52,930 --> 00:00:55,120
And right now, I'll just update the council log to I.D..

18
00:00:56,260 --> 00:01:00,970
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

19
00:01:00,970 --> 00:01:03,670
prop and make that request off to our payment service.

20
00:01:04,210 --> 00:01:05,910
Once again, we're going to make use of the U.S.

21
00:01:05,980 --> 00:01:08,620
Request hook that the very top of the file.

22
00:01:11,420 --> 00:01:17,420
I will import U.S. request from up to directories, folks use request.

23
00:01:20,820 --> 00:01:21,610
And then right after.

24
00:01:21,630 --> 00:01:25,410
Are you state going to add in due request?

25
00:01:27,660 --> 00:01:28,230
Eres.

26
00:01:30,180 --> 00:01:35,710
And that will come from calling use request with our Eurail of API slash payments.

27
00:01:36,750 --> 00:01:38,400
The method is most.

28
00:01:40,270 --> 00:01:44,380
The body is going to contain our order I.D..

29
00:01:45,600 --> 00:01:52,170
As order dot idee and now in this scenario, we're in just a little bit of a challenging spot right

30
00:01:52,170 --> 00:01:52,500
here.

31
00:01:52,860 --> 00:01:57,150
So in all the things we've looked at so far around this year's request hook, we really just provided

32
00:01:57,150 --> 00:01:58,980
some body properties to the thing.

33
00:01:59,360 --> 00:02:03,090
And I was pretty much it that loaded up or kind of created a request that was ready to go.

34
00:02:03,330 --> 00:02:06,390
And as soon as we called do request, it would then execute the request.

35
00:02:07,020 --> 00:02:11,910
But in this case, at the instant that we get that token inside this token callback right here, the

36
00:02:11,910 --> 00:02:15,300
instant we get that little I.D. thing, we want to make our request.

37
00:02:15,500 --> 00:02:21,000
And we don't really have the opportunity to go back and set any states or add that property into body

38
00:02:21,030 --> 00:02:21,570
right here.

39
00:02:21,980 --> 00:02:27,510
What would be really nice is if we could provide this extra token property off to the do request function

40
00:02:27,900 --> 00:02:31,890
and have to do request function, just automatically merge in this additional property to the request

41
00:02:31,890 --> 00:02:32,280
itself.

42
00:02:32,910 --> 00:02:37,650
So in other words, what I would really like to do instead of this council log right here, I would

43
00:02:37,650 --> 00:02:45,090
like to call do request and then passan an object that has a token, which is the idea off that object

44
00:02:45,570 --> 00:02:47,810
and then have the request function merged.

45
00:02:47,940 --> 00:02:52,920
This little object right here together with the body object right here.

46
00:02:53,100 --> 00:02:57,360
And so we should end up with two properties being sent off to our back and API, both the order I.D.

47
00:02:57,390 --> 00:02:58,260
and the token.

48
00:02:59,260 --> 00:03:03,100
So to make this work, we're going have to make a little change to our user request hook and just make

49
00:03:03,100 --> 00:03:08,100
sure that if we pass any additional properties off to do request, it should merge those into the eventual

50
00:03:08,100 --> 00:03:09,280
request that we send off.

51
00:03:10,060 --> 00:03:12,640
Let's open up our Hoke's file, find a user request.

52
00:03:15,030 --> 00:03:17,220
I'll find the do request function right here.

53
00:03:17,970 --> 00:03:22,620
So I going to say that this thing is going to receive some additional props or properties we want to

54
00:03:22,620 --> 00:03:23,160
send along.

55
00:03:24,660 --> 00:03:28,730
I'm going to default that to be an empty object just in case we decide not to provide any.

56
00:03:28,790 --> 00:03:32,450
Which is how we've already made use of this hoax several times throughout this project.

57
00:03:33,910 --> 00:03:39,240
Then I'm going to take those props and I'm going to merge them in with the body that we had provided

58
00:03:39,480 --> 00:03:40,500
to the hook originally.

59
00:03:40,770 --> 00:03:43,470
So in total, I'm going to remove body.

60
00:03:43,950 --> 00:03:46,620
I'm going to put in a new line here just to give myself a little bit of space.

61
00:03:47,350 --> 00:03:49,170
I'll then create a new object.

62
00:03:49,500 --> 00:03:52,930
I'll put in dot, dot, dot, body and dot, dot, dot props.

63
00:03:53,160 --> 00:03:53,670
Like so.

64
00:03:55,130 --> 00:03:55,970
And that should be it.

65
00:03:56,370 --> 00:03:57,140
They'll say the file.

66
00:03:57,620 --> 00:04:00,020
And I guess it really wants it to be on one line after all.

67
00:04:01,110 --> 00:04:06,570
So now whenever we make use of our use request hook, when we call do request, we can pass in some

68
00:04:06,600 --> 00:04:09,210
additional properties to include with the request body.

69
00:04:10,420 --> 00:04:15,040
And so now the code that we just added in over back inside of order show specifically the call to do

70
00:04:15,040 --> 00:04:17,260
request right here should work as expected.

71
00:04:18,620 --> 00:04:19,800
OK, so now last thing to do.

72
00:04:20,220 --> 00:04:27,450
When we call a user request after the body, we also have to provide the on success callback.

73
00:04:28,750 --> 00:04:31,570
We're going to receive as a response the payments object.

74
00:04:31,630 --> 00:04:35,440
So remember, whenever we create a payment, we send back some information about payment that was just

75
00:04:35,440 --> 00:04:35,740
made.

76
00:04:36,160 --> 00:04:39,550
And really, I think it just includes the I.D. and maybe the order I.D. as well.

77
00:04:40,480 --> 00:04:42,670
Right now, let's just do a console log of that payment.

78
00:04:45,720 --> 00:04:50,490
And then finally, let's take the ears, J.S. ex right there and make sure that we show it somewhere

79
00:04:50,490 --> 00:04:54,430
inside of our return, J.S. X block down here as well.

80
00:04:55,960 --> 00:04:57,970
They'll just stick in ears anywhere inside their.

81
00:05:00,010 --> 00:05:01,660
Let's save this and go test it out.

82
00:05:01,810 --> 00:05:03,610
Now, I do want to know the first time we'd run this code.

83
00:05:03,640 --> 00:05:04,790
We are going to see an error.

84
00:05:04,840 --> 00:05:06,670
This is just a tiny little gotcha.

85
00:05:07,060 --> 00:05:07,750
We're gonna fix it up.

86
00:05:07,780 --> 00:05:09,400
I just want you to see the air in action.

87
00:05:09,960 --> 00:05:10,190
OK.

88
00:05:10,330 --> 00:05:12,310
So I kind of look back over a map, my list of tickets.

89
00:05:13,300 --> 00:05:14,960
I'm going to try to create a new order.

90
00:05:15,040 --> 00:05:15,970
So click on purchase.

91
00:05:16,000 --> 00:05:18,490
And as soon as I do, I see a nasty error right here.

92
00:05:18,970 --> 00:05:20,090
Like I said, just a little.

93
00:05:20,110 --> 00:05:20,620
Gotcha.

94
00:05:20,710 --> 00:05:21,760
Nothing we can't fix.

95
00:05:22,450 --> 00:05:25,470
So we just made a change to our user request hook.

96
00:05:25,800 --> 00:05:26,440
Here it is right here.

97
00:05:27,040 --> 00:05:31,600
And we said that when we call use or Simmi, when we call do request, we can optionally provide in

98
00:05:31,600 --> 00:05:34,090
some additional properties to include with requests body.

99
00:05:35,840 --> 00:05:37,660
That means that ain't me called do request.

100
00:05:38,030 --> 00:05:43,460
If we provide any argument whatsoever, that argument is going to be merged into the request body.

101
00:05:44,090 --> 00:05:44,990
And why is that relevant?

102
00:05:45,410 --> 00:05:51,110
Well, you might recall just a moment ago when we were working inside of our ticket show component,

103
00:05:51,170 --> 00:05:53,570
which is really tickets ticket idea, that file right there.

104
00:05:54,610 --> 00:05:56,360
We had made use of the used request hook.

105
00:05:57,130 --> 00:05:58,660
So we got that do request function.

106
00:05:59,410 --> 00:06:04,630
And then I kind of made a big deal about putting the button element right here, giving it the on click

107
00:06:04,630 --> 00:06:05,120
callback.

108
00:06:05,500 --> 00:06:09,010
And then as soon as someone clicked on that thing, we were going to invoke do request.

109
00:06:09,790 --> 00:06:14,680
Well, remember, anytime that we put something in as an event handler, that function right there is

110
00:06:14,680 --> 00:06:17,980
going to be given a first argument of the event object.

111
00:06:18,450 --> 00:06:21,490
So right now, with the change we just made to the do request function.

112
00:06:21,760 --> 00:06:27,040
We're going to essentially receive the event object as this props argument and then merge it into the

113
00:06:27,040 --> 00:06:27,790
request body.

114
00:06:28,180 --> 00:06:33,130
So we are trying to take an event and send it off as a request body, which is why we're seeing that

115
00:06:33,130 --> 00:06:33,850
nasty air.

116
00:06:34,630 --> 00:06:35,320
But it picks us up.

117
00:06:35,440 --> 00:06:37,540
All we can do is go back over to our ticket show.

118
00:06:40,120 --> 00:06:43,540
Finally on Klick, we're going to wrap that with an arrow function.

119
00:06:44,110 --> 00:06:47,770
So now, even though this does get called with an event object, we're not going receive it.

120
00:06:47,830 --> 00:06:50,410
We're not going to pass it through to do request or anything like that.

121
00:06:51,370 --> 00:06:51,570
OK.

122
00:06:51,650 --> 00:06:52,450
Such a fix there.

123
00:06:52,540 --> 00:06:53,350
So let's say this.

124
00:06:54,700 --> 00:06:55,700
I to flip back over.

125
00:06:56,450 --> 00:06:57,530
I'm going to create an order.

126
00:06:58,220 --> 00:06:58,700
There we go.

127
00:06:59,180 --> 00:07:00,050
I'll pay with my card.

128
00:07:01,380 --> 00:07:03,090
Or two for two, for two, for two.

129
00:07:04,950 --> 00:07:05,840
A 20 dollars.

130
00:07:08,000 --> 00:07:11,800
And we should make a request to our payment and point their dues payments.

131
00:07:12,440 --> 00:07:16,580
Now, we have purchased this order or at least provided some payment in theory.

132
00:07:17,300 --> 00:07:21,320
Now, just so you know, if we now do any follow up payments, it is extremely likely they will end

133
00:07:21,320 --> 00:07:24,860
up see an error because the payment service will probably say something like, hey, that order has

134
00:07:24,860 --> 00:07:25,670
already been paid for.

135
00:07:25,700 --> 00:07:26,630
Or something like that.

136
00:07:27,350 --> 00:07:28,140
We can verify.

137
00:07:28,190 --> 00:07:29,780
Make sure that the payment has been processed.

138
00:07:29,810 --> 00:07:31,010
If we go back over to scaffold.

139
00:07:32,720 --> 00:07:36,350
Back inside of that scaffold, we could take a look at these series of events that have been emitted

140
00:07:36,380 --> 00:07:41,570
and received and try to pass or get an idea of the series of actions that just went on behind the scenes.

141
00:07:42,470 --> 00:07:46,670
So first off, it looks like that right there is probably where we initially created the order.

142
00:07:47,210 --> 00:07:48,740
We published an order create events.

143
00:07:49,340 --> 00:07:51,500
The expiration service started up a timer.

144
00:07:52,220 --> 00:07:56,510
Then the payment service received that and knew that it needed to start to watch for an incoming payment

145
00:07:56,510 --> 00:07:57,290
for that order.

146
00:07:58,910 --> 00:08:01,580
Later on, it looks like we had a ticket updated.

147
00:08:01,670 --> 00:08:05,240
So that's where we successfully reserve the ticket by setting its order I.D. property.

148
00:08:06,370 --> 00:08:10,570
It looks like the order service itself got acknowledgment that the ticket was reserved.

149
00:08:11,670 --> 00:08:13,110
Then a little bit later.

150
00:08:13,140 --> 00:08:15,390
And these two events for me right here are out of order.

151
00:08:15,810 --> 00:08:17,630
This is where we submitted the payment.

152
00:08:18,090 --> 00:08:21,120
So the payment service, alleged events say that the payment was created.

153
00:08:21,600 --> 00:08:23,730
The order service received that event.

154
00:08:23,790 --> 00:08:28,440
And so at that point time, it marked that order as probably being paid for or completed.

155
00:08:28,500 --> 00:08:29,400
I think is what we called it.

156
00:08:31,350 --> 00:08:34,800
Then a little bit later, once again, out of order right here, I see expiration.

157
00:08:35,690 --> 00:08:36,110
Complete.

158
00:08:36,400 --> 00:08:39,490
So that's where our expiration service says, hey, it's been 60 seconds.

159
00:08:39,520 --> 00:08:40,900
Hopefully this thing has been paid for.

160
00:08:41,200 --> 00:08:45,220
And it looks like the order service received that and said, oh, well, this order has already been

161
00:08:45,220 --> 00:08:45,680
paid for.

162
00:08:45,700 --> 00:08:47,970
So I don't have to worry about canceling it or anything like that.

163
00:08:49,150 --> 00:08:54,490
All right, let's say it looks pretty good now just to confirm, if we do go back over and tried to

164
00:08:54,580 --> 00:08:56,290
repurchase this ticket again.

165
00:08:56,410 --> 00:08:57,180
So here's the ticket.

166
00:08:57,230 --> 00:08:59,320
If I click on purchase, I probably see something.

167
00:08:59,320 --> 00:09:00,940
It says ticket is already reserved.

168
00:09:01,390 --> 00:09:03,070
So this is the ticket I just paid for.

169
00:09:03,280 --> 00:09:05,800
It's never going to become unreserved or anything like that.

170
00:09:06,430 --> 00:09:10,660
So we should probably figure out some way of maybe filtering this list right here and only show tickets

171
00:09:10,660 --> 00:09:11,410
that are available.

172
00:09:11,830 --> 00:09:15,430
We're alternately we could just mark tickets that have already been purchased on this list as well.

173
00:09:15,610 --> 00:09:16,270
Something like that.

174
00:09:16,270 --> 00:09:19,210
Something does make it really clear which tickets we can still purchase.

175
00:09:20,170 --> 00:09:21,670
Well, I think we saw a little bit of work to do.

176
00:09:21,760 --> 00:09:23,140
So let's get to it in just a moment.