Technical & Scientific > Programming

PCI Question

(1/2) > >>

ober:
So I have a client that has proprietary pricing.  He wants to have a secure page where people can respond to a quote that he sent out with modifications where they provide their CC info for future processing (sometimes they don't ship an order for 2 weeks because a lot of the work is custom and they don't charge until they ship).  The collection is all easy and fine.  Done that a bunch of times.  My issue is passing the CC info off to him.  I've only dealt with passing the CC off to a 3rd party where they process the payment and the CC info is gone.  I need to somehow securely get it to him and store it until he processes the payment.


That scares the shit out of me from a PCI compliance standpoint.  In an ideal world I would pass the CC off to a 3rd party to verify the card details and have THEM hold the information until payment is processed.  But I'm not even sure that is an option.  The last thing I want to do is just hold the information in a database somewhere and that gets hacked and he and I both go to jail.  I mean worst case I would only hold it until the payment is processed but still I don't like it.


Thoughts?

Mike:
I feel ya.  We looked at CC processing earlier in the year and quickly realized we don't want to do it ourselves and do want to use a third party.

I really feel like there is a 3rd party processor that can do this.  Entering the details at order time but not billing until shipping is super common.

From the bit I remember you basically want to separate out your web server from your processing server.  They should at least be separate VMs.  The processing server should be encrypted at rest.  The rest I don't quite remember.

Honestly, this is an area that I wouldn't touch.  Too much potential for things to go wrong and a ton of civil liabilities.

KnuckleBuckett:
Tell him 3rd party.

micah:
What third party system are you using?

I know with Authorize.net and Stripe (the only two I've worked with other than basic paypal stuff...oh and a really shitty vendor named Payliance*) they allow you to (optionally) pre-auth a card and then store a token for that customer and charge at a future date.

For example: https://stripe.com/docs/saving-cards

So, like you're doing now, the actual PII and PCI-related data stays at the 3rd party and you just charge it later via API or their web-based dashboard (if the gateway provider has one)

*edit: I just remembered, payliance was for ACH transactions and did NOT store data, in that case I encrypted the account number in the database.  I never had a security or compliance audit so maybe I didn't do it 100% correct but, it was a secure encryption method and the database was on a different server than the decryption key.

ober:
I don't have a 3rd party system with him right now.  I've used Sage (2 diff versions), Paypal, Stripe, and ... something else I can't remember.  He uses Comerica Bank which claims to have merchant services so I probably just need to call them to see what they offer.  I really don't like this project at all honestly.  I mean it's not complicated as far as the concept but the risk is through the roof if not handled properly.

Navigation

[0] Message Index

[#] Next page