I hope I'm missing something here but the documentation and examples for using the full page hosting solution always want to use POST. You cannot redirect to a POST so I don't see how this can work correctly. All the examples seem to assume that I'm going to have a button on my page wrapped in a form that redirects directly to Authorize.Net but that isn't how our apps work. More importantly, if the user sits on that page for more than 15 mins then Authorize.Net invalidates the token (based upon the documentation).
I don't want or need to create a token until the user explicitly clicks the Pay button. At that point I have to do some server side processing so I call back to the server. At this point I'd create the token. I need to send the payment URL back to the client so it can redirect. But since it requires a POST I cannot simply send a redirect response with the URL. I also don't want the user to have to click yet another button. I could potentially redirect to my page, detect that I need to form post and then, using scripting, trigger the post but that seems like a lot of messy code to do something that seems trivial.
We're in the middle of evaluating a new provider and Authorize.Net is one of them. PayPal allows me to redirect the way I want but I haven't gotten to the other providers. Not being able to redirect is going to be an issue for us and would probably eliminate Authorize from the list. It also isn't an option to use an iframe or self host. We want the entire payment experience off our network.
How can I get this to work properly?
โ10-19-2017 02:56 PM
Auto submitting your payment form is as simple as
document.getElementById("YOUR_PAYMENT_FORM_ID").submit();
For greater control of your forms with reduced PCI compliance requirements, check out accept.js && accept.js in action.
โ10-20-2017 07:28 AM - edited โ10-20-2017 07:32 AM
That does not solve the problem I'm talking about here. Yes I can trigger a redirect to yet another page on my site that then has a form embedded in it with the token that needs to be sent and then auto-trigger the submission but that is far from ideal. Hence this is not a good solution to this problem.
The app has already sent the data the request needs to the server. Why in the world would I need to POST a redirect request when I could just pass the returned token as part the URL? This is how other providers seem to work. If Authorize.Net does not support any other approach then I'll add it to the list of cons against the product. We will take it under advisement as we compare products. It just seems like a serious oversight that this scenario, which I think is very common, isn't supported by full page hosting.
โ10-20-2017 07:43 AM