Dos and Don'ts while integrating payment gateway without PCI Compliance

Question

I would like to have some clarification related to integrating payment gateway in my website, as our company doesn't have PCI DSS Compliance would like to know is it legal to pass the card details to a payment gateway through JavaScript code?

I know we should not save or store this information, or pass it to our server. And we are not doing this as well.

We are planning to integrate Razorpay payment gateway, using the JavaScript file provided by Razorpay. This JS file gives function to create a payment by calling method createPayment, where we have to pass payment data. Below is the sample data:

var paymentData = {
      email: email,
      contact: '9999999999',
      method: 'card',
      'card[name]': cardName,
      'card[number]': cardNumber,
      'card[cvv]': cardCvv,
      'card[expiry_month]': cardExpiryMonth,
      'card[expiry_year]': cardExpiryYear
};

This is how the code flow is:

1. We render input fields to enter card details
2. Read the data in each input fields from JavaScript
3. construct the data object needed to be passed to the payment gateway
4. Call method provided by payment gateway JavaScript and pass the object to this function as a parameter.

So my question is this legally correct way to implement? Also, I am not able to see any documentation related to this kind of implementation in Razorpay. But they do provide support for this approach now as well.

Please let me know if there are any other edge cases needed to be taken care while implementing Payment Gateway without PCI DSS compliance.

Answer 1

Let me start with a disclaimer that I'm not an expert in PCI compliance. This is my working knowledge to function as a developer and may not be entirely accurate. I recommend using this as a starting point to do more research.

Legal will depend on the context. In the US, PCI compliance isn't required by any federal legislation. Instead PCI compliance is enforced contractually with merchant service providers. For instance, here's an excerpt from ProPay's documentation:

All merchants must be compliant with the Payment Card Industry Data Security Standard (PCI DSS). For merchants that are integrating into the ProPay API, which includes the handling and transmission of card data directly, merchants are required to validate that they have completed the appropriate PCI DSS requirements.

If you want to process payments through ProPay, you are obligated to comply with PCI requirements. If you were to use ProPay, at some point early in your relationship, they will ask to formally baptize you into accepting the PCI DSS standard by filling out paperwork certifying that you're compliant with all of requirements outlined in the PCI DSS standard. Smaller merchants will have an option to pledge their allegiance by completing a Self Assessment Questionnaire or SAQ (pronounced "sack"). Larger merchants will have to hire some QSA consultant to submit a report on their behalf - which I know even less about.

You'll have a choice in which SAQ to fill out, depending on your exposure to credit card data. SAQ A can be completed if you have absolutely no control over how credit card data gets captured. If you are eligible to complete SAQ A, the work required to self-assess is supposed to be trivially easy.

SAQ A-EP is similar to SAQ A, but has many more requirements to self-assess. For reference: SAQ A has 4 pages of questions, SAQ A-EP 30 pages of questions. SAQ A has less questions because a number of the questions simply aren't relevant when you have no exposure to credit card data.

To your specific example: the library you're using sounds like you are responsible for reaching into the DOM to pull credit card data out of <input>s that you created. This makes you ineligable to complete SAQ A because of this requirement in part 2g:

The entirety of all payment pages delivered to the consumer’s browser originates directly from a third party PCI DSS validated service provider(s).

SAQ A-EP (again, part 2g) allows you to create the page that captures the data, so long as you don't actually submit it to your webserver:

Merchant’s e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor;

...

All elements of payment pages that are delivered to the consumer’s browser originate from either the merchant’s website or a PCI DSS compliant service provider(s);

Therefore, if you were to use a payment gateway that wants to validate your PCI compliance using a SAQ, you will be obligated to fill out the long, terrible, SAQ A-EP form instead of the SAQ A cakewalk.

Weirdly enough, Razorpay's landing page suggests they don't require merchants to be PCI compliant. I'm skeptical of that claim, but if they really don't require PCI compliance, you might not need to pursue it. I can't recommend defying PCI... but if they never ask you to validate your PCI compliance, you'll never have to fill out either SAQ A or SAQ A-EP.