1
00:00:01,240 --> 00:00:05,310
Our request handler is looking great and we've got some tests around creating a new charge.

2
00:00:05,330 --> 00:00:07,100
So what's next.

3
00:00:07,100 --> 00:00:10,540
Well I want to point out that there's kind of a gap inside our application right now.

4
00:00:10,700 --> 00:00:16,490
At this point time after we create a charge on the stripe API we don't really have any way of relating

5
00:00:16,500 --> 00:00:19,760
an order to a charge at some point time in the future.

6
00:00:19,790 --> 00:00:24,140
In other words after we create the actual charge we don't have any kind of data structure that we could

7
00:00:24,140 --> 00:00:30,440
come back to and say a day a month a week a year and say Hey did someone pay for this order.

8
00:00:30,440 --> 00:00:35,310
So we're gonna start to create a new collection inside of our payment service inside this collection.

9
00:00:35,330 --> 00:00:37,570
We're gonna store a list of different payments.

10
00:00:37,580 --> 00:00:43,640
The only goal of a payment is to relate an order and a charge that we created on the stripe API.

11
00:00:44,300 --> 00:00:48,410
So this is a collection that were going to use to keep track of which orders have actually been paid

12
00:00:48,410 --> 00:00:49,240
for.

13
00:00:49,430 --> 00:00:54,500
You and I are not really going to make use of this payments model at any point time inside of her app.

14
00:00:54,530 --> 00:00:56,240
So in other words we're not really going to read from it.

15
00:00:56,240 --> 00:00:59,110
We're not really going to show any information from it or anything like that.

16
00:00:59,120 --> 00:01:02,990
I'm only showing you how to create this payments collection in case you want to build something the

17
00:01:02,990 --> 00:01:08,330
future like say a dashboard to show your users a list of all the orders that they have successfully

18
00:01:08,330 --> 00:01:10,100
paid for or something like that.

19
00:01:12,530 --> 00:01:17,300
So this is going to require us to build up a new Mongoose model and then any time that we create a charge

20
00:01:17,810 --> 00:01:19,130
inside of our request handler.

21
00:01:19,160 --> 00:01:24,140
So essentially it right here right after that we're going to create a new payment object and it's just

22
00:01:24,140 --> 00:01:26,680
going to say that for a given order we have paid for it.

23
00:01:26,690 --> 00:01:30,070
And here's the I.D. of the stripe charge.

24
00:01:30,170 --> 00:01:31,370
That's pretty much it.

25
00:01:31,410 --> 00:01:34,070
So we'll be a pretty simple and straightforward thing to put together.

26
00:01:34,190 --> 00:01:36,240
So let's get started on it right away.

27
00:01:36,410 --> 00:01:41,960
Inside my model's directory I'm gonna make a new file of payment dot t yes at the very top.

28
00:01:41,970 --> 00:01:51,220
We will import Mongoose as usual we'll then create our three interfaces so a payment adders

29
00:01:54,200 --> 00:02:03,770
a payment dock that is going to be extending Mongoose dot document and then a payment model and that's

30
00:02:03,770 --> 00:02:07,320
going to extend Mongoose dot model.

31
00:02:07,470 --> 00:02:12,550
It is a generic we'll stick in payment dock Oh a little typo.

32
00:02:12,550 --> 00:02:13,790
There we go.

33
00:02:15,490 --> 00:02:17,740
Let's start off first with our payment adders interface.

34
00:02:17,740 --> 00:02:20,230
What properties are we going to provide to a payment.

35
00:02:20,230 --> 00:02:26,350
Like I said the only real goal of this payment object is to tell us about or to somehow relate together

36
00:02:26,560 --> 00:02:29,700
an order and a charge that is pretty much it.

37
00:02:29,710 --> 00:02:32,440
So on the payment object we're just going to store it.

38
00:02:32,440 --> 00:02:37,460
The idea of the order that we'll also store the idea of the charge.

39
00:02:37,570 --> 00:02:38,890
That's all we're going to store.

40
00:02:38,930 --> 00:02:42,400
So it's just gonna relate these two things together and is going to be the presence of this payment

41
00:02:42,400 --> 00:02:47,650
that indicates that we have successfully paid for a given order so on a payment adders right here.

42
00:02:47,660 --> 00:02:59,870
I'll say that this thing has a voter I.D. That is a string and a stripe I.D. That is a string.

43
00:02:59,920 --> 00:03:04,420
Next up on the payment dock interface of the this is give me the list of properties that a payment has

44
00:03:04,750 --> 00:03:05,920
pretty much just the same thing.

45
00:03:05,920 --> 00:03:13,100
So order I.D. That is a string and stripe I.D. That is a string as well.

46
00:03:13,170 --> 00:03:16,130
Now do we want a payment to have a version number.

47
00:03:16,140 --> 00:03:19,320
Should this thing have a version for keeping track of all that concurrency stuff.

48
00:03:19,890 --> 00:03:22,760
Well I would say in general yes probably.

49
00:03:22,830 --> 00:03:27,840
But for our application we're essentially creating a payment one time and then never updating it never

50
00:03:27,840 --> 00:03:30,530
changing any properties tied to it whatsoever.

51
00:03:30,540 --> 00:03:34,470
The whole idea of a version number was really to keep track and make sure we processed events in the

52
00:03:34,470 --> 00:03:40,290
correct order as a given record changed because our payment record is never going to change because

53
00:03:40,290 --> 00:03:43,320
it's really just got that order I.D. and stripe I.D. and that's it.

54
00:03:43,320 --> 00:03:49,140
I really don't need a version number because this thing simply isn't going to change over time and I'm

55
00:03:49,140 --> 00:03:53,940
never going to expect to have to emit new events and have to make sure that they are processed in some

56
00:03:54,000 --> 00:03:55,320
given order.

57
00:03:55,350 --> 00:03:58,390
So in this case no version is really required.

58
00:03:58,390 --> 00:04:03,090
Now having said that it I would say that it is good practice to just include a version everywhere for

59
00:04:03,090 --> 00:04:04,000
every record.

60
00:04:04,080 --> 00:04:07,950
Even if you don't think you're going to need it right away because you might need it at some point time

61
00:04:07,980 --> 00:04:12,150
in the future and if you decide to add it in the future well that means you got to go around to all

62
00:04:12,150 --> 00:04:16,100
your different events related to this record and add in that version property.

63
00:04:16,140 --> 00:04:19,970
So this is really up to you but in the case of this application I know that I'm not going to make you

64
00:04:19,970 --> 00:04:24,730
sort of diversion property so I'm just not going to include it.

65
00:04:24,780 --> 00:04:26,700
So then finally onto our payment bottle.

66
00:04:26,900 --> 00:04:32,120
As usual we're gonna say this thing has a build property or build method that's gonna receive some adders

67
00:04:32,180 --> 00:04:38,030
of type even adders and it's going to give back to us a payment.

68
00:04:38,040 --> 00:04:45,190
Doc less than three our schema so I'll make a payment schema.

69
00:04:45,350 --> 00:04:51,050
This will be a new Margo's schema and then inside of here we'll say this thing is going to have an order

70
00:04:51,060 --> 00:05:00,140
I.D. It is required and its type is going to be string with a capital S and then a stripe idea as well.

71
00:05:01,210 --> 00:05:05,290
Required and its type will also be string with a capital S

72
00:05:09,050 --> 00:05:09,490
as usual.

73
00:05:09,500 --> 00:05:11,840
We will also define that transform property.

74
00:05:11,840 --> 00:05:14,750
Make sure we strip off that I.D. all that kind of stuff.

75
00:05:15,810 --> 00:05:16,960
Does the second argument right here.

76
00:05:16,970 --> 00:05:18,420
We'll put in Transformers.

77
00:05:18,440 --> 00:05:19,900
Me too Jason.

78
00:05:19,940 --> 00:05:20,680
There we go.

79
00:05:20,690 --> 00:05:28,240
Transform this thing we'll be called with our documents and the return value.

80
00:05:28,330 --> 00:05:34,780
And as usual we'll set red dot I.D. equal to Red Dot underscore I.D. and then we'll delete off the red

81
00:05:34,780 --> 00:05:36,640
dot underscore I.D. property

82
00:05:39,540 --> 00:05:42,380
yet nothing too surprising so far.

83
00:05:42,610 --> 00:05:51,970
Now we've got our scheme up but together we're going to define the build method on their so define payment

84
00:05:52,390 --> 00:05:55,930
schema dot statics dot build

85
00:05:59,350 --> 00:06:05,380
this will be a function that takes in some attributes of type event actors and then we will return a

86
00:06:05,380 --> 00:06:12,280
new payment and we'll take all those actors and just essentially pass them through

87
00:06:16,320 --> 00:06:20,680
yet and then finally we'll create the actual payment model at the very bottom and then export it.

88
00:06:20,780 --> 00:06:24,900
So payments is Mongoose dot model

89
00:06:28,070 --> 00:06:32,370
beat in the payment schema let's not forget that this thing is a generic.

90
00:06:32,380 --> 00:06:37,780
So we're gonna specify as well our payment Doc and the payment model interfaces

91
00:06:42,630 --> 00:06:47,270
and then at the very bottom we can finally export these payment model itself to experts.

92
00:06:47,550 --> 00:06:47,850
Payment

93
00:06:51,230 --> 00:06:57,700
and that's pretty much it now that we've got this thing put together back inside of a handler.

94
00:06:57,720 --> 00:07:02,730
Right after we create our charge we cannot create a new instance of a payment and save it to our database.

95
00:07:02,730 --> 00:07:06,560
And again the whole goal this thing is to just say yeah we pay for the given order.

96
00:07:06,630 --> 00:07:12,240
Now at some point time in the future we could do a look up or say a given order I.D. and decide whether

97
00:07:12,240 --> 00:07:14,610
or not that order has been paid for.

98
00:07:14,640 --> 00:07:17,970
Let's take a pause right here and implement that last little step in the next video.