Hello!
From the hosted payment form, we are attempting to relay the response to a URL. Everything is working perfectly for our live card not present account in test mode; however, our developer card present account in test mode is not relaying. There is no error message, it’s just not sending us a relay. When we press "Process Transaction", the page displays XML. We use the same URL for both accounts. The following code demonstrates what we’re passing:
<input type='hidden' name='x_relay_response' value='true'>
<input type='hidden' name='x_relay_url' value='https://OUR.URL.HERE'>
We're hoping that developer accounts just don't send relays, but we can't find any documentation to support this theory. Please let us know if we can provide any additional details or clarifications.
-Derek
12-30-2011 08:16 AM
Thanks a lot for pointing out the silent post URL. We have got it working now.
01-03-2012 09:19 AM
One wierd thing is that the option for transaction response and silent post URL is not available on the Card Present sandbox account. I had to pull the URL from a CNP account and use it to navigate to the silent post url settings page on Card Present sandbox account to update it. Is this something that's not supported on Card Present accounts or is it just that they are missing links.
01-03-2012 09:24 AM
Did it work after you navigated to the URL and changed the settings? If so, that does sound kind of odd. You'd think it would either be linked or disabled entirely.
01-03-2012 12:31 PM
Yes it did work. It saves the settings and the silent post works as well.
01-03-2012 12:49 PM
The Card Present API is based on AIM and generally there is no reason to use the silent post since you receive realtime transaction results. Because this is the only API available on Card Present accounts, we have removed it from the settings page along with other irrelevant settings (such as payment form settings). If this is something that we see people looking for, we could certainly add the link again. However, I see little benefit to users of the Card Present API.
01-06-2012 03:32 PM
That certainly makes sense, I didn't realize he was using AIM. I guess the question then is, why he ksrsrinivasan using the silent post? Only possibilities I can think of are (a) he had silent post code from a different site and didn't want to bother changing his storage method or (b) he's mirroring the transactions to a second site in a rather messy way.
01-06-2012 03:50 PM
The idea was to minimize the scope of PCI compliance for our customers. We post the TrackData from MSR directly to Authnet Post URL (much like SIM or DPM), in which case, the relay response is the way to capture the result back. It turns out that the relay response does not work with CardPresent, and hence the Silent Post URL as a work around.
What i would like to see is the CardPresent API natively support a hosted payment form solution with a generic interface (COM based) to support MSR devices (Am open and very much willing to contribute a dotnet based COM component.). This would greatly reduce the efforts we developers put to work around all these standards and compliance issues.
01-16-2012 03:07 PM
Trevor, TJPride
Do you have any thoughts on my last comment?
01-18-2012 07:46 AM
To be honest, I'm not that familiar with CP yet, since most of the work I do is for web sites that sell products, not so much restaurants and so on. And it sounds like you want a niche integration that isn't likely to be supplied any time soon, unless a third party comes up with a solution for you.
I figured it wasn't worth posting a non-constructive response before, which is why I didn't reply.
01-18-2012 04:17 PM
Thanks TJPride & Trevor.
We deal with a lot of small government entities. They want the product in-house (hosting is not an option), be able to do both card present and card not present transactions and still be within the minimum PCI scope or completly out-of scope. They just do not have annual budget to go through the PCI audit.
We were able to get what we wanted from Usa e-pay since their hosted payment form and their API in general works the same for both card present and card not present as long as we pass in the right variables. And we could use the same account to process btoh.
The biggest challenge with AuthNet is the difference in the API behavior between CP and CNP and the fact that we need two seperate accounts just adds to it.
01-19-2012 06:36 AM - edited 01-19-2012 06:37 AM