topic Re: Hosted Payment Form Relay in Integration and Testing

Hosted Payment Form Relay

dbjohnson — Fri, 30 Dec 2011 16:16:51 GMT

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

Re: Hosted Payment Form Relay

TJPride — Fri, 30 Dec 2011 16:29:44 GMT

Did you configure your URL in the control panel of the second account? What XML are you getting back? Please paste it.

Re: Hosted Payment Form Relay

dbjohnson — Fri, 30 Dec 2011 16:48:58 GMT

In the settings for our live card not present account in test mode, there is an option under "Transaction Response Settings" for "Relay Response"; however, we haven't put anything in the URL field. In the developer card present account in test mode there isn't a section for "Transaction Response Settings" so we're unable to specify a URL. We're passing the same hidden input fields to both gateway accounts.

This XML is displayed in the browser control after we press the "Process Payment" button:

<response>
<ResponseCode>1</ResponseCode> 
<Messages>
    <Message>
        <Code>1</Code> 
        <Description>
            <![CDATA[This transaction has been approved.]]> 
        </Description>
    </Message>
</Messages>
<AuthCode>
    <![CDATA[000000]]> 
</AuthCode>
<AVSResultCode>P</AVSResultCode> 
<CVVResultCode /> 
<TransID>0</TransID> 
<RefTransID /> 
<TransHash>DC1873050EC340E5DB6C3D398469CB79</TransHash> 
<TestMode>1</TestMode> 
<UserRef /> 
<AccountNumber>XXXX1111</AccountNumber> 
<AccountType>Visa</AccountType> 
</response>

Re: Hosted Payment Form Relay

TJPride — Fri, 30 Dec 2011 17:26:11 GMT

Well, without an error, my guess is it's the test mode. Why use test mode on a developer account? I always use live mode, test mode doesn't really simulate things that well.

Re: Hosted Payment Form Relay

dbjohnson — Fri, 30 Dec 2011 19:00:40 GMT

We turned off test mode and still no relay. The XML was slightly modified. We received the following XML:

<response>
    <ResponseCode>1</ResponseCode> 
    <Messages>
        <Message>
            <Code>1</Code> 
            <Description>
                <![CDATA[ This transaction has been approved.]]> 
            </Description>
        </Message>
    </Messages>
    <AuthCode>
        <![CDATA[ FUGATW]]> 
    </AuthCode>
    <AVSResultCode>Y</AVSResultCode> 
    <CVVResultCode /> 
    <TransID>2167785004</TransID> 
    <RefTransID /> 
    <TransHash>78BBF62B693A502E0A89711197A5E8FC</TransHash> 
    <TestMode>0</TestMode> 
    <UserRef /> 
    <AccountNumber>XXXX1111</AccountNumber> 
    <AccountType>Visa</AccountType> 
</response>

Re: Hosted Payment Form Relay

RaynorC1emen7 — Fri, 30 Dec 2011 19:23:05 GMT

I'm not 100% sure but it doesn't said Credit Present API support relay response since it closer to AIM then SIM.

http://developer.authorize.net/api/cardpresent/

Re: Hosted Payment Form Relay

dbjohnson — Fri, 30 Dec 2011 19:39:29 GMT

I discussed this with my colleagues a bit further and they all agree that we've had successful relayed responses with this gateway before. The card present integration document seems to support the idea that it should work because that's where we got the field names.

Does anyone know if they've disabled relay responses for developer accounts using the hosted payment form in the last few weeks?

Re: Hosted Payment Form Relay

ksrsrinivasan — Fri, 30 Dec 2011 19:40:55 GMT

My understanding is, SIM, DPM, Silent Post and CP all use the AIM api behind the scenes. So why is it that relay responce not supported on CP alone? I can use AIM to relay response in a CNP account and not on CP account?

Re: Hosted Payment Form Relay

RaynorC1emen7 — Fri, 30 Dec 2011 20:52:45 GMT

http://developer.authorize.net/guides/AIM/Appendix_A/Appendix_A_Fields_by_Transaction_Type.htm

Under Best Practice Fields

* The x_relay_response field is not technically an AIM feature; however, it is recommended that you submit this field on a per-transaction basis with the value of “FALSE” as a best practice to further define the AIM transaction format.

Re: Hosted Payment Form Relay

TJPride — Sat, 31 Dec 2011 02:03:34 GMT

Oh, you're using relay response with AIM? Odd. FYI, in the PHP API at least, AIM, SIM, CIM, and ARB are layered on top of the base class AuthorizeNetRequest, while DPM layers on top of SIM (since SIM and DPM both use relay response). It makes no logical sense to use relay response with AIM, since you get the results back immediately and on the same page. Unless you're mixing up relay response with silent post, which is something that sits outside of the merchant process and just receives a post for every transaction put through (including transactions entered manually through the control panel, I believe).

Re: Hosted Payment Form Relay

ksrsrinivasan — Tue, 03 Jan 2012 17:19:59 GMT

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

Re: Hosted Payment Form Relay

ksrsrinivasan — Tue, 03 Jan 2012 17:24:02 GMT

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.

Re: Hosted Payment Form Relay

TJPride — Tue, 03 Jan 2012 20:31:56 GMT

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.

Re: Hosted Payment Form Relay

ksrsrinivasan — Tue, 03 Jan 2012 20:49:44 GMT

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

Re: Hosted Payment Form Relay

Trevor — Fri, 06 Jan 2012 23:32:10 GMT

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.

Re: Hosted Payment Form Relay

TJPride — Fri, 06 Jan 2012 23:50:55 GMT

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.

Re: Hosted Payment Form Relay

ksrsrinivasan — Mon, 16 Jan 2012 23:07:21 GMT

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.

Re: Hosted Payment Form Relay

ksrsrinivasan — Wed, 18 Jan 2012 15:46:58 GMT

Trevor, TJPride

Do you have any thoughts on my last comment?

Re: Hosted Payment Form Relay

TJPride — Thu, 19 Jan 2012 00:17:37 GMT

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.

Re: Hosted Payment Form Relay

ksrsrinivasan — Thu, 19 Jan 2012 14:37:54 GMT

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.