Is Authorize.net in any way obligated to transfer user data on request?
February 7, 2012 6:03 PM Subscribe
Is Authorize.net in any way obligated to transfer user data on request?
I'm trying to move to another Level 1 PCI compliant provider to handle the billing of recurring transactions.
But right now Authorize.net is "denying my request"...no reason. They just say they won't do it.
I know for a fact that they have done it, but it's obviously not something they would want to do since it's taking business away from them.
So, are there any legitimate legal avenues for forcing them to transfer the user data that we collected (and that is currently stored using their CIM service)? Authorize.net is technically just storing the credit card data we sent them and now we're saying we want to take that data elsewhere.
I'm trying to move to another Level 1 PCI compliant provider to handle the billing of recurring transactions.
But right now Authorize.net is "denying my request"...no reason. They just say they won't do it.
I know for a fact that they have done it, but it's obviously not something they would want to do since it's taking business away from them.
So, are there any legitimate legal avenues for forcing them to transfer the user data that we collected (and that is currently stored using their CIM service)? Authorize.net is technically just storing the credit card data we sent them and now we're saying we want to take that data elsewhere.
This is just about the card data, right? Because CIM supports export of out-of-PCI-scope data, AFAICT (profile, shipping address, etc.)
The thing about card data is that it's not your data, it's not even the cardholder's data -- it's the card brand's property and Authorize and everyone else handling it is beholden to them. (And owned by them -- Authorize is owned by Cybersource is owned by Visa. That's one of the reasons they're particularly strict on this. A Visa company being soft on compliance would not go over well with the companies Visa threatens or fines for non-compliance.)
So yeah, on one hand it's in their interest to not make it easy to export, but on the other hand, the whole point of the service they're providing is that one can't get that data.
If your authentication credentials, either API or identifying yourself over the phone, was enough to obtain card data in aggregate, then there's not much point in all of the key management requirements -- attackers would just go after Authorize's customers' accounts and all of the PCI requirements for protecting aggregate card data at rest go out the window.
That's the tradeoff of contracting out card data storage -- you benefit (tremendously!) from not having to do SAQ D yourself, at the cost of using a card motel: numbers go in, but don't come out.
I'm responsible for PCI compliance at a company which handles card data in a similar manner. We go through this too, although our take is partly what I wrote above, and partly that our value-add is that cardholders will trust us with their card data where they might not trust a random small business, so we've got an obligation to them to keep the data private.
Outside of all the PCI stuff -- my own experience on this kind of thing is that special requests happen as favours, and as soon as things become a legal threat from one end, it's immediately adversarial -- legal threats trigger the "we need to protect ourselves at all costs" bit.
posted by mendel at 7:55 PM on February 7, 2012
The thing about card data is that it's not your data, it's not even the cardholder's data -- it's the card brand's property and Authorize and everyone else handling it is beholden to them. (And owned by them -- Authorize is owned by Cybersource is owned by Visa. That's one of the reasons they're particularly strict on this. A Visa company being soft on compliance would not go over well with the companies Visa threatens or fines for non-compliance.)
So yeah, on one hand it's in their interest to not make it easy to export, but on the other hand, the whole point of the service they're providing is that one can't get that data.
If your authentication credentials, either API or identifying yourself over the phone, was enough to obtain card data in aggregate, then there's not much point in all of the key management requirements -- attackers would just go after Authorize's customers' accounts and all of the PCI requirements for protecting aggregate card data at rest go out the window.
That's the tradeoff of contracting out card data storage -- you benefit (tremendously!) from not having to do SAQ D yourself, at the cost of using a card motel: numbers go in, but don't come out.
I'm responsible for PCI compliance at a company which handles card data in a similar manner. We go through this too, although our take is partly what I wrote above, and partly that our value-add is that cardholders will trust us with their card data where they might not trust a random small business, so we've got an obligation to them to keep the data private.
Outside of all the PCI stuff -- my own experience on this kind of thing is that special requests happen as favours, and as soon as things become a legal threat from one end, it's immediately adversarial -- legal threats trigger the "we need to protect ourselves at all costs" bit.
posted by mendel at 7:55 PM on February 7, 2012
Response by poster: @mendal: It's about card numbers and billing data, and I'm not asking them to export the data and give it to me or tell me any card holder billing data. I'm asking them to transfer the data directly to another Level 1 PCI compliant vendor.
Other vendor's absolutely are willing to do this (Stripe, Recurly, Braintree, etc). It's not a security issue as it's vendors working directly with each other to transfer the data.
posted by JPigford at 8:09 PM on February 7, 2012
Other vendor's absolutely are willing to do this (Stripe, Recurly, Braintree, etc). It's not a security issue as it's vendors working directly with each other to transfer the data.
posted by JPigford at 8:09 PM on February 7, 2012
Yes, what @JPigford said... http://www.portabilitystandard.org/
Samurai, Recurly, Spreedly, Stripe, Braintree all follow this, there's no reason why Authorize.net doesn't except that they want to keep their customers from going to a modern gateway.
posted by smohnot at 4:58 AM on February 8, 2012 [1 favorite]
Samurai, Recurly, Spreedly, Stripe, Braintree all follow this, there's no reason why Authorize.net doesn't except that they want to keep their customers from going to a modern gateway.
posted by smohnot at 4:58 AM on February 8, 2012 [1 favorite]
Response by poster: So I finally got through to someone at Authorize.net and she said they actually will transfer data, but you have to have at least 250+ cards on file and on top of that they charge a $500 "data transfer fee."
Interesting that they did say they do it, but absolutely lame that you need to have 250 cards on file to do it.
posted by JPigford at 1:34 PM on February 8, 2012
Interesting that they did say they do it, but absolutely lame that you need to have 250 cards on file to do it.
posted by JPigford at 1:34 PM on February 8, 2012
This thread is closed to new comments.
No customer support reps at any level seem knowledgable of any such process that would allow them to export encrypted data to us.
Background - I work for another progressive payment processor/gateway http://samurai.feefighters.com. We let our customers own the data, as is only fair. Unfortunately, Auth.net doesn't play by fair rules :( but I have no good news for you, only several tales of hardship.
posted by smohnot at 7:53 PM on February 7, 2012