Credit Card Storage

NZ_Kiwis

Is there a standard accept way to pass credit card numbers for payment in PHP?

I've been given the project of having a booking system for some clients, i've been asked to collect a credit card for payment via this form. How can I store or pass this onto my clients safely.

Obviously I don't want to email it.
I don't believe storing it in a mysql database is safe.

What do I do.

I would use google check out or PayPal if I was collecting payment myself.

laserlight

Hmm... you're saying that the customer submits the credit card details, then instead of passing them on to an online payment gateway, these details are supposed to be passed to the customer, who then processes payment manually using those details?

If so, it is not obvious that email won't work, e.g., if the server and the customer have a pre-arranged secret key, you can encrypt the credit card details and send them by email. Or to avoid the case where the server is compromised and the attacker also intercepts the email, you could involve a public key cryptosystem to encrypt the keys used to encrypt the details (and this can also be used to securely store the details in the database)... the problem is that this sounds straightforward in theory, but is easy to get wrong in practice, hence the general recommendation to avoid storing credit card details by immediately sending them securely to an online payment gateway.

NZ_Kiwis

what is the best way to encrypt this information

laserlight

Ugh, I made a typo: "passed to the customer" should be "passed to the client". Still, is that the situation that you are facing? You should describe the process in greater detail before any talk on "what is the best way to encrypt this information".

NZ_Kiwis

I knew what you meant and you had it correct, I collect the payment from customers and pass it onto the suppliers to charge for the goods.

So back to the question, how to encrypt this information?

laserlight

NZ_Kiwis wrote:
how to encrypt this information?

I think your best bet is to sub-contract a PHP developer who is professionally well versed in integrating crypto. Attempting this yourself when you are currently clueless sounds like a recipe for disaster.

That said, if you have no other option but to do this yourself, then searching the Web for a library that can correctly abstract away the details for you may be the next best option, assuming that you can trust whatever you find.

Otherwise, I suspect that you are left with using the mcrypt and openssl extensions. The mcrypt extension can be used to encrypt the credit card details, e.g., with AES using MCRYPT_RIJNDAEL_256; the openssl extension can be used to generate the key and IV for the symmetric key encryption and for the public key encryption of that key generated. (You can also use it alone, but it seems to me that you are more likely to use mcrypt correctly for the symmetric key encryption.) You also have to consider that you will need to sign the data to detect tampering.

EDIT:
Oh, I noticed that in another thread you asked about "developing secure pages". Indeed, even if you get an expert to design and implement this correctly for you, it will still be insecure if the credit card details coming to the server from the customer are not securely sent through SSL/TLS or an equivalent.

Weedpacket

Not incidentally, if you're talking about storing credit card details (as suggested by the thread title), be aware that credit card companies have security standards that they require you to comply with (the PCI Data Security Standard). Looking at that will give you a better idea of what you will need to do.

NZ_Kiwis

I was thinking, could I use Google checkout to take payment then pay the suppliers myself - can I make payments to others via Google? or can I just accept payments?, finally can Google checkout be customised to suit my personal website style in anyway? if so to what extend?

laserlight

NZ_Kiwis wrote:
could I use Google checkout to take payment then pay the suppliers myself

If your suppliers agree concerning such an arrangement, then the answer is obviously yes.

NZ_Kiwis wrote:
can I make payments to others via Google? or can I just accept payments?, finally can Google checkout be customised to suit my personal website style in anyway? if so to what extend?

This is not the right place to ask such questions. You should start by reading the Google Checkout documentation, then approach Google customer support and/or the relevant community for help.

NZ_Kiwis

laserlight;11014165 wrote:
If your suppliers agree concerning such an arrangement, then the answer is obviously yes.

This is not the right place to ask such questions. You should start by reading the Google Checkout documentation, then approach Google customer support and/or the relevant community for help.

Well obviously I would ask them first!

I thought I would get an answer like that, if I go to google I'll get a google sales spin on it and here I may get a more balanced opinion, or I may even get information on another provider that does something similar to Checkout that i've not heard of thats not PayPal!

laserlight

NZ_Kiwis wrote:
if I go to google I'll get a google sales spin on it and here I may get a more balanced opinion

Well, you asked about what can Google Checkout be used for, rather than whether Google Checkout would be easy to integrate or better than X for your purposes. Google Checkout either can, or cannot, be used for what you're asking for. That's fact, not subjective opinion, hence checking the docs would be better. Google cannot be biased about that, or it would be providing technically incorrect information (and perhaps also false advertising).

NZ_Kiwis wrote:
I may even get information on another provider that does something similar to Checkout that i've not heard of thats not PayPal!

Yeah, there are quite a few payment gateway alternatives out there. If you want to ask people for their opinions of them, use the Echo Lounge forum.

johanafm

But why bother with storing credit card details in the first place? Why not simply use one of the several ways to get that information to the credit card processing company?

All communication using SSL/TLS
1. form to user
2. info to credit card company
3. info from CCC about success of payment
4. info and possibly goods/services to user.

laserlight

johanafm wrote:
But why bother with storing credit card details in the first place? Why not simply use one of the several ways to get that information to the credit card processing company?

Because under the original scenario, that simply would go against the agreed protocol between NZ_Kiwis and the merchants. It turns out that that protocol is not required, hence the talk about using Google Checkout and then paying the merchants.

johanafm

Exchange CCC for merchant and do it the same way then. That way still leave the icky parts of securely storing CC info to the merchanges, unless they also opt to just pass it on to the CCC who have allready solved this issue. Or do I still miss the entire point?

sneakyimp

If the original plan was to send collected credit card numbers to the client(s) so that they could collect money, then it would probably be pretty easy to force the clients to get a merchant account and then use a transaction gateway (e.g., Google Checkout or Paypal or Authorize.net) with credentials specific to each client to collect the money for them.

i.e.,
1) Kiwi builds a site selling goods for ClientX which collects credit card data from customers
2) Kiwi tells ClientX "yo get yourself an authorize.net* account and hook it into a merchant account then send me some authorize.net API credentials"
3) Kiwi uses the authorize.net api in his site to handle payment transactions
4) CustomerY hits Kiwi's site and buys something
5) Kiwi's site takes the payment information from CustomerY and connects to the Authorize.net payment gateway which processes the transaction. The results in money being transferred by Authorize.net from CustomerY into the merchant account owned by ClientX

If you have more than one client, each will need their own merchant account and authorize.net account. Alternatively, you could create your own authorize.net account and merchant account and collect the money yourself into your own account, but then you have an accounting task on your hand and you'll need to figure some way to send payments to all your clients.

*Or paypal or google checkout or amazon payments account