I have a test account and am trying to use the relay_response feature. It works with my production account. I consistently get the message that the transaction was successful, but there was a problem with my web site. I've tried using my real URL and https://developer.authorize.net/tools/paramdump/.
Is there somewhere in the UI I can authorize an URL for my test account?
โ09-21-2009 07:36 AM
I am also seeing this issue at a customer site. The relay response POST is not received. This is with live transactions, so the user's card is charged but no action can be taken due to the POST not arriving.
The core problem is that the POST does not arrive. Other posters in this thread have reported that the POST does not even arrive at the border firewall/gateway. This suggests that the problem may lie on the Authorize.Net side. The error email sent indicates that a timeout has occurred, which is not true.
There are several side issues that are related:
* There does not seem to be any retry on the transaction POST. Other payment systems try multiple times to send the transaction details. Of course, this would only help if the transaction details are being sent at all.
* The user is presented with a confusing error message that seems to say "something succeeded, but something failed". What it really means is that charging the card succeeded, but posting the transaction failed. In our case this means that the user doesn't get their service. Perhaps this error message could be configurable.
* The user's card is charged regardless of the relay response success or failure. Perhaps this is out of the scope of the relay response feature, but my idea of ideal behaviour would be to not complete/cancel/void the transaction if the reply to the relay response is anything other than an HTTP 200/OK. Building on this, the contents of the response in case of an error would be displayed to the user (exactly as the receipt feature works).
In short, that this problem happens at all is of concern, and understandably makes the customer nervous.
โ10-26-2009 07:51 PM
I received a response informing that the issue in this thread related only to the test environment and is now resolved. I'll follow up here if I can find out any more about similar issues in the live environment.
โ10-27-2009 03:22 PM
The official Authorize line (from tech support and on this forum) is that there was a problem in the test environment but it is fixed. They are completely denying any possibility of a problem in the live environment.
There are several posts (including my own) in this forum that are talking specifically about the LIVE environment. We are seeing problems in the field - and they are not being addressed.
If you are reading this forum in consideration of using relay response or silent post with a SIM implementation - i would advise you to pay very close attention to this issue or consider another vendor.
โ10-28-2009 06:36 AM
So after more than a week of waiting for a response on my eTicket, i get this:
Bottom Line:
If you are a developer looking to use SIM to integrate with a custom web application - don't plan on the relay response as a reliable mechanism. If you need it to be reliable, then STAY AWAY FROM AUTHORIZE.NET
โ10-28-2009 07:10 AM
The frustration with this issue continues.
Authorize.Net continues to deny that there is any possibility that their live systems are any less than perfectly flawless.
On Wednesday we set out to prove/disprove the assertion that Authorize.Net always attempts to contact the relay_response_url. Authorize.Net has said repeatedly that there is no problem on their end - that the only possible problem is that the relay_response_url is not available to be requested.
So we devised an experiment. We created a brand new application on the Google App Engine. It's only purpose is to attempt a transction via SIM and verify that Authorize.Net requests the relay_response_url as it should. The transactions were tested against the live gateway (https://secure.authorize.net/gateway/transact.dll) using test transactions (x_test_request = true). The relay_response_url was specified with each transaction and pointed to a page hosted on the Google App Engine. That response page was extremely simple, it's only function to print out the current date & time.
We ran this test roughly every 5 min for several periods over the last two days. The results are that Authorize.Net failed to retrieve the response page 4 times out of approximately 350 tests over that period (>1% failure rate). That is to say, that Authorize.Net could not reliably retrieve the simplest possible response page from one of the most available server clouds in the world.
I take this as incontrovertable proof that there IS a problem with the Authorize.Net systems.
If Authorize.Net engineers are not capabable of setting up a similar system to reproduce this problem for themselves, then please contact my company we will be happy to set it up for you.
It is imperative that Authorize.Net take the following actions as soon as possible:
1. assure your customers that this matter is being taken seriously
2. initiate a proper investigation into the issue
3. provide an ETA for the completion of that investigation
4. provide an ETA for restoration of proper function
โ10-30-2009 08:28 AM
Thanks for your posts Paul.
Scary that a gateway that deals with significant amounts of ecommerce transactions would ignore issues like this.
โ10-30-2009 04:54 PM
Is there any update with this issue? I am trying to use the SIM relay response with no success in the test environment. All I get is the following message...
"An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.
This transaction has been approved.
It is advisable for you to contact the merchant to verify that you will receive the product or service."
Plus the email I receive doesn't tell me anything.
โ11-04-2009 10:52 AM
This is a bit ridiculous now. No response on here from Authorize.net and no response from the message I sent to support (even though it says they will respond in 24 hours, it has been almost 72 hours now).
I am posting the very basics for a relay response: x_login, x_amount, x_type, x_show_form, x_fp_hash, x_fp_timestamp, x_fp_sequence, x_relay_response=>TRUE, x_relay_url. The x_relay_url matches the default relay response url in the merchant interface.
Transactions are being approved as I can see them in the unsettled transactions list and they are pending settlement. But I still am not getting anything posted back to my x_relay_url. Which is obvious from the access logs on my server and the following message I see every single time....
"An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.
This transaction has been approved.
It is advisable for you to contact the merchant to verify that you will receive the product or service."
This would be fine if I were actually getting error messages sent to me! Instead I am just receiving receipts, with no error response anywhere.
Can an admin out there please respond to this issue.
Thanks
of course I am posting to https://test.authorize.net/gateway/transact.dll
โ11-09-2009 10:23 AM
Hey all,
I apologize for the delay in responding. I have forwarded the issue on for further investigation and so far, I have no updates other then they are looking into this. I will update this post as soon as I know anything.
Thanks,
Michelle
โ11-09-2009 02:25 PM
I seemed to have found why I was having problems. I was setting the relay response url to a port different than port 80. Once I changed the port I wanted to relay response to post to, it worked.
In the documentation it makes note that... "Note: Authorize.Net only posts the Silent Post on port 80."
It also says.... "Please be aware that the Silent Post URL does not function the same as the Relay Response URL."
So initially I did not think it would be a problem setting the relay response url to post to a different port. Unless I missed it somewhere in the documentation, it should say the relay response url only posts to port 80 also.
Another thing I found which I didn't see documented anywhere, if you want to use the Receipt Page, you have to set x_relay_response to 'FALSE', even though the field is optional and I believe would default to 'FALSE'.
โ11-09-2009 02:34 PM