Integration and Testing

[jbubbison]

Is it possible to specify the delimiter character for the validationDirectResponse that is returned when using the CIM createCustomerPaymentProfileRequest method (when the validationMode is testMode or liveMode)?

The reason I ask is that the createCustomerProfileTransactionRequest method accepts the <extraOptions></extraOptions> element, which enables me to format the validationDirectResponse in a manner of my choosing. It appears that the createCustomerPaymentProfileRequest method offers no such capability.

Is anyone able to confirm?

Thank you for your insights.

[Trevor · Accepted solution]

There is no way to set the delmiter programmatically outside of the <extraOptions> element, but you can set the default delmiter for any Authorize.Net account within the account settings.  Changing the default delimiter (and optionally the encapsulation character) will apply to the response returned for a createCustomerPaymentProfileRequest.

[Trevor · Accepted solution]

There is no way to set the delmiter programmatically outside of the <extraOptions> element, but you can set the default delmiter for any Authorize.Net account within the account settings.  Changing the default delimiter (and optionally the encapsulation character) will apply to the response returned for a createCustomerPaymentProfileRequest.

[jbubbison]

Thank you for the prompt and informative response, Trevor; it was articulate and concise.

While we're on the subject (I hate to start another topic for this), is there any reason of which you're aware that the <extraOptions>...</extraOptions> data would be parsed incorrectly on the Authorize.Net side?

I'm submitting the following (via the createCustomerProfileTransactionRequest method)

<extraOptions><![CDATA[x_delim_data=TRUE&x_delim_char=|&x_customer_ip=127.0.0.1]]></extraOptions>

and in the Transaction Detail view of the sandbox site (CIM -> Customer Profile -> View History -> Transaction Detail), the customer IP line looks like this:

Customer IP: 127.0.0.1]]>

It appears that the closing CDATA tag is being appended. In fact, it seems that whichever parameters are included first and last in the list are affected in this way.

To explain further, in the "Merchant Email Receipt" that is generated as a result of the API request, I find the following (using the same <extraOptions> data that is pasted above):

========== MERCHANT DEFINED =========
%3c!%5bCDATA%5bx_delim_data : TRUE

In this instance, it appears that the opening CDATA tag is being prepended (and URL-encoded).

Any thoughts as to why this is happening? Am I doing something wrong on my end?

Thanks in advance.

[Trevor]

I just copied and pasted that extraOptions tag into my own test code, but I was not able to reproduce the behavior that you are describing.  The only thing that comes to mind is that you may somehow be double-encapsulating the CDATA string.  For example:

<extraOptions><![CDATA[<![CDATA[x_delim_data=TRUE&x_delim_char=|&x_customer_ip=127.0.0.1]]]></extraOptions>

This would cause exactly the behavior that you are describing.

[jbubbison]

Thanks, Trevor.

Per your suggestion, I tried removing the encapsulating <![CDATA[]]> tags and now the values appear correctly in the CIM interface on the Authorize.Net developer site (and no API errors are generated).

I also searched my entire application for the strings "extraOptions" and "<![CDATA" to see if I may have been double-encapsulating the CDATA string. The latter string was not found anywhere at all, and the "extraOptions" string was found only where I'm composing the XML (and I'm definitely not double-encapsulating there).

After removing the encapsulating tags, I dumped the raw XML output that is being sent to the API and it does not contain the encapsulating strings:

<?xml version="1.0" encoding="utf-8"?>
<createCustomerProfileTransactionRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
    <merchantAuthentication>
        <name>XXXXXXXXXXXX</name>
        <transactionKey>XXXXXXXXXXXXXXXX</transactionKey>
    </merchantAuthentication>
    <refId>XXXXXXXX</refId>
    <transaction>
        <profileTransAuthCapture>
            <amount>3.55</amount>
            <lineItems>
                <itemId>1</itemId>
                <name>Prorated Payment</name>
                <description>Prorated payment for August 10, 2011 to August 31, 2011</description>
                <quantity>1</quantity>
                <unitPrice>3.55</unitPrice>
                <taxable>false</taxable>
            </lineItems>
            <customerProfileId>XXXXXXX</customerProfileId>
            <customerPaymentProfileId>XXXXXXX</customerPaymentProfileId>
            <order>
                <invoiceNumber>XXXXXXXX</invoiceNumber>
                <description>Prorated payment for August 10, 2011 to August 31, 2011</description>
            </order>
            <cardCode>123</cardCode>
        </profileTransAuthCapture>
    </transaction>
    <extraOptions>x_delim_data=TRUE&amp;x_delim_char=|&amp;x_customer_ip=127.0.0.1</extraOptions>
</createCustomerProfileTransactionRequest>

Given that this functions as expected and desired, I'm going to leave the encapsulation strings out of my XML request.

Out of curiosity, what happens if you submit an equivalent request and omit the encasulating strings? Do you receive an error? Or are the values accepted and parsed correctly with or without the encapsulating strings?

I wonder if the XMLSerializer PEAR library that I'm using to compose the XML from a PHP array is escaping the encapsulating strings into their HTML entity equivalents or similar (as it appears to do for & -> &amp; ).

[Trevor]

You can submit it without the CDATA encapsulation most of the time.  The only time you will get a problem is if your <extraOptions> value includes XML reserved characters.  Opening and closing angle brackets would be the most obvious problem.