Back inside of our handler right after we create this charge then going to take the response so we get
back.
That's gonna be an object that tells us some details about the charge that was created.
We're gonna take the I.D. out of that thing and then use it to create a new payment record to get started
at the very top.
This file I will import the payment model from up one directory models payment then back down.
Right after we create that charge let's take a look at our documentation really quickly just to understand
what comes back when we create a charge because I keep on saying oh yeah we get back something that
represents the charge but again let's just look at the docs really quick all right so back on the stripe
API docs can take a look at creating a charge and we could see the response we get back right here.
So it's gonna be this big object that has a lot of information about the charge that was created and
very simply you'll notice it has that I.D. property that's pretty much it.
That's what we want to store.
Once we store that I.D. if we ever want to look up this charge at some point the future we could use
this retrieve a charge endpoint or the stripe client.
So we would do a stripe charges retrieve put in the idea right there and that would give us the full
charge object.
And so that's how we could retrieve a charge potentially at some point on the future if we needed to
look up any further details about it.
So that entire big response is going to come out of this create call don't receive that as a variable
called charge and then immediately after all build up a new payment that'll be a payment billed going
to pass in the order I.D. as ordered i.e. and actually we do not have an order I ordered dot I.D. property
we've got just the order I.D. itself which actually suits pretty well for our uses open and just order
I.D. and then our stripe I.D. is charge dot I.D. then after creating the payment we'll do it in a wait
a minute dot save.
Well that's pretty much it.
Not the worst thing in the world now as usual.
It'd be fantastic to write out a real quick test around this.
Let's go back over to our root handler test file.
There it is right here I think we could put together a test for this very very quickly.
As a matter of fact we'll just reuse the test we already put together.
So at the very top I will import the payment model from up to directories models payment I'll then go
down to the most recent test we put together that is the success case on right here and we'll just add
in an additional expectation to this thing.
So at the very bottom of the test after we make sure that the stripe charge was actually created let's
take a look in our payment collection and just make sure that a payment was actually created and saved
with a given stripe I.D. or alternately with a given order I.D. either one would be fine so I will do
a payment is a wait payment not find a one they'll try to find one payment saved to the payment collection.
And how about we tried to find a payment with the I.D. equal to these stripe charges I.D. and they give
an order idea as well that'll really make sure that we save the payment with all the correct details
so I can say that I want to find a payment with this order I.D. order.
I.D. and with a stripe I.D. of Stripe charge that I.D. once again you'll notice we get an ID right there
because this thing might be undefined.
We're gonna say typescript don't sweat it because you're really checked for the existence of that variable
right there
after that we write out in expectation to make sure that we actually found a payment.
Now there is a real small gotcha here.
You'll notice that on the last step when we looked up all of our different charges tried to find a given
charge the actual expectation we wrote out was expect this thing to be defined.
The reason we use the to be defined matter was that when we use the fine method right here we are they're
going to get the record we were looking for or a value of undefined to be defined match or itself.
Checks to see that a value is not undefined specifically the value not undefined in the case of payment
right here.
If we are not able to find a payment with the given filters rather than being given undefined we get
a value of null null and undefined are two different things.
So if we expect payment to be defined this will always evaluate successfully or truthfully.
In other words we will not fail to matter because the payment variable is either going to be the payment
we are looking for or it will be a value of No.
And both those are going to pass this expectation because again this thing is looking for a value to
be undefined because payment is either going to be a payment ordinal we need to specifically say that
we expect a thing not to be.
No.
We're gonna update that matter and say that we expect payment not to be.
No.
Like so yes let's now save that we'll back over to our terminal
and back over here.
It looks like we are good to go as usual.
Let's make this test fail so I will flip back over.
Let's go back over to our request handler and we'll just comment out the line where we tried to actually
save the payment outcome and that out save the file.
And now we will expect something to come up and say Hey sorry about this value is actually know when
you expected it wouldn't be.
And there we go.
Looks good like going to Uncle Matt that save it again.
And we are all set.
All right.
So we have created the charge.
We have saved a record that relates the charge Andi ordered together.
And the last thing we really had to do inside of Europe beyond responding with some more meaningful
value than what we have right here less than we really have to do is make sure we publish an event to
say that well we created a charge or we create a payment or something like that.
Let's take a pause here and build up that publisher and the event definition in the next video.