Customer charged but not given access

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:

s2member-pro/includes/templates/forms/authnet-checkout-form.php

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
City/Town 40
State/Province 40
Country (60)
Postal/Zip Code  20
first 50
last 50
email 255

Thanks,

Mark.

• This topic was modified 1 year ago by  Mark Maunder. Reason: Added more fields from the API's

Hi Mark.

Thank you for reporting this important issue. I’m notifying Jason now so it can be fixed.

Thanks for the heads up on this request for support.
~ Investigating now.

This has been corrected in the development copy, and will be fixed in the next maintenance release. Thanks for bringing this to my attention, both of you :-)

$xml .= '<billTo>';
$xml .= '<firstName>'.esc_html(substr($post_vars["x_first_name"], 0, 50)).'</firstName>';
$xml .= '<lastName>'.esc_html(substr($post_vars["x_last_name"], 0, 50)).'</lastName>';
$xml .= '<address>'.esc_html(substr($post_vars["x_address"], 0, 60)).'</address>';
$xml .= '<city>'.esc_html(substr($post_vars["x_city"], 0, 40)).'</city>';
$xml .= '<state>'.esc_html(substr($post_vars["x_state"], 0, 2)).'</state>';
$xml .= '<zip>'.esc_html(substr($post_vars["x_zip"], 0, 20)).'</zip>';
$xml .= '<country>'.esc_html(substr($post_vars["x_country"], 0, 60)).'</country>';
$xml .= '</billTo>';

UPDATE: s2Member® Pro v120514 fixes this issue.
s2Member® Unified Changelog » v120514

Thanks Jason. Looks like you’re truncating the data sent to authorize.net. I’d assumed you were going to limit the input field length too.

The reason I mention it is because authorize has fraud detection that relies on things like having correct street numbers and suite numbers in addresses. (Their AVS system).

So if we truncate addresses we may modify a suite number (for example) at the end of a long address line. If the user knows how long the max length allowed on an address line is then they will hopefully abbreviate the address in a way that includes the really important stuff like numbers.

Mark.

Yes, I agree with you.
I’m having this updated in the next maintenance release.

UPDATE: s2Member® Pro v120517 fixes this additional issue.
s2Member® Unified Changelog » v120517

Thanks Jason.