Handling of customer addresses

[Kent Multer]

One of my clients has had a problem with credit-card fraud. They have turned on a restriction in their Authorize.net account, so that it will only accept orders where the billing and shipping address must be the same, as well as the more common requirement that the billing address for the order must match the one on file at auth.net. They have a lot of subscriptions that are now in Error status, mostly because of address mismatches.

To help them clean this up, I want to use phpMyAdmin to pull a list of subscriptions with mismatched addresses. But I'm not sure which addresses to check. The credit cards are saved in MivaPay. Is there an address that's saved with each card? Or does the store use the customer's default billing address when it processes a subscription?

On a related note: in newer versions of Merchant, the Customers table contains the ship_id and bill_id columns that point to the customer's default shipping and billing addresses. But the table still contains all the old columns for the complete addresses. Does the store use these columns any more? Or are they just there to support older modules, reports, etc.?

Thanks --

[ILoveHostasaurus]

The store uses the card and address combination that the given customer chose for their subscription, which could be one of any number of addresses they have stored in their address book mapped to any number of saved cards. If you manipulate this data, you'll break the referential integrity of the data Miva Merchant stored, so you should not attempt to do that.

Regardless, I don't see how you correct this issue in such a manner. If the store owner does not permit a different shipping and billing address, your two options to make them match are 1) change the current subscription shipping address to match the billing, which could have product going to a completely inappropriate destination resulting in any number of issues including chargebacks, 2) change the current billing address to match the shipping address, which may or may not work, but you'd also be altering data in that shopper's address book, which may affect other cards they have on file, and break future checkouts they intended to make, costing the store owner even more revenue. Additionally, you may create further liability issues by manipulating a customer's billing data in a way they did not intend.

My recommendation would be they turn that setting off at authnet, email the customers whose subscriptions are failing, let them know on X date a new security policy will be put in place requiring matching billing/shipping, and let those customers correct it. If they don't, then the stoer owner's choice is going to be what costs them more sales, the policy, or the fraud, and then it should be a simple numbers-based decision. Or they could instead deploy a quality fraud filter that relies on more and better data to prevent fraud than inconveniencing legit customers by only shipping to their credit card address.

[Kent Multer]

Of course the client is not going to arbitrarily change alter customers' address settings. I pointed out the problems with that when they first contacted me about the problem. I also pointed out the downsides of requiring customers to use a single address for both shipping and billing; but they made the decision to do it, at least for now. They were getting large numbers of fraudulent orders. At one point, the client wrote to me that,"This was what we had to do as we had 56 frauds in a few days and the gateway provider closed us down and held funds. I have spoken to Auth.net a dozen times in the last week, this was the only way they could see we could shut it down." They have "tried all kinds of anti-fraud with Miva. We had a 3rd-party plugin which was meant to do the job ... but it just does not work."

Many subscriptions already have a single address for both billing and shipping: more than half of them, I think, after taking a quick look. So instead of bulk-mailing all of the subscribers, they would like me to get them a list of the ones that have subscriptions with mismatched addresses.

I realized that I wasn't sure which tables I should be looking at to find the mismatches. Also, I don't know the details of how MivaPay works. But I do know that Authorize.net's API allows a merchant to send both a billing and a shipping address along with the credit card number. So my first question should have been: When the store processes a subscription order, does it send a billing and/or shipping address to Auth.net? If the answer to that question is Yes, then I need to know: billing, shipping, or both? And also, which address(es) does the store send, i.e., what table does it get them from?

[Bruce - PhosphorMedia]

unless there is fraud in subscription orders, why not just lock down the store by removing 'shipping' info input and remove the 'address' drop down as well (assuming they all use the same billing info). that way, you can leave authnet set for 'match billing info'...or did the coffee not work this morning.

[Kent Multer]

Hi Bruce, that does seem like a good idea. But this requirement only applies to credit-card orders, not to those that use other types of payment.

I wrote some protective code to ensure that, if the customer wants to pay with a credit card, they must have billing and shipping addresses that match. For now. the problem is those existing subscriptions that have mismatched addresses.

[Bruce - PhosphorMedia]

yea, i see...not ideal but you could, on OPAY, show "Edit Shipping" address form...