02-14-2011 07:26 AM
Couldn't find an answer anywhere: how is the SIM x_relay_url variable validated exactly against the value in the account settings?
We need the relay url to be http://mywebsite.com/orders/<order_id>/notify, so we'd like to be able to specify it on a transaction basis via the x_relay_url variable. Not sure if that is possible/allowed with SIM?
(and if not, what is the purpose of the x_relay_url variable?)
Thanks in advance!
02-15-2011 04:15 AM
Can someone please chime in?
We have it working fine with the test environment, but we don't know if it will work in the live environment.
The documentation about the x_relay_URL parameter says:
"If this field is submitted, the payment gateway will validate the URL value against the Relay Response URL configured in the Merchant Interface. If the URL submitted does not match the URL configured in the Merchant Interface, the transaction will be rejected."
-> it does not detail what "validate" means, and if e.g. wildcards are possible.
We're integrating a generic e-commerce platform for 3rd party merchants, so we don't have access to a live merchant account for testing.
02-16-2011 06:09 AM
I added these two fields on the form:
<INPUT type='hidden' name="x_relay_response" value="true">
<INPUT type='hidden' name="x_relay_url" value="http://www.mywebsite.com/authorize.net/notifyme.php">
01-24-2013 01:59 PM
We've been passing a dynamically generated relay response url using the x_relay_url in SIM for years in our production environment now, and haven't had any issues until recently. We've had thousands of successful relay responses. We've always left the relay response url blank in the Merchant Interface so that it does not validate it.
Only just recently, we experienced 4 transactions where relay responses never reached our server, although other relay responses are still successfully reaching our server. I've checked with Authorize.net's customer support regarding this and they say that you should set the relay response in the Merchant Interface. I'm awaiting response from them about how exactly the validation works, and whether we can somehow use wildcards for the relay response url.
01-24-2013 02:42 PM - edited 01-24-2013 02:49 PM
We are still continuing to have good relay responses.
Just those 4 transactions were missing relay responses so far. They were captured/authorized, but no relay response was received by our server. I've spent hours scouring the server's access logs (which captures all inbound requests, regardless of whether they were valid or not - nginx access logs), and there simply is nothing coming back from authorize.net for those 4 transactions, which were sent no differently than any of the thousands of successful transactions which occurred before them, and many dozens of successful transactions which occurred during/after them so far. Now we're comparing the authorize.net transaction reports against our database to see if there were any new ones today..
I found nothing abnormal about those 4 transactions either. Customer support looked at them and couldn't find anything strange about them either.
Maybe it was just a network glitch? Our next steps if this issue continues, might be to specify a static relay response url (as the customer support suggested) in the merchant interface and modify our server to use a static relay response url (if there is no way to specify a wildcard). And if that doesn't work, then we might consider switching from SIM to to the more reliable AIM.