4

I'm currently trying to implement a payment system (braintree) but I'm not entirely sure how this is supposed to work.

What I hope it works like:

  • User selects a product and clicks on "buy"
  • User enters a credit card to pay with and clicks "okay"
  • My client sends the credit card information to my server
  • My server forwards this to braintree (or paypal) and I get back a credit card ID token
  • Using that token I sign an agreement for the user, the credit card and my recurring billing plan and I notify the client whether it worked or not
  • User sees on the client that it worked and starts to enjoy the service

So, I don't want the user to require something like a PayPal account if possible. I'm also still not 100% sure how the braintree API works but from the looks of it I can create a Customer which has multiple credit cards. However, I'd need to transmit the credit card to my server which only forwards this information to the custodian.

If the answer to this is "yes, your server has to fulfillthe PCI compliance" then I'd like to know if it's actually possible to have a payment system that does not require a user account at the custodian.

Stefan Falk
  • 1,047
  • 1
  • 9
  • 11

2 Answers2

6

Yes, your server as described has to be PCI compliant. However, most processors support modes of operation, different than you describe, which will limit your scope*.

You say:

  • My client sends the credit card information to my server
  • My server forwards this to braintree (or paypal) and I get back a credit card ID token

If the credit card data is transmitted, stored, or processed by your server, then you server is in scope, and you are subject to a reasonably large set of PCI compliance such as SAQ C or SAQ D.

However, most processors support iframe and/or javascript technologies that will allow your server to be removed from the loop - the client sends their card data directly to the processor, and the processor hands them some chit which they can hand to you in lieu of a credit card to carry on the purchase. You, in turn, cash in that chit to get a token representing the card data that they handed the processor.

When such a technology is in use, and insulating your systems from any direct involvement with card data, then your compliance requirements drop down to SAQ A or SAQ A-EP.

You should ask your processor "What offerings do you have for tokenization that will allow me to keep my servers out of scope and reduce my PCI compliance requirements?" (If they say "huh?", find a new processor.)

[if so, is it] actually possible to have a payment system that does not require a user account at the custodian.

No. If you are allowing a processor to handle cards for you, then you must give them a bank account for use in transferring funds to (e.g., purchases) and from (e.g., chargebacks) you. And when they want the bank account, they're going to want all sorts of tiresome information like who you are. The processor is, in fact, sponsoring you into the card network. They are liable for your debts if you behave poorly.

(And that's true whether they're managing the actual card data for you (tokenizing) or just processing transactions... Credit card numbers are not useful without processing by the card network; you can't charge them without a connection to the system, and the system isn't designed for anonymous members. If you want anonymity, charge in Bitcoins or Simoleons instead of credit cards).

*If your business is accepting credit card payments, you're bound by PCI, even if you don't touch the actual credit card data yourself. The best you can do is reduce your scope - if you are subject to SAQ A, for example, you'll have ~15 requirements instead of ~300 for SAQ D.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
1

Braintree's documents show an example where the card data is directly send to them and you only get back a token. If this case would suit your needs then PCI compliance is not necessary.

So the flow would be like this:

  • User inputs their card data in a form created by the Braintree Javascript library and submits it. It goes to their server and they send back a token, which is inserted in a hidden field in your form.
  • Your form is then submitted to your server, but it contains nothing but a token that references the card kept on Braintree's servers.
  • Your server uses the token as if it was card data (you can associate it to customers, set up subscriptions, etc) but it can't be used outside of your Braintree account and is thus not part of PCI-DSS' scope.
André Borie
  • 12,706
  • 3
  • 39
  • 76