07-15-2011 12:58 PM
Newbie here... been integrating CIM api's for about 2 months... anyway, ran into an issue in using the
"createCustomerProfileRequest" CIM api when there was an ampersand & included in the company name
<?xml version="1.0" encoding="utf-8"?> <createCustomerProfileRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"> <merchantAuthentication> <name>xxxxxxxxxxx</name> <transactionKey>xxxxxxxxxxxxxxx</transactionKey> </merchantAuthentication> <refId>xxxxxxxxxxxxxxxxxxxxxx</refId> <profile> <merchantCustomerId>121121</merchantCustomerId> <description>SO121121</description> <paymentProfiles> <billTo> <company>xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx & zzz</company> <address>755</address> <zip>10466</zip> </billTo>
(note that the break shown above AFTER the & does not exist in the real XML)
The error returned is "E00003 An error occurred while parsing Entity Name. Line 13, position 39. ".
If i count out the line and position, that points to the ampersnad in the <company> tag.
My thought was that I could use the "CDATA" tag like I see in some of the API examples in the manual, usually shown in the <extraOptions>.
When I did that
<company><![CDATA[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx & zzz]]></company>
The error returned is "E00003 Invalid character in the given encoding. Line 13, position 20. " which points to the
which points to the [ just prior to the CDATA .
Can we use CDATA to wrapper special characters in the actual data values?
The API works fine if the ampersand is not embedded in the data. I don't want to strip it out, because we have
customers give us the name off of the card and it does have an ampersand as part of the name that is on the card.
Any help, including pointing me to the documentation that explains this, would be appreciated.
Thanks in advance
07-17-2011 06:53 AM - edited 07-17-2011 06:54 AM
Ampersand is a reserved character in XML.
To use it you have to first clean the input to escape it by using &
(I always found it funny that to escape an ampersand you have to use an ampersand)
01-14-2014 12:00 PM
This is a bug in the AuthorizeNet SDK library (at least in 1.4.6). The library is not properly escaping XML attribute values or element text values when serializing XML documents to Strings.