Our request handler is looking great and we've got some tests around creating a new charge.
So what's next.
Well I want to point out that there's kind of a gap inside our application right now.
At this point time after we create a charge on the stripe API we don't really have any way of relating
an order to a charge at some point time in the future.
In other words after we create the actual charge we don't have any kind of data structure that we could
come back to and say a day a month a week a year and say Hey did someone pay for this order.
So we're gonna start to create a new collection inside of our payment service inside this collection.
We're gonna store a list of different payments.
The only goal of a payment is to relate an order and a charge that we created on the stripe API.
So this is a collection that were going to use to keep track of which orders have actually been paid
for.
You and I are not really going to make use of this payments model at any point time inside of her app.
So in other words we're not really going to read from it.
We're not really going to show any information from it or anything like that.
I'm only showing you how to create this payments collection in case you want to build something the
future like say a dashboard to show your users a list of all the orders that they have successfully
paid for or something like that.
So this is going to require us to build up a new Mongoose model and then any time that we create a charge
inside of our request handler.
So essentially it right here right after that we're going to create a new payment object and it's just
going to say that for a given order we have paid for it.
And here's the I.D. of the stripe charge.
That's pretty much it.
So we'll be a pretty simple and straightforward thing to put together.
So let's get started on it right away.
Inside my model's directory I'm gonna make a new file of payment dot t yes at the very top.
We will import Mongoose as usual we'll then create our three interfaces so a payment adders
a payment dock that is going to be extending Mongoose dot document and then a payment model and that's
going to extend Mongoose dot model.
It is a generic we'll stick in payment dock Oh a little typo.
There we go.
Let's start off first with our payment adders interface.
What properties are we going to provide to a payment.
Like I said the only real goal of this payment object is to tell us about or to somehow relate together
an order and a charge that is pretty much it.
So on the payment object we're just going to store it.
The idea of the order that we'll also store the idea of the charge.
That's all we're going to store.
So it's just gonna relate these two things together and is going to be the presence of this payment
that indicates that we have successfully paid for a given order so on a payment adders right here.
I'll say that this thing has a voter I.D. That is a string and a stripe I.D. That is a string.
Next up on the payment dock interface of the this is give me the list of properties that a payment has
pretty much just the same thing.
So order I.D. That is a string and stripe I.D. That is a string as well.
Now do we want a payment to have a version number.
Should this thing have a version for keeping track of all that concurrency stuff.
Well I would say in general yes probably.
But for our application we're essentially creating a payment one time and then never updating it never
changing any properties tied to it whatsoever.
The whole idea of a version number was really to keep track and make sure we processed events in the
correct order as a given record changed because our payment record is never going to change because
it's really just got that order I.D. and stripe I.D. and that's it.
I really don't need a version number because this thing simply isn't going to change over time and I'm
never going to expect to have to emit new events and have to make sure that they are processed in some
given order.
So in this case no version is really required.
Now having said that it I would say that it is good practice to just include a version everywhere for
every record.
Even if you don't think you're going to need it right away because you might need it at some point time
in the future and if you decide to add it in the future well that means you got to go around to all
your different events related to this record and add in that version property.
So this is really up to you but in the case of this application I know that I'm not going to make you
sort of diversion property so I'm just not going to include it.
So then finally onto our payment bottle.
As usual we're gonna say this thing has a build property or build method that's gonna receive some adders
of type even adders and it's going to give back to us a payment.
Doc less than three our schema so I'll make a payment schema.
This will be a new Margo's schema and then inside of here we'll say this thing is going to have an order
I.D. It is required and its type is going to be string with a capital S and then a stripe idea as well.
Required and its type will also be string with a capital S
as usual.
We will also define that transform property.
Make sure we strip off that I.D. all that kind of stuff.
Does the second argument right here.
We'll put in Transformers.
Me too Jason.
There we go.
Transform this thing we'll be called with our documents and the return value.
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
dot underscore I.D. property
yet nothing too surprising so far.
Now we've got our scheme up but together we're going to define the build method on their so define payment
schema dot statics dot build
this will be a function that takes in some attributes of type event actors and then we will return a
new payment and we'll take all those actors and just essentially pass them through
yet and then finally we'll create the actual payment model at the very bottom and then export it.
So payments is Mongoose dot model
beat in the payment schema let's not forget that this thing is a generic.
So we're gonna specify as well our payment Doc and the payment model interfaces
and then at the very bottom we can finally export these payment model itself to experts.
Payment
and that's pretty much it now that we've got this thing put together back inside of a handler.
Right after we create our charge we cannot create a new instance of a payment and save it to our database.
And again the whole goal this thing is to just say yeah we pay for the given order.
Now at some point time in the future we could do a look up or say a given order I.D. and decide whether
or not that order has been paid for.
Let's take a pause right here and implement that last little step in the next video.