1

I have an application that requests Credit Card information to do a payment to a third party company.

My application captures the CC, CVV, Expiration Date, etc. and then passes that information to their API that charges the customer.

I've been reading about PCI Compliance but based on the following image, I am not quite sure what level of compliance I would need to meet.

enter image description here

Lastly, I would like to figure out what would be the best options for me in case I have a new purchase from the same client. Since I am not charging the customer but the third party does, how would be the best way to store the payment information so user doesn't need to enter his information every single time they want to use my service? What would be the implications of storing payment information on my servers from a PCI compliance point of view? Is there a way where I don't need to store the payment information for the user but I can pass their information (if they are a returning customer) to 3rd party API and still being PCI Compliance?

user3587624
  • 1,427
  • 5
  • 29
  • 60

1 Answers1

2

Since you're building a web application (even embedded into Facebook messenger), if you're building out the form that collects card data, you're going to either fall under "Shopping Cart - Payment Page Direct Post" (which is A-EP) or "Shopping Cart - Payment Page Not Outsourced" (which is D-Merchant). You really want to be under A-EP if you can, but you may not be able to.

The difference between the two is whether or not the card data crosses through your servers. With "Direct Post", the web page itself sends the data (usually via HTTP POST) to the payment API, and you have no way to capture it. With "Not Outsourced", the data comes back to your server, which then calls the payment API and passes it along. In that case, you're going to have to go through the entire D-Merchant questionnaire (by far the longest, other than D-Service Provider), and probably have a special environment set up to prevent anything from trying to read the card data as it transits your server.

There's really no part of the card data that is worth storing to try and identify a repeat purchaser, because you won't have the payment data to actually complete a payment. Instead, you should see if your payment provider provides any type of "token", which can be used to identify that payment data later. If so, you can associate that token with the customer (however you identify a customer) and reuse it when they return.

Further reading: https://www.pcisecuritystandards.org/documents/SAQ_InstrGuidelines_v3-1.pdf

Bobson
  • 13,498
  • 5
  • 55
  • 80
  • Would be easier for me then to use some sort of third APIs like stripe to avoid building my own form and then being under A (or A-EP) category? I will check out with the third party API company whether they could provide me some sort of token after completing a payment so I can use it for future payments without asking the user the payment information every single time. (For that I will need to map the token to a given user as you pointed out) Thanks! – user3587624 Jul 03 '17 at 02:33