Storing Credit Card Info

8
votes

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?

3
payment-gatewaypaymentcredit-cardpci-dss
Yes, I agree the Sony thing was very timely. I have no desire to store the information in our databases.... way to risky IMO. – Nick
Just a suggestion. DO NOT store this information on the phone itself. If you store it on a website so your customers can manage a customer profile be sure you invest in SSL certifcate. I would even go as only collecting what you need so what happen to Sony does not happen to your company. – Security Hound
As to your question I would simply contact Authorize.net support staff to be honest. What you don't want to do is store full credit card information unless you have to. Be sure to allow the customer only the choice of saving the information. I always thought that most vendors simply stored authorization number when dealing with this sort of information after the first transaction. – Security Hound
Yeah, the problem is that we are going to be integrating with several different vendors.... really depends on where the app is being used. So I really only need the storage part, not the processing part. – Nick
If it were me, I'd work with your processor. For example, the Authorize.net solution sounds ideal if you processed through them. And your processor may have specific requirements about this. So I'd contact them. – Jonathan Wood

3 Answers

8
votes

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.

3
votes

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.

1
votes

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