search

thephpleague / omnipay

A framework agnostic, multi-gateway payment processing library for PHP 5.6+
http://omnipay.thephpleague.com/
MIT License
5.92k stars 928 forks source link

POST Redirect Could do with Being Templated #198

Open judgej opened 10 years ago

judgej commented 10 years ago

Just trying out omnipay with and found Helcim running with AuthorizeNet_SIM. The POST redirect page looked pretty fugly, being unstyled.

It would also help to be able to provide more information on the POST redirect page about what that page is for in case the redirect does not work or the remote payment gateway site is slow to respond.

On top of that, the page is in English, and not translated.

Anyway, the redirect page is all hard-coded in Omnipay\Common\Message\AbstractResponse ::getRedirectResponse()

I think that HTML needs to be easily overridable. Since omnipay is not using DICs that would allow us to swap in an overridden version of that class, the template could should at least be put into a property that can be overridden.

Okay, PSR4 can in theory allow you to override any class you like, just by registering your own version in the same namespace before the core omnipay package is registered with composer, but that's a tricky thing to do.

So, does the POST redirect page need some templating love?

judgej commented 10 years ago

I realise that getRedirectResponse() provides the HTML for redirecting, and you don't have to use it at all (you can build your own). But my point is that often just a few small tweaks are what is needed. For example, the current HTML does an auto-submit of the POST form. There is no option to disable that auto-submit, which makes it difficult to work with when developing.

sanderha commented 8 years ago

Any updated on this?

Is it possible in someway to hide the redirectpage, or does it have to be a self-submitting form?

judgej commented 8 years ago

The option to construct your own redirect page is always there. It would be great not to have to, but if you want to give the redirect page your own branding (since it will flash up even if momentarily) then you you have to write your own.

sanderha commented 8 years ago

I see. So it has to use a html self-submitting form to post the data? Would it be possible to skip a visible redirect by using php cURL or something?

judgej commented 8 years ago

There are different gateways that need different types of redirect. A page to auto-POST a form is just one method, so not all gateways will need it. The logic for it is here:

https://github.com/thephpleague/omnipay-common/blob/master/src/Omnipay/Common/Message/AbstractResponse.php#L170

This is used when getting a response from OmniPay that requires a redirect to the remote gateway, i.e. for the user to be sent to the gateway using their browser. There is no way around that - the user MUST go to that remote site. Some redirects used GET, and they are easy to do with a HTTP redirect (unless going from local SSL to remote non-SSL, which should never happen). Some gateways require the user to be sent there with POST data. That can only happen in a browser by submitting a form.

The POST can all live in an iframe, but the issue is the same - if a POST is expected by the remote gateway, then a form has to be constructed and submitted using JavaScript on behalf of the user, with a button as a fallback in case the JavaScript does not work.

sanderha commented 8 years ago

My gateway also requires POST data, so I guess it will have to be submitted with a form then like you said.

Thank you very much for the explanation! :)

judgej commented 8 years ago

Just use the built-in non-templated redirect (linked above) to start with, to get your gateway working. Once you have done that, then you may want to think about writing your own POST redirect if you are not keen on what it looks like.