So last time I said that I would talk about the ignored first return value, when you call refund knew
from strike, and I never did that.
So let's look over the documentation.
And this is the documentation we were looking at last time.
And, of course, strip refund programs is passed to refund new and that returns are and they don't
talk about our here at all.
But if you go to the API reference and look at the refund object by clicking on refund object here,
it actually describes what you get back from the refund.
Now, all of this information might be useful in certain situations, but we're not using any of it.
I just wanted to let you know what kind of information you're getting back in the refund in case you
need to do something with it at some point in the future.
All right.
Let's go back to work.
So we've written this refund function inside the cards package.
And, of course, we need to have a handler on our API that calls this to process a refund.
So let's go to our API folder and open the handlers.
And here I'll just go to the very bottom.
And I'll create a new handler to process a refund, so thank receiver Appointer to application and I'll
call it refund charge and it's a handler.
So we give it a response writer and it's pointed to a request.
Now, this is going to receive Jason and I'm going to assume we're getting certain information here,
so I'll create a variable charge to refund and it will be a struct and it will have the following fields.
First of all, it's going to have an ID to be an integer.
And in Jason, I'll call that ID and that will be the ID of the order.
We want to refund, but we'll have payment intent, which we need to do a refund and that's a string.
And in Jason, I'll just call that t'ai for payment intent.
We'll also have the amount.
Now, this is optional.
If you don't specify an amount when you do a refund, then the full amount of the underlying charge
will be refunded.
But at some point you might want to do a partial refund.
So that's why I included it in the cards package.
In the refund function.
They're all included here as well.
It will be an integer and in JSON, I will call that amount.
And finally, what currency is it, so that'll be a string and in JSON we'll call that currency and
again, we're not using that with our refund function, but at some point you might be supporting multiple
currencies.
So you may as well put it in here right now and plan for the future.
Now, at this point, I would actually do something that I'm not going to bother doing right now.
I would validate the amount against the underlying order.
So I would call the database with the ID for the order, look up the amount, compare the amount that's
in the database with the amount that's specified in this JSON payload, and make sure that, first of
all, the amount I'm trying to refund isn't greater than the amount.
And secondly, that maybe that they're equal, whatever logic you want to implement there.
Now, I'm not going to bother doing that because that's trivial and you should have no difficulty doing
that on your own.
And also, the refunds here are all coming from a secure back end.
And the only person that can has access to that is the authorized user, in our case, admin at example,
dot com.
So I'm going to assume that admin at example dot com is an honest person and isn't going to try to cheat
himself now will create a card from our cards package.
We're going to call cards dot card and specify its fields.
So the secret that's equal to abduct config,
dot, strike, dot secret the key which we don't use.
But I put it in there because I might at some point in the future, abduct config, dot straight dot
key and the currency which is charge to refund the currency.
So that gives me my card variable and now I can call all the methods on it.
We also of course, have to read our Jason into that variable.
So error is assign the value of APT JSON and we hand it W r and we're reading into charge to refund
and we check for an error.
If error is not equal to nil, then apt bad request or an error and return.
Don't go any further.
So we have our variable we've read our Jason and populated a variable, optionally we can do some validation
here and now we've created a code variable, so let's try to refund it.
Error is sign the value of or is equal to her refund.
And it requires the payment intent, which is charged to refund payment intent, and it requires the
amount charged to refund that amount.
And again, we check for an error.
So I'll just copy this code
and paste it here and now.
Everything probably went all right.
So we'll create a response variable resp to disrupt and it has an error field, which is a ball.
And in JSON that's called error and it has a message which is a string.
And in JSON we call that message.
Now, I've never done anything with message here, but I put that in because when you're writing your
code, you may want to specify some kind of message and send it back.
OK, so we'll specify one here just for fun.
So restaurant error is equal to defaults because there are no errors and the message is equal to charge
refunded.
And we write Jason Topdog.
Right, Jason.
And that requires some status of status.
OK, and the response.
So there's our handler.
And now, of course, we need to set up a route for it.
So let's go to Root Stasch API and write down here in the protected section because this is a protected
route post and we'll just call it slash admins or API slash admin refund and we'll call the handler
after a refund charge.
OK, so we have our cards logic in place to do a refund.
We have a handler to call that kurds' package and then we have a root to the handler.
So now we need to go update our front end code to call that route, which fires off the handler and
does the refund.
And we'll get started on that in the next lecture.