Authorize.Net API questions and help with your payment integration.
Authorize.Net API questions and help with your payment integration.
08-30-2019 02:18 AM
I'm currently using SIM and have Relay Response configured to that I get informed of the transaction status.
I'm in the process of migrating to Accept Hosted and it's working in my sandbox. To be informed of the transaction status in my sandbox I configured a Relay Response URL (just like my SIM production setup) but it's not getting executed. In my browser I'm getting a message with the response showing the transaction was successful. But my server needs to receive this from Authorize.net.
Yes I'm aware of the webhooks stuff. But to me that's a step backwards compared to getting my Relay Response URL executed.
If I migrate from sandbox to production will Relay Response work?
08-30-2019 05:02 AM
There is no way to get a relay response to work with Accept Hosted. It sounds like you may have a UI concern, as I know relay response will allow you to display a custom receipt page. You can set your receipt url on Accept Hosted to display something that is good for your UI and UX. To bypass the auth.net receipt page, use an iFrame integration.
In regards to webhooks, I wouldn't call them a step back at all, although I understand your concerns. They work like magic and you can do a lot with them. I have ran well over 1,000 tests and 99%+ come back within 3 to 5 seconds of the customer hitting the pay button. They almost never fail. I have been running regular test transactions since Sept of last year, and have tested many integrations. There was 1 single day out of all of these that they did not come back reliably, and this integration in question had DNS resolution errors. Others were posting on the forum that theirs were not delivered, so it may have been a genuine auth.net issue that caused the delay, but given that we had DNS problems with it earlier we cannot rule that out.
09-13-2019 02:16 PM
My concern is about timing, not about UI.
We are a club, and a perspective member (PM) must pay to join our club. With SIM and Relay Redirect (RR) we currently:
1) collect some information from the PM, create membership database records for the PM that are in the "pending" state, and then pass the person to the A.net website along with info on how much the payment is, so that they can pay for their membership.
2) On the A.net website the PM enters their credit card info and clicks pay.
Notice that with our current scenario those items never happen out of order.
I'm coding Accept Hosted with an iFrame. That will let the PM know the status of the transaction. As I understand things eventually the webhook will fire and when that happens I believe my website will have to go get the status of the transaction. So there's a gap in time there, where the PM could get the transaction status and then use my menu system to look at their membership status, as see that it is still in the 'pending's state. Notice how these can happen out of order using webhooks. Or am I missing something...
09-14-2019 07:50 AM
09-30-2019 03:17 AM
For kicks on my production server I configured the authcapture webhook with a URL that executes my webhook code. Hence I now have both my Relay Response URL and my authcapture webhook URL being called. I've written a simple logging function, and using it I can see exactly when both get executed, to watch the logging in real time I open a SSH window to my linux server and then do "tail -f $HOME/log/logfile", and ever time a webpage is serverd up log messages appear.
Having paid for my own membership, from the time I click the Pay button to when the Relay Response URL runs, typically it's a fraction of a second.
Recently members paid for their membership, and looking thru my log file, here are the seconds of delay between the Relay Response running and the webhook running for 18 payments:
11 7 23 18 6 21 14 19 16 5 16 9 24 21 11 16 19 11
Hence if I use the webhook to update the member's membership status as having been paid (use the transaction id to get the invoice number to get the membership number) it's very likely that a member could successfully pay and then display their membership status and get inaccurate information. They would have every right to think our website is crap, and no amount of "look what it says now" would change that opinion.
With the significant delay between authcapture and the webhook running webhooks are a step backwards compared to Relay Response.
In reality Relay Response is a webhook, and it's a timely one. And they include the invoice number so you don't have to go get it!
I guess everytime a member displays the webpage for their membership status I could add code that:
1. check if the membership was recently paid for (ie webhooks updated it) and if so stop. But if not continue on.
2. checks if a record was recently created for the member and get the invoice number from it,
3. send a getUnsettledTransactionListRequest??? request to a.net to get a list transIds,
4. For each transId in the list us it to call getTransactionDetailsRequest looking for a transaction with the correct invoiceNumber,
5. And if the invoiceNumber matches and the responseCode was successful then update the membership status.
6. And then display the membership status to the member.
Given the coding to do all that, why even bother with coding up a webhook?
09-30-2019 10:34 AM
09-30-2019 11:57 AM
Good afternoon @Renaissance
Unfortunately, I haven't been very clear. I'm using Accept Hosted iframe (with communicator) and lightbox.
I have a VERY simple sandbox php webpage working where:
- loading the webpage sends info / gets back the token and displays a button,
- and when the button is clicked the token is sent and the reply is displayed in the iframe/lightbox, and after a second or two the payment webpage appears with in it,
- clicking Cancel is programmed to just hide the iframe,
- upon successfully paying I receive the transactResponse message and thus hide the iframe and display a "you have successfully paid" message.
If Relay Response (RR) URL worked with Accept Hosted the transactResponse message and the RR URL would both happen at the same time, and thus:
1) my members browser would display the "you have successfully paid" info,
2) the Relay Response URL would update the member's membership on my website's database. THIS WOULD BE FANTASTIC! But, sadly, you say no matter what Relay Response will never run.
Because you keep coming back to the communicator and transactResponse message and how wonderful it is, I feel you are suggesting I use it (which runs insecurely inside my member's browser) to run some JS code that would execute a URL on my website that would update the member's membership (similar to what my RR code does), is that what you are subtly suggesting??
The great thing about the transactResponse message is that it even has the invoice number (something the webhook message doesn't)! Oh that's to funny.... Unless I'm missing something, besides security, it seems like this would work.
09-30-2019 12:13 PM
Also, I forgot to ask about something else you previously mentioned. You also stated "I have ran well over 1,000 tests and 99%+ come back within 3 to 5 seconds of the customer hitting the pay button."
The 18 payments I previously timed were on my production server using SIM / Relay Response / webhook. My log file shows they averaged 13.6 seconds of delay between Relay Response and the webhook running. I'm not guesstimating my timings either as my server is generating them.
How are you achieving such low delays?
If I had numbers like yours I could give a luke warm thumbs up to webhooks as currently implements, and if they would update the webhook to include the invoice number I would give it a two thumbs up bigly!
09-30-2019 12:56 PM
09-30-2019 01:35 PM
Just ran a test and it looks like it takes longer on an iframe. Not sure why. I am clocking about 15 seconds. May be just something today.
I would still recommend using the transaction response, even if 99% come back in 3 to 5 seconds. You don't want your customers to have an inconsistent experience. The iframe solves the problem perfectly.