Storing Credit Card Info

Question

So I know there have been numerous posts about storing credit card information. We are building a mobile application and want people to be able to enter in their card information once, not with each purchase.

We looked at Authorize.net CIM, and it appears to be an ideal solution (we just store a profile ID or Token that returns the credit card number)... but it might fall short of our needs, since the credit card information isn't processed (necessarily) by authorize.net but by whatever merchant account we are sending the payment too. In other words we want to store the credit card information like a wallet... not necessarily process with Authorize.net every time.

Reading the CIM XML documentation (p.94), it looks like the getCustomerPaymentProfileResponse masks the credit card return data... so I don't see how that would be useful for processing if the data is masked?

We do have some other options for implementation but I was really hoping to have a web-based way for customers to manage their payment accounts. Does anyone know of any ways to store credit card data that can be called on demand to be passed to any given merchant's processor?

EDIT 4.28.2011 - I'm hitting a wall with this. What if we don't store the credit card information at all, have customers enter it and then pass it... how do we do that securely? No storing it, pass along HTTPS, encrypt card data while in transit?

Answer 1

Sadly, there is no easy way to achieve this.

As you are aware, Payment Service Providers will securely store the card details, and return a token id (so that you can reference those details), but they can never return the original card details back to you.

This is because the PSP will have gone through PCI-DSS compliance. Part of that compliance is ensuring that anywhere the card details are passed (such as to other 3rd parties) is also PCI-DSS compliant. If they were to allow card details to be returned from the vault to the client, then they would need to ensure that the client is also PCI-DSS compliant (which would pretty much defeat the point of the client using a Payment Service Provider!).

Your options therefore are:
- Work through PCI-DSS compliance so that you can store the card details securely yourself.
- Store the card details to every Payment Service Provider that you interoperate with, and store the returned tokens from each.

Answer 2

Stripe does something like this. They process the card details without you ever needing to store them and give you back a token representing the credit card, which you can then:

• either make a one time charge on, OR
• save as a 'customer' and then bill in the future, either as needed, or in a automatically recurring way

There's a good RailsCast on billing with Stripe that's worth checking out. Very developer friendly.

Answer 3

Edit
I just realized Authorize.Net CIM is a kind of tokenization service. So you're probably aware of most of this. I'll leave the post here though - it maybe useful for somebody else.

If these merchants/vendors are willing to alter their API, I'd look into card tokenization. It's a feature offered by some processors that lets you transact payments without a card number. The way this works is on the first transaction the user hands their card info to the processor, which passes back a token to the merchant which uniquely identifies the cardholder data for that user & merchant, and the user's card data is stored internally by the processor.

You could then store these tokens and pass them to the vendor payment applications, which would in turn use them to process the transactions. I assume these tokens would be unique to a specific merchant, so you would probably have to store 1 token per vendor/merchant for a specific user.

There maybe a rule about this, where the vendor/merchant can't proxy tokens or otherwise get them from a third party. If that is the case, your vendors could supply a new token/guid that maps to the token they store internally for use with their card processor...

Google - credit card tokenization

PCI Standards

PCI-DSS is no joke, and while these merchants/vendors don't technically need to disclose to their processor that your application is storing card numbers, but if they do disclose it could get messy. Either of two things could happen:

• The vendor could be forced to prevent your application from using the API
• Your application would have to go through PCI certification