So for awhile we've had this problem with certain card transactions, usually Visa it seems, where an address mismatch error is generated through our card processor Authorize.net even though the customer's address is actually correct. Addresses that generate this error always follow the pattern of a numbered street name following the house number. Example: 1234 5th Street
When a credit card transaction is processed, the only pieces of information that are actually verified in the transaction are numbers: the card number, expiration date, ccv code, and the house number. The name on the card, the street name, city name, state name, etc. are not used for verification purposes. So, if we run these same card transactions manually by getting the card number from our customers and processing the transaction on a physical card terminal, then there is no error of course because the address is correct.
So, I have a feeling that what is happening has to do with "Billing Address Line 1". Instead of the card processor (Authorize.net) recognizing the house number as "1234", it also sees the number in the street name and is instead trying to verify "12345", which returns an address mismatch error.
Has anyone else experienced this kind of issue? I thought about creating separate fields for the house number and street name on the checkout screens, but I want to make sure that the information is being passed correctly from screen to screen throughout the checkout process. It seems that the "Billing Address Line 1" field goes through some name changes from page to page, so I'm not quite sure how to proceed.
OCST: &mvte:global:BillAddress1;
OPAY: &mvte:global:Basket:bill_addr1;
INVC: &mvte:order:bill_addr1;
Can I use the "Billing Address Line 1" field for the house number and create a second field for the street name? If so, how can I correctly pass the new street name field on each checkout screen? Or is there another/better way to fix this?
Thanks,
Shannon
When a credit card transaction is processed, the only pieces of information that are actually verified in the transaction are numbers: the card number, expiration date, ccv code, and the house number. The name on the card, the street name, city name, state name, etc. are not used for verification purposes. So, if we run these same card transactions manually by getting the card number from our customers and processing the transaction on a physical card terminal, then there is no error of course because the address is correct.
So, I have a feeling that what is happening has to do with "Billing Address Line 1". Instead of the card processor (Authorize.net) recognizing the house number as "1234", it also sees the number in the street name and is instead trying to verify "12345", which returns an address mismatch error.
Has anyone else experienced this kind of issue? I thought about creating separate fields for the house number and street name on the checkout screens, but I want to make sure that the information is being passed correctly from screen to screen throughout the checkout process. It seems that the "Billing Address Line 1" field goes through some name changes from page to page, so I'm not quite sure how to proceed.
OCST: &mvte:global:BillAddress1;
OPAY: &mvte:global:Basket:bill_addr1;
INVC: &mvte:order:bill_addr1;
Can I use the "Billing Address Line 1" field for the house number and create a second field for the street name? If so, how can I correctly pass the new street name field on each checkout screen? Or is there another/better way to fix this?
Thanks,
Shannon
Comment