So this time around, what we want to do is to start to work on converting our virtual terminal page
from a form submission to the front end to instead a submission to a protected route on the back end
of the API.
So what I'll do, first of all, is create a route to a non-existent handler and I'm in my reach Dash
API Dutko and I'm inside that mux route.
We created a couple of lectures ago and what I'll do is create a route called Muxtape Post and it will
go to API slash admin, which comes from line 30, as you'll recall.
And we're going to go this time to slash virtual dash terminal.
Dash succeeded
and then we'll go to a existent handler, which will be from a receiver app and I'll just call it virtual
terminal payment succeeded, which is the same thing we called it on the front end.
So now let's go over to our handlers, dash API and start working on that and will be similar to but
not exactly the same as what we have in the front end.
So I'll create a function here with a receiver app pointer to application and I will call that virtual
terminal payment succeeded and it's a handler, so it needs a response writer and a pointer to a request.
Now we're not going to handle a form post.
What we'll do is actually send JSON as the body of the post request from the front end.
So we need someplace to store that.
So I'll do is just create a variable, a struct var talks and data, which is what we called it on the
front end.
But I'll make this a struct and you can of course create your own type if you want to, but I'll just
do it right in here so I know I'm going to have payment amount and I'm going to take that as an input
from the JSON file and in JSON I'll expect that to be called Jason Amount.
And I'm also going to have the currency payment currency, which will be a string, and in JSON we'll
call that currency.
And I'm also going to have the first name, which will be a string, and Jason will call that first
name.
Now, in the virtual terminal may not actually use that, but it's not going to hurt us to put it in
there.
And we'll have the last name, which is Strength and JSON.
I'll call that last name.
And we're also going to have the email, which is your strength.
And Jason, that's called email and the payment intent, which is actually a payment ID, but I'll call
it payment intent and that'll be a string.
And Jason, that'll be called payment, underscore or spelt right.
Underscore intent and the payment method, which again is an ID Jason payment underscore method.
And I'll have the bank return code, we're not getting that from Jason, but we'll be using it shortly.
As you'll see, we're not getting that from the Jason posted with this.
In other words, bank return code.
And I got to put the word code after that and a type.
OK, we're also going to need the expiry month
and that is going to be an inch.
And and in Jason, we'll call the expiry exp expiry month and I'll duplicate that and do the same thing
for a year.
Again, expiry year.
And the last four digits, which will be in the form of spring, which is how we get it from Stripe,
Jason, last for some of this, we're getting posted to us and some of it we're not and will be populating
this transaction data later on to send it back as the response from this handler.
Now, I'm going to do everything in this handler right now.
And of course, if you want to extract these two shorter functions or methods, you feel free to do
so.
But let's get this going.
OK, so we're getting a posted, Jason.
And as we know, we can use our built-In helper from the app receiver called Jason.
And we're going to read W and are the first two required parameters and then we're going to read into
some data.
So if this succeeds, then our variable text and data is populated with everything that was posted to
us.
But there might be an error.
So we'll check for error is not equal to nil.
Then all I'm going to do right now is say Abdon, bad request.
And that requires the response writer, the reader and the error.
And I'll return at this point because I don't want to go any further.
And if we get past that, what we need to do, of course, is to to take advantage of our cards, packages
or a variable called card.
And that's equal to cards dot card.
And we populate its parameters secret with app, dot config, dot stripe, dot secret and it's key with
the config dot straight dot key.
Now we have that variable and we can take advantage of all of its functions.
So first of all, we'll get our payment and content will retrieve that.
So pie for payment, intent and error.
Those are assigned the value of the card to retrieve payment intent and all that requires user and data
payment intent.
And again, we check for an error.
And I'm just going to copy this because I'll be using it periodically through the remainder of this
election, so I'll pass that in there.
Now we have our payment intent.
The next thing we want to do is pretty much the same thing we did on the front end, and that's to get
the payment method, payment method and error or assign the value of card.
And what we call here is get payment method and we hand it and data
payment method.
And again, we check for an error.
So now we can populate some of the fields that were not populated in our time in data variable.
So to and data last for we have that now that's going to be equal to pm dot card dot last for.
And we also have the expiry month fix and data that expiry month and that will be equal to.
And we have to cast this to an end because it comes as you in sixty four p.m. the third month and I
can duplicate that and get the year expiry year in.
This becomes a year.
Now we create a new transaction, just like we did on the front end.
And actually, if I want to, I can go and copy that information, but I'll just type it out here because
there's not very much.
So we'll create a transaction variable.
It's a type models dot transaction.
I just populate its members.
So amount that will be equal to tax and data.
Amount of capital, the
payment amount.
So we need the amount, we need the currency and that's and DataDot payment currency.
We need the last four, which is now tax and data.
Last fall, we need the expiry month and that's tax and data date expiry month and we need the expiry
year.
So I'll just duplicate that and change this tier and change this tier.
And not many more when his bank returned home.
And that comes from, if you recall, PPI or payment intent charges,
DOT data index zero.
And finally, the transactions data.
And we're just going to hard code that to two, which means cleared.
So once we have that popularity, we just save the transaction.
So I don't care about the ID.
I do care about the error.
And those are equal to after the transaction.
And I give it my transaction that I just created.
And again, we check for an error so I can just copy this code.
Paste it in here, and if there is no error at that point, we just returned some Jason.
So what we're going to do is tap right, Jason?
And it requires our response writer some status of status, OK?
And the data which is taken and that should be sufficient.
So if we go back to our roots for the API, our error should be gone because that handler now exists.
OK, so if we did everything right, that's the backend we receive posted Jason.
We process it as required and we send back our response.
So in the next lecture, we'll go modify the front end to instead of posting to the front end, we'll
have it send a post request in the form of Jason to the route we just to find here on line thirty seven
of rootstock API.
So we'll get started on that in the next election.