I just noticed that we don't appear to get a transaction ID back from getHostedPaymentPageRequest, just a transaction token, which I now realize are not the same thing. Is that correct?
What I need is to be able to call getTransactionDetails after the return from the redirect to the Accept Hosted page (once again, we are required to do a full page redirect in order to integrate with our application, rather than an iFrame solution). I saw another similar thread here that appeared to suggest using a webhook, but that won't work for us since we need to be able to request the transaction details as part of our server's response to the redirect back to our application.
10-30-2018 07:53 AM
Any luck or progress on this? I am running into the exact same problem.
I am building a website for a movie theater, and I obviously need to verify that the transaction was successfull after the user makes the payment before I reserve their seats and get a pickup number from the ticketing server for them.
Found another thread too which suggests using "Web Hooks". I've https://community.developer.authorize.net/t5/Integration-and-Testing/Verify-an-Accept-Hosted-tr...
I've looked into that though, and the problem I have with that is it looks like my site would to wait for a payment event to act on, rather than being able to give the user instant feedback. Doesn't seem like a great solution. I want to make this easy for the user, but I also don't just want to give away free movie tickets or my client might be a little upset. So far as I can tell Authorize.net is not providing an easy way to do that.
11-02-2018 03:22 PM
@dominick wrote:Any luck or progress on this? I am running into the exact same problem.
I am building a website for a movie theater, and I obviously need to verify that the transaction was successfull after the user makes the payment before I reserve their seats and get a pickup number from the ticketing server for them.
Found another thread too which suggests using "Web Hooks". I've https://community.developer.authorize.net/t5/Integration-and-Testing/Verify-an-Accept-Hosted-tr...
I've looked into that though, and the problem I have with that is it looks like my site would to wait for a payment event to act on, rather than being able to give the user instant feedback. Doesn't seem like a great solution. I want to make this easy for the user, but I also don't just want to give away free movie tickets or my client might be a little upset. So far as I can tell Authorize.net is not providing an easy way to do that.
It sounds like we are in very similar circumstances. No, I have not found a solution for using full page redirects other than a webhook, and I agree with it not being a suitable solution for the reason you have outlined. The way I am currently going about trying to resolve it is by switching to an iframe-hosted solution ... I've also been having some unrelated problems with that, but at least it does return a transaction ID.
11-07-2018 04:12 AM
It doesn't seem like it would be that hard for Authorize.net to just include an ID in the POST data when the user returns to our sites after the payment is complete. Oh well.
The solution I ended up using was the Accept.js library. It does work for me but I was really hoping to have a site that was not reliant on Javascript. But, it doesn't seem like theres a good way to use authorize.net without javascript, unless you want to just give away free stuff, so I guess that's that...
11-07-2018 09:46 AM
11-19-2018 08:05 PM
I'm having the exact same issue. I have to use the redirect method (iframe and webhook will not work for us) and I can't get the transaction ID. The vendor I'm working with to build the form system has done this exact same setup (redirect method with transation id) on multiple other payment processing providers, so I think our best option is to switch payment processing providers away from Authorize.net.
12-18-2018 08:04 PM
12-21-2018 06:32 AM - edited 12-21-2018 06:33 AM
@Renaissance wrote:
The redirect method and Webhooks are not mutually exclusive alternatives. They are something you use together. I have tested 100s of Webhooks with 0 failures, and unless the customer is a speedreader and/or extremely fast with their mouse, 99% + of Webhooks beat them to the server. In other words, by the time they have reviewed and/or printed their receipt and clicked continue, the Webhook has already came back.
But we don't use Auth.net receipts. When the customer clicks on Pay, the postback to our site is immediate and then we have to have the transaction data in order to show them our own receipt. In this scenario webhooks seem unsuitable. Not to mention that 99% accuracy on our receipts is not acceptable.
We also have a 2nd problem with webhooks in our testing areas because of the rerouting that needs to take place, and the lack of information in the webhook about the URL that was redirected from would require us to build a new system of associated reference IDs to specific source machines, but this only compounds the reasons why we are not using webhooks.
12-21-2018 02:49 PM
12-22-2018 12:38 PM
Assuming you are utilizing the divert strategy, the post back to your site would need to occur on the auth.net receipt page. This is unavoidable as best I know. I notice in another post that you said you changed to an iframe.
How could it be that you utilize the exchange information? You show your own receipt that will have the exchange Id and what else? Nothing is impossible for someone who is truly determined, for the most part, and my hunch is the way isn't hard for this situation.
08-03-2021 11:46 PM