Showing results for 
Search instead for 
Did you mean: 

Accept Hosted and Relay Response

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


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?








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 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 issue that caused the delay, but given that we had DNS problems with it earlier we cannot rule that out. 



All Star

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 website along with info on how much the payment is, so that they can pay for their membership. 

2) On the website the PM enters their credit card info and clicks pay.

3) does the auth/capture, and then ==> calls our RR URL with info on the status of the transaction. The code for our RR URL saves the info passed to us from (successful/declined/error, ...), we update the PM's membership database records from 'pending' to 'active', and then return to some HTML( a webpage with a javascript redirect to our website).

4) then passes the HTML to the PM. Since the HTML contains a javascript redirect it causes the PM's browser to go back to my website, and the webpage being displayed is the status of their transaction (successful/declined/error).

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...   


For sure they can happen out of order in your case. Webhooks may not be the complete solution for you, given your process. The iframe has a communicator that will deliver transaction results.



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 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?


Have you considered using an iframe? You set up a communicator and get an instant response. The customer never leaves your site and their session remains intact.

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.

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!


For some reason I thought you were using an iframe, but I didn’t see where I got that info. I recalled responding to your post.

My webhooks come from accept Hosted, either redirect or iframe. My guess is that SIM has a delay that accept Hosted does not, possibly tied to you running 2 updates. I do not time them in a log, I just know that I hit the pay button and go directly to my orders page and it is there on one or usually at the most 2 or 3 refreshes. The documentation says that they are sent in 3 second intervals initially.

You can get an invoice number using the gTD method call, and my 3 to 5 seconds includes that. So in other words the 3 to 5 seconds isn’t how long the webhook takes to hit but the combined processing time for everything my app does to update orders, measured from the time I hit pay.

With an iframe, the session is never ever killed during the order process, and you can tie any cookies to the user no problem. My first integration was a redirect. The shop has a cookie that ties the user to the shopping cart, and the way I have it programmed you cannot tie them to it upon return to the site, and you are done for in any case if they X out instead of hitting continue.

So to answer your question, you can just have the page following the iframe update the order. You can use your customized receipt page. On the project I am working on now, my customized receipt page marks the order paid and then a webhook comes back to update billing contact info in our records.

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.