1

I'm working on a project with a new client and they've had some problems getting a merchant account for processing their online payments due to the business type. The system works in a similar way to Just Eat/Expedia etc in that a customer places on order on the site which is then passed on to the venue, with the site taking a commission.

The client asked if we could store customer payment details in our database (encrypted) and then pass them on to the venue for processing themselves using their in-house card systems. I know there are PCI Compliance issues with this but I've not been able to get a straight answer on exactly what we need to do. I've spoken to a couple of hosting companies and one is saying we need a cluster with separate web and database servers, while another has said we won't. I've never done something like this before, I usually just farm out payment processing to somebody like SagePay etc.

This is the proposed payment flow:

  • Customer places order on website
  • Payment details are stored in database
  • Customer is emailed an order acknoledgement. Venue is emailed an order notification. If venue accepts the order, order and payment details are transmitted for in-house offline processing
  • Once the venue has taken payment in-house, the order is confirmed and payment details are deleted from the site database
  • Customer is emailed a final order confirmation

I want to make sure any process is right, and the last thing I want is for the site to be attacked, payment details taken, and be left liable for any losses!

Any advice would be much appreciated.

Terry
  • 31
  • 3
  • The process is correct and sfe as long as the info is encrypted. I'd be more worried about pci compliance of the manual processing. – Hameed May 14 '12 at 12:45
  • comprehensive reference available at https://www.pcisecuritystandards.org/ – dm03514 May 14 '12 at 12:49
  • We won't have any interaction with the venues' systems at all. The idea is that they will use the Chip & Pin machines they currently use for processing in-venue transactions anyway. Would hosting with someone such as http://www.34sp.com/business-hosting be enough for this process or is a cluster required? Thanks – Terry May 14 '12 at 12:51
  • @Terry: To be clear, you're saying that the venues will be processing customer-not-present transactions using PDQ terminals, having retrieved the transaction detail from your web server over HTTPS? – eggyal May 14 '12 at 12:53
  • That's bad advice, "encrypting the info" is non-trivial (to do it properly) and covers about 1% of the huge PCI obligations relating to card holder data storage, remember there are massive card scheme fines for a breach following a bodged attempt at becoming compliant. Integrating with a hosted online payment solution from your vendors merchant will save you risk and cost (and to do this properly will be hugely costly). – Alex K. May 14 '12 at 12:54
  • @eggyal, that's exactly the plan. The details will be encrypted and stored within the database at the point of the order being placed, then transferred to the venue over HTTPS at a later date for them to process. – Terry May 14 '12 at 12:55
  • @AlexK. The client has spoken to merchant account providers and many are reluctant to offer an account due to the nature of the business (pre-booking event tickets). In addition, the proposed solution also overcomes the problem of the client paying % fees on the whole of the order value rather than invoicing the venues at a later date for the commission amount. – Terry May 14 '12 at 12:57
  • I would advise you to follow @AlexK's advice. However, failing that, so long as the user is aware that they are contracting with the venue (i.e. you are merely a communication intermediary), you should at very least use asymmetric (i.e. public-key) encryption in the customer's browser ([SJCL](https://crypto.stanford.edu/sjcl/) is a good starting point) to encrypt their card details using the public key of a keypair that only the specific venue with whom they are contracting has the corresponding private key. The venue could decrypt similarly and you will never have access to the plaintext. – eggyal May 14 '12 at 13:00

2 Answers2

0

You failed to include an actual question....

However: PCI compliance is non-trivial; there are multiple levels of compliance, and the standards are a little dense...in general, as long as you don't store payment details, it's relatively easy to comply. If you do store payment details, your compliance requirements become a lot more complex, and may include processes such as vetting employees.

Your intention to transfer payment details to the venues looks like a huge red flag - you're basically giving credit card details to third parties, which I as a consumer would not be happy about, and is almost certainly not allowed within any of the PCI standards.

It's worth talking to a specialist payment gateway provider about the options you have - for instance, most credit card transactions consist of an "authorisation" call, which submits the card details and amount; the service checks the card is good for the money, and "ring fences" the amount on the account, and issues back an authorization code. The actual "settlement" can occur later - up to 10 days for some cards, and can use just the authorization code, rather than the full card details. A specialist payment provider will know what options you have.

It may be possible for you to share the authorization code with your venues, to allow them to take payment (though this would almost certainly require you all to use the same gateway provider).

It would be straightforward to change the flow you mention to include auth/settle logic:

  • Customer places order on website
  • Your site issues "auth" using credit card details, store auth code.
  • Customer is emailed an order acknoledgement.
  • Venue is emailed an order notification.
  • If venue accepts the order, you execute the "settle" transaction
  • You confirm order details to venue
  • Customer is emailed a final order confirmation
  • Weekly/monthly/whatever you issue a report to each venue showing amount outstanding and send them a cheque or whatever.
Neville Kuyt
  • 29,247
  • 1
  • 37
  • 52
  • As well as a red flag I'm pretty sure that capturing details for processing by a 3rd party (i.e. through a merchant account not belonging to yourself) may bump you into the "Service Provider" level of obligation, which puts you in the hardcore yearly onsite-audit arena. – Alex K. May 14 '12 at 13:18
  • @AlexK: There's no reason one would need to capture the data - see my comment above. – eggyal May 14 '12 at 13:20
0

An alternative approach is to take the storage of credit card information out of your hands completely and put the burden on someone else who has the means and expertise to do so while making it easy for you to charge your customers when necessary. Authorize.Net offers their Customer Information Manager API which allows you to create payment profiles for your customers. They handle the storage of the credit card information and give you a payment ID for it. You then can charge against that payment ID whenever necessary without having to have access to the actual payment details.

John Conde
  • 217,595
  • 99
  • 455
  • 496