Reply
Member
Posts: 1
Registered: ‎02-15-2019

authorize.net is interpreting encoded spaces as nonencoded spaces when receiving encoded URLs

Our organization uses Slate to manage the enrollment processes for potential candidates and accepted students.  On or shortly after January 25th the software (Slate) began not receiving a post back response.  Here is the information that has been provided to me and Authorize.net support has directed me to post to this group for troubleshooting suggestions.

 

Slate is posting an encoded URL, but when the data is being interpreted on the authorize.net side, it appears to translating encoded space characters back to spaces?

 

When viewing the source of this Slate page (https://go.cia.edu/apply/payment?id=838c3489-f18d-4977-964d-4686652be947) that posts to authorize.net, the spaces in the relay URL are encoded:

 

<input type="hidden" name="x_relay_url" value="https://go.cia.edu/apply/payment?cmd=authorizenet&amp;r=d4d52665-448b-4df5-bdc4-81fa4b38ed54&amp;t=838c3489-f18d-4977-964d-4686652be947&amp;s=Enrollment%20and%20Housing%20Deposits" />

 

When you click the link to Submit Payment on the above referenced page and are then directed to the authorize.net payment gateway (https://secure2.authorize.net/gateway/transact.dll) and view the source of the page you find that the ampersand characters remain encoded correctly and authorize.net is actually encoding the slash characters using html encoding, but the spaces are no longer encoded:

 

<INPUT TYPE="HIDDEN" NAME="x_relay_url" ID="x_relay_url" VALUE="https:&#47;&#47;go.cia.edu&#47;apply&#47;payment?cmd=authorizenet&amp;r=d4d52665-448b-4df5-bdc4-81fa4b38ed54&amp;t=838c3489-f18d-4977-964d-4686652be947&amp;s=Enrollment and Housing Deposits”>

 

Highlights are mine demonstrating where the issue is.

 

When I change the name of the account to include underscores instead of spaces (Enrollment_and_Housing_Deposits) there’s nothing to incorrectly interpret, so the payment posts back correctly. The problem is, in Slate, the debit is against “Enrollment and Housing Deposits” and the credit is against “Enrollment_and_Housing_Deposits” so they don’t match up.

 

We can change the hundreds of debits by hand, and we’ll have to do that anyway since Julie would like us to change the name to Non-Refundable Enrollment Deposit and Non-Refundable Housing Reservation Fee (or what it will have to be is Non-Refundable_Enrollment_Deposit_and_Non-Refundable_Housing_Reservation_Fee).

 

I’m still concerned that the interface is not consistent in the way it handles encoded strings, because a similar thing is happening with email address. Slate is passing the following in the example that includes a “+” which is a legal character in email addresses:

 

<input type="hidden" name="x_email" value="jonathan.wehner+slate.test.gene@gmail.com" />

 

authorize.net is changing that to:

 

<input type="text" class="input_text" id="x_email" name="x_email" maxLength="255" autocomplete="off" value="jonathan.wehner slate.test.gene@gmail.com" aria-required="true" aria-invalid="false">

 

 

 

Any guidance would be greatly appreciated,

Richard Maxwell