cancel
Showing results for 
Search instead for 
Did you mean: 

SIM - Problem with x_cust_id or x_invoice_num containing 2 or more consecutive spaces

We have been using Authorize.net for a while now without any changes to our code to transfer the user to Authorize.Net to make a payment.  Our Invoice Numbers contain a 4 character prefix and a 6 digit suffix.  The prefix is right padded with spaces. as necessary between the prefix and suffix (EX: BOP 123456 or D   123456)   Sometime between April 2nd and April 6th we started receiving Settlement Errors.  The Settlement Errors would not be calculated into our daily settlement report, but they would download with no indication that they were in error when we download the batch settlement report.

 

While researching this issue we noticed � characters in place of some of the spaces on the batch settlement report.  We did some additional research and traced every step of the process and found that up until we submitted to secure.authorize.net there were always the appropriate number of spaces in the invoice_num and cust_id fields (including in the form post)

 

Once on the secure.authorize.net site however we start to see problems creeping into the page source.  The x_cust_id and x_invoice_num hidden input fields now contain non-breaking spaces ( ) for the 2nd and/or 3rd consecutive spaces.  We also see the same in the HTML (which we would expect for formatting purposes).

 

After submitting we are returned to our site for the receipt page where the  s have now become ī¿½ (I believe those are the correct characters, but I'm transcribing from a screenshot I took yesterday)

 

The information we are passing in the cust_id and invoice_num fields is an account number that we use to tie the payment back to the customer's account so we need a predictable format.  We also use the same posting logic to sent requests for two different companies that have slightly different account number formats so trying to change the spacing to account for this bug would not be a good solution as we could inadventantly cause bigger problems.

 

From everything we can see this is a problem with the Authorize.Net site, but the support rep we spoke with was very unwilling to escalate the problem to someone with some basic HTML/web programming knowledge so that we could get a proper bug report in place.  

 

Any ideas?

MOD
Member
4 REPLIES 4

It look like the second space is convert to  (cc# entry screen) then to  (receipt page). Workaround is probably is to decode it before using. Hopfully one of the mod will forward this to the developer.

Their email address is developer@authorize.net

RaynorC1emen7
Expert

It actually comes back to us when we download the batch settlement report with the spaces, it displays as a replacement glyph (the ? in the black diamond) on the html version of the page.  We don't have any problem loading the transaction on our end, however, the processor is returning a settlement error (probably because they're getting an odd character), but the download from the batch settlement report doesn't convery that the transaction is in error, so our total download doesn't balance to our daily batch total we recieve by email when batch processing occurs.

 

Overall, it's multiple points of failure.  we've seen the occasional settlement error in the past which is one of the reasons our processes dictate balancing processed total to the batch total, but in the past it has been very rare to see one of these, but now it's a problem that would affect about 50% of accounts, in practice, it only effects around 20% because of the distribution of who pays by CC vs check or EFT

 

If we don't see any feedback from a moderator by tomorrow morning then I'll look at forwarding on our more detailed (with lots of screenshots, and static submit page) to the developer address.

Just run another test, instead of SIM, using DPM, the receipt page show the second space as  

Hopefully, they will have all the info they need from you to fix this problem.

I've submitted on to the developer address you provided.  hopefully they can do something.  I also provided a html/javascript (javascript to generate timestamp and hash based on form filled login and transaction key) test document to show this problem in action.  The transact.dll page translates inbound 2nd and subsequent spaces to   and if it recieves a   it will translate to  

 

We also provided the same demo to our bank and they are attempting to get our processor TSYS to get involved.  We are hoping that Authorize.net is willing to fix this bug in their transact page as opposed to us needing to put in a hack on our end to replace spaces before submission.

 

thanks for your help.  hopefully we can make some progress.