cancel
Showing results for 
Search instead for 
Did you mean: 

Mutual client of ours noticed hash character causes problems in responses (from SIM/CIM form posts)

A mutual client of ours has noticed that a hash character entered into billing info, like apartment number # 10B, causes problems.  This is due to the # character not being Http encoded, so it ends up marking the end of info sent back to us in the URL.  Though approved at Authorize.Net, the response they send us cannot be fully processed because we only receive back 13 fields out of the expected 40 or so.  (URL parameters that hit our server clearly end at the hash.)

 

These are responses from transparent redirect (SIM/CIM) so old APIs, but currently in production.

 

Since they have several thousand contacts containing hash characters in their addresses, we were wondering if these transactions were working OK in the past until some recent change on Authorize.Net's side.

tbas55
Contributor
5 REPLIES 5

@tbas55 Do you mean you are passing hash characters in the  Authorize.Net API request? I have tried currently CreateCustomerpaymentProfile API with hash characters in address field and while getting the profile it works. If it is ANET request you are referring is truncating chars, can you send us the API request? Also, if you want to check the past transactions whether they are okay, you can Login into Merchant Interface at https://account.authorize.net, find the transactions in the "searchTransactions" option based on status/customer/settlement date.

 

Here is the request i have tried in sandbox

 

<getCustomerPaymentProfileRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
  <merchantAuthentication>
    <name>78BZ5Xprry</name>
    <transactionKey>8s2F95Q7brhHd7Tn</transactionKey>
  </merchantAuthentication>
  <customerProfileId>1813212446</customerProfileId>
  <customerPaymentProfileId>1808522261</customerPaymentProfileId>
  <includeIssuerInfo>true</includeIssuerInfo>
</getCustomerPaymentProfileRequest>
<?xml version="1.0" encoding="utf-8"?> 
<getCustomerPaymentProfileResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
  <messages>
    <resultCode>
      Ok
    </resultCode>
    <message>
      <code>
        I00001
      </code>
      <text>
        Successful.
      </text>
    </message>
  </messages>
  <paymentProfile>
    <billTo>
      <firstName>
        John
      </firstName>
      <lastName>
        Doe
      </lastName>
      <address>
        123 Main St. #123
      </address>
      <city>
        Bellevue
      </city>
      <state>
        WA
      </state>
      <zip>
        98004
      </zip>
      <country>
        USA
      </country>
      <phoneNumber>
        000-000-0000
      </phoneNumber>
    </billTo>
    <customerProfileId>
      1813212446
    </customerProfileId>
    <customerPaymentProfileId>
      1808522261
    </customerPaymentProfileId>
    <payment>
      <creditCard>
        <cardNumber>
          XXXX1111
        </cardNumber>
        <expirationDate>
          XXXX
        </expirationDate>
        <cardType>
          Visa
        </cardType>
        <issuerNumber>
          411111
        </issuerNumber>
      </creditCard>
    </payment>
  </paymentProfile>
</getCustomerPaymentProfileResponse>
bhav
Authorize.Net Expert Authorize.Net Expert
Authorize.Net Expert

No this is not using the new API.  As I said, these are responses from transparent redirect (SIM/CIM) so old APIs.  We post an http form to https://test.authorize.net/profile/ and Authorize.Net hits us back with truncated http query parameters because one contains hash (#).

 

FYI, as a workaround unless we hear otherwise, we are planning to change our code that submits the Authorize.Net (SIM/CIM) form to first strip out any hash (#) characters, because the http response that comes back to us is otherwise truncated at the point of the hash.  This means Apt. #5 would now be Apt. 5 in a street address.

 

Note again, this issue came in where old APIs are still in production, where we post an http form to https://test.authorize.net/profile/.  Our implementation of the New Authorize.Net API does not receive a callback in this way.

@tbas55  When sending direct request with data that has # a reserved character, HTTP would truncate the same on server side. So, you need to encode these characters while sending the request. 

https://en.wikipedia.org/wiki/Percent-encoding#Percent-encoding_reserved_characters

 

-Bhavana

bhav
Authorize.Net Expert Authorize.Net Expert
Authorize.Net Expert

@bhav Just to be clear, we are doing a POST to https://test.authorize.net/gateway/transact.dll

This fully encodes as you suggested.  Using Fiddler you can see the hash (#) encoded here as %23

   x_zip=14232&x_address=Adr%2C+%2355&x_company=CO

 

It was entered as #55 onscreen.  The problem is the response from Auth.Net does NOT do the same URL encoding that you describe.  Note that Auth.Net's site shows the hash is received OK (see pic at bottom of this reply) but here you can see Fiddler shows the response back to us abruptly ends exactly where the hash character should be in the x_address field:

 

GET https://tbau.idi.com:8081/OLB/BillPayment/BillPayment/ProcessMakePaymentAccountResult?x_response_cod...

 

Name:FF LL
Company:CO.
Address:Adr, #55
City: 
State/Province: 
Zip Code:14232