For every SaaS and eCommerce business that provides card payment options to its customers, the measures taken for the protection of their sensitive card information are of paramount importance. A security breach is every firm's worst nightmare; it could lead to a deep dent in a company's reputation, in addition to the monetary depletion.
To let your customers know that your data security is infallible, and to validate that claim, a PCI DSS Compliance would serve as the ultimate credential.
The Payment Card Industry Data Security Standard encompasses a set of practices and procedures required to be followed by companies (the ones that process, store, or transmit card details) to establish protection of their customers' card data.
Companies that process below 6 million transactions per year have to fill up the corresponding SAQ (Self-Assessment Questionnaire), while the other companies have to submit a QSA (Qualified Security Assessor) approved compliance report. The SAQs are further classified (into A, B, C, D) based on the way you handle the card information. Among those, SAQ B and SAQ C aren't applicable for the SaaS and eCommerce folks, and hence let's just talk about those that matter to us.
If you don't handle your customers' card details at any point of the transaction, SAQ A is meant for you (a good example would be when you are using your payment processor's secure iFrame/hosted payment page to record the payment information).
You'll be required to complete SAQ A-EP (a stricter version of SAQ A), if you're accepting the card information with your own form and then passing it on to your payment processor directly from the client's server, so that the data never touches your server.
Apart from these two options, you also have the most stringent form, SAQ D, which is meant for businesses that handle (process/store/transmit) card data using their own systems.
Click here to learn more about which SAQ is applicable for your business.
Note:
Let's say that you are completely outsourcing your card data handling and thus fall under the SAQ A category, but are processing more than 6 million transactions per year. What do you do then? You'll have to get a third-party QSA to certify that you adhere to SAQ A by completely outsourcing all your card data handling.
Chargebee is a PCI DSS Level 1 certified service provider, and here're your different integration options (and their corresponding SAQ form requirements):
With this option, you get to offer your customers a native checkout experience, and still use the Chargebee SDK (with the language of your preference). Behind the scenes, you can employ any of the payment gateways such as Stripe, Braintree, Authorize.Net, WorldPay, eWay, etc.
This allows you to let us take care of the complete checkout experience, with the help of customizable hosted pages that match your website/application experience. Like the first option, all of the payment gateways are compatible in this case as well.
With this option, you can customize and create your own checkout page. Once the customer's credit card details are entered in the hosted payment Fields or Components, the sensitive card information is encrypted and sent to the payment gateway. The processed information from the payment gateway is then sent to Chargebee as a 'Token ID'. The Token ID should be used in the Create subscription and Create payment source API to create subscriptions and payment methods in Chargebee.
In this option, you'll have to collect the card details at your end, and pass it on to Chargebee, which then forwards the information to Stripe.
Here the payment gateway of your choice (Stripe/Braintree) will give you a payment form that needs to be embedded in your checkout page, from which the card details are collected directly and sent to the gateway.
Similar to the previous case, you'll be using the iFrame provided by Stripe/Braintree in your checkout page, which will be recording the payment details, with no intervention from your side.
Further Reading: