|Posted: Monday May 14th, 2012 at 9:51 am #13396|
There is what appears to be a serious bug in the Authorize.net implementation.
Customers on our site that enter a transaction field longer than the authorize.net ARB spec allows are getting billed via an AIM transaction, their ARB is not being created and they’re getting a confusing error message that makes them think they haven’t been given access.
This is reproducible by entering an address in the authorize.net recurring billing form that is longer than the max allowed by the authorize.net APIs.
The cause seems to be that the s2member authorize.net form, one of which is:
allows customers to enter up to 100 chars for just about any field. This is contrary to the AIM and ARB API specifications for authorize.net which vary depending on the field.
So what occurs is the AIM API truncates longer fields and the ARB API bombs which gives the customer the error message.
So the result is, customer enters address and hits the submit button, customer is billed via AIM, ARB fails, s2member generates error message, customer is confused and doesn’t think they have access.
This is obviously urgent because any customer on our site that enters a transaction field longer than the ARB spec is hit by this.
For your reference here are the AIM and ARB allowed lengths for the following fields (the same length in each case):
Street Address 60
- s2Member® Products