Credit Card Data Portability - Does anyone really care?

When accepting payments online (Authorize.Net,SagePay, Braintree etc) you can elect to store your customer's credit card data. It's an obvious requirement for recurring payments and potentially a good practice for one time payments (by pre-populating a shopping cart for a returning customer). So what happens to your customer's credit card data if you decide to change payment providers? 

The answer is "it depends".

Initially, some merchants make the mistake of thinking they should be able to receive their data via something like a .csv file. Due to PCI DSS rules that's not possible. Yet in reality PCI issues are often used as a smokescreen to justify why you can't get your data back.

Credit card data can be transferred - it just has to be securely transferred from one PCI compliant service to another.

Unfortunately, many services providers point to PCI concerns as a reason not to do any type of transfer. For a merchant, the thought of asking all their customers to re-enter their card data typically stops them in their tracks. Thus creating a frustrating lock-in cycle.

From

Some services can't or don't because they don't vault cards for you independently - leaving the answer in the hands of whichever payment gateway you selected to work with their service. Still, globally, it's the exception rather than the rule.

Credit card data portability reminds me of flood or earthquake insurance. People sort of assume they're covered - if they think about it at all. Many never experience a natural disaster. Those that have suffered feel very strongly about the need for credit card data portability. Given Spreedly's business we most likely talk with a disproportionate number of these folks.

Let's also be honest. Even when you do support portability it's a pretty clunky process. The card data has to be moved between two providers in a secure manner. Data has to be re-mapped. Your service has to be up and running for new transactions before you can shut off the older service (so you don't orphan whatever signs up happen after the transfer is done) It's substantially better than not being able to get your data back - but it's hardly a seamless process. Also, some payment gateways charge fees to do this work so there can be an added cost as well.

Spreedly tackles this by vaulting your cards away from your payment gateway and giving you a payment gateway API to integrate. 

.

However, what if you want or need to use the payment gateway API (vs Spreedly's?) Well, one option not in place today is for a payment gateway to use Spreedly as an independent vault for customers who want their cards stored independently. Technically, it would fairly easy for a payment gateway to implement something like this.

They could create a Spreedly environment on the fly for each customer that wants this, and vault into Spreedly alongside their own vault.  If the customer wanted to change, they'd just say "create a Spreedly account and we'll move the environment over to it for you and give you a list of your currently active Spreedly tokens." From there the customer has an independent vault that they could process against - either via the Spreedly API or by having a new payment processor point to the vault.

Investing development resources with the sole goal of making it easier for customers to leave is a difficult concept for 90% of companies to embrace - so we don't expect a lot of pull from the payment gateways here. Which comes back to the opening title for this post - is there any real market demand for this from end users? (the push?) 

There's nothing quite like Spreedly around so maybe it's a lack of solutions/awareness. Or maybe it's just the fact that most people think they have flood insurance as part of their overall insurance policy and so don't ever think about it too deeply. It might be a financial mismatch. Feel free to drop us a line if you have feedback on this topic.

‍

Download the Payments Orchestration eBook Below