cancel
Showing results for 
Search instead for 
Did you mean: 

Hosted Payment Form Relay

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

dbjohnson
Member
19 REPLIES 19

Thanks a lot for pointing out the silent post URL. We have got it working now.

Regards,

Srinivasan R

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.

Regards,

Srinivasan R

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.

Yes it did work. It saves the settings and the silent post works as well.

Regards,

Srinivasan R

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.

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.

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.

Regards,

Srinivasan R

Trevor, TJPride

 

Do you have any thoughts on my last comment?

Regards,

Srinivasan R

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.

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.

 

 

Regards,

Srinivasan R