Optional redirect_to parameter

[teghoz]

Users are suppose to redirect to a specified url after completing instructions on their bank pages. Since there was no specified return_url on this documentation - https://developers.paystack.co/v1.0/reference#charge, i was forced to reach out to them about how to redirect back to the referred page. They referred me to this documentation - https://developers.paystack.co/docs/charging-from-your-backend.

So i think the charge return_url should be set on the initial charge request. What do you think? I would have created a pull request but since you say its faster from your end..................................

[adebisi-fa]

Hello @teghoz,

The documentation here, says:

You can specify an optional url to which we should redirect the user after the attempt is complete by adding redirect_to=[url] as a GET parameter.

This could mean that the redirect_to GET param:

1. should be specified when creating a ChargeRequest; OR

2. should be appended to the data.url returned when the data.status is open_url, which the user will then browser to, to make payment.

Looking at it further shows that it could be more of Option 2, as there isn't any return_url in the body parameters for ChargeRequests.

However, it appears the after the [user] attempt is completed, meant "when the user has finished payment using the computed url" (i.e. data.url with the redirect_to=[any_url] GET params appended).

What do you think?

[adebisi-fa]

On ". . . [issue updates being] . . . faster from [my] end"

Never meant that actually. In the context of the changes in your first pull request, and the review made on those code, I felt it would be faster for us, if I made the changes here (especially since there are other wrist-friendly addition I intend adding to make the overall experience better).

THIS WILL SURELY NOT APPLY TO ALL FUTURE PULL REQUESTS! So, please, do send in pull request as the case may be.

Thanks, please.

[teghoz]

Sure. No its cool. So far objectives are met. its totally fine. Please keep up the good work

[teghoz]

However, it appears the after the [user] attempt is completed, meant "when the user has finished payment using the computed URL" (i.e. data.url with the redirect_to=[any_url] GET params appended).

What do you think?

As regards the aforementioned. I don't think assigning the URL on the object does anything. Because we don't perform any request at that point back to the end point. So how would Paystack know that it has to redirect back to URL it does not know. This makes me come to my conclusion that it must be the first option on the charge request. At least it would have already known the expected return URL. So how does this library handle that by the way?

[adebisi-fa]

Hello @teghoz,

Can you please proceed with adding a RedirectTo (redirect_to) property to the BankChargeRequest DTO, from your end, then test the build to be sure it fix your scenario? We could update this repo, and eventually nuget, afterward, if everything is fine.

What do you think, please?

[teghoz]

@adebisi-fa Hi so what is the way forward on this issue?

[adebisi-fa]

Hi @teghoz,

I already suggested this:

. . . please proceed with adding a RedirectTo (redirect_to) property to the BankChargeRequest DTO, from your end, then [try out] your build to be sure it fix your scenario.

We can then update the repo, if your build fix the issue.

Hope this helps.

[adebisi-fa]

Hello @teghoz,

I'll be closing this issue, for now, as it appears it has somehow been resolved.

Regards, please.

- Foluso