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

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

TJPride
Expert

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> 

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.

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>

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/

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?

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?

Regards,

Srinivasan R

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.

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).