12-29-2009 02:08 PM
I am moving a store from another payment gateway to Authorize.Net. The other gateway has two 96-character address lines. Authorize.Net (CIM, in my case) supports only a single, shorter address line. How should I combine what is currently two long address lines into the single, short address line without breaking address validation?
12-30-2009 12:32 AM - edited 12-30-2009 12:34 AM
The Address Verification System only validates the first line in the address and the validation will disregard any characters after the address. This means that combining the two address lines into one will not adversely affect address verification. It is up to you how exactly you choose to segregate the two portions of the address in the single line.
01-04-2010 06:21 AM
I am trying to solve this same problem by using the company field as my address line 2.
However, I am getting an error that stats that company is not a valid element. Any advice? I am trying to use CIM for PCI compliance and not store any identifiable information, however not have an address line 2 is kind of silly. This is a shipping address, not a billing address for (AVS) charging.
Here's the request and the error:
<?xml version="1.0" encoding="utf-8"?><createCustomerShippingAddressRe
The operation failed with the following errors:
[E00003] The element 'address' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd' has invalid child element 'company' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'. List of possible elements expected: 'city, state, zip, country, phoneNumber, faxNumber' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'.
[messages] => SimpleXMLElement Object
[resultCode] => Error
[message] => SimpleXMLElement Object
[code] => E00003
[text] => The element 'address' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd' has invalid child element 'company' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'. List of possible elements expected: 'city, state, zip, country, phoneNumber, faxNumber' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'.
01-14-2010 12:57 PM
The CIM API is sensitive to the order that elements included. The sample that you provided shows the company element after the address element, swapping the order of those two fields should address the error that you are seeing.
07-23-2010 10:13 AM
Is it possible that adding a Suite number to the single bill-to address line would trigger a mismatched street address in AVS?
07-25-2010 09:31 PM
No, it is not. Issuing banks only validate the first 5 numeric values of the street address and all 9 digits (if they are included) of the zip code.
07-27-2010 03:44 PM
Thank you Elaine. AVS was working fine for us until one address (something close to "300 Fifth Avenue, Suite 200") just wouldn't validate for all of the customer's cards while the ZIP would. He got upset because it was eating his credit and we had to call the issuing bank to release all the funds held up by the declined. On our end, we were charged all the percentages by our processor because the transactions (fairly large) were approved by them.
We tried both "300 Fifth" and "300 5th" and neither one validated. To make it work and ensure not being charged all the percentage by our processor, we had to turn that setting off in AVS for the transaction to go through. We're now hesitant to require both the ZIP and Street Address to validate but are obviously concerned with potential fraud.
07-27-2010 06:55 PM
Their merchant account provider really sucks if they are surcharging for failed AVS. Every other processor does not do that. The only requirement is that AVS is performed but it does not have to pass. If I were you I would tell them to find a new processor quick.
07-28-2010 01:46 PM
I believe they are just charging their standard discount rates for approved transactions, not anything related to AVS. AVS is done by Authorize.net, hence the Transaction Status in our Auth.net Account says Declined. The actual transaction is showing as approved on the processor's end, and what's actually happening during the AVS Decline is 2 transactions/authorizations: 1 for the approved charge and 1 for the immediate refund (due to AVS Decline). Authorize.net appears to send this second notice immediately after an AVS decline.
I was stumped too when the card issuer for our client saw 2 transactions with the same approval code. Turns out one was the charge and the other the immediate refund.