I'm developing a web application for hotels that send offers to the guest's hotels. I want to store the guest's credit card data in a secure way, through a third party service as I don't want to implement a PCI compliant solution myself.

I don't want (and I cannot) process the payments, as each hotel has its own payment gateway and it will process the payments later on. However we should give to each hotel the capability of accessing credit card data upon offer acceptance by guests. Hotels must perform antifraud check (like 1$ transaction) or introduce the cc data in their payment software system.

I would like to understand how this workflow could be achieved: most of the online services offer "tokenization" as a storage solution.

Which seems good, but I don't know how the send the card information to the hotels. It seems to me that tokenization is used to perform later the transaction, which I cannot do on behalf of the hotels. Moreover, once tokenized, it seems to me that data cannot be recovered. Each hotel must be able to actually see and use the cc data of its guests.

Any help and/or reference to a suitable provider is welcome.

  • Are you even sure you're allowed to store-and-pass-along CC info for creating charges by 3rd/4th parties?
    – Joel
    Commented Jun 22, 2013 at 18:19
  • This is a excellent question, which is a general problem in the hotel industry. At the moment I don't see any good solutions though that can deal with this sort of transmission of card holder data
    – neildt
    Commented Feb 21, 2015 at 12:25

2 Answers 2


If you touch the cardholder data at all, even if only to receive them and immediately transmit them elsewhere, you have PCI to worry about. (Maybe not directly - if you are not taking payments yourself, you don't have that as a contractual responsibility... but the merchants who do must ensure you, as a third-party service provider, are compliant.)

A tokenisation service only allows you to reduce the number of systems that are in scope, by taking storage out of the equation; it doesn't allow you to escape PCI entirely. You would have to create your own workflow for distributing tokens to third parties and authorising them (strongly!) to view the detokenised numbers; and this would certainly be subject to all the rigours of PCI.

Merchants avoid being dragged into PCI scope by letting a payment processor deal with the whole flow of cardholder data - redirecting the user into their processor's web site when it's time to enter card number, and redirecting back out at the end. I am not aware of any service similar to a payment processor that will take those details for you and, instead of doing an transaction, hand them over to a separate merchant party.

Your model is inherently pretty risky. Your merchants will be doing Card Not Present initial transactions without either the security code (CVV2 et al) or 3-D Secure (VbV et al) in this workflow. This puts a lot of liability on the merchant's shoulders, and puts you at risk of legal fun if there is anything at all wrong with your systems.


My first thought: if you use a 3rd party for CC info storage, but have the option to fetch that CC info from that provider, it would actually be equivalent to you storing the data yourself.

Tokenization is used exactly so you'll have "access" to the CC (so you can create a charge), but can't see the CC info itself.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .