1

I am building a site which will accept payments. I will be processing payments with either Stripe or Square. Stripe now has Stripe Elements, and Square has Square Payment Form. I have tried Square Payment form but it's hard to customize and loads really slow. And I would like to have easy control over the look and feel of the form.

My question is, if I take the card information in regular input fields but don't store the information and instead immediately send it over to Stripe/Square via their libraries upon submit, is this still considered safe/PCI compliant?

1

You need to be very careful to understand if you are embedding an IFRAME from Square/Stripe or using JavaScript libraries. As the IFRAME or full redirect is currently classed as outsourcing as Joe says, and would be SAQ A - but a JavaScript implementation would need you to attest to compliance using SAQ A-EP. There's a quite old Visa document (I wrote) that describes this which also highlights the attacks.

https://www.visaeurope.com/media/images/Processing%20e-commerce%20payments%20guide-73-17337.pdf

The attack you need to be worried about is known as Magecart and uses rogue JavaScript to harvest the card data from your user's browser - described well by RiskIQ here.

https://www.riskiq.com/blog/labs/magecart-keylogger-injection/

Personally I always recommend that you fully redirect you customer to a payment processor (stripe/square etc) as this is the method of accepting that is least susceptible to attacks. PCI DSS compliance is only half the problem - the other half is looking after your customer's payment card data.

1

By making use of Stripe or Square you reduce your PCI burden since you are “outsourcing” handling of credit card information (CHD). This could make you eligible for filling in for example only a SAQ-A that has only a few mandatory controls to meet your PCI obligations.

The moment your site does ANY processing, storage or transmission of CHD, your PCI obligations increase. You might now have to fill in a SAQ-D for example. SAQ-D has a lot more mandatory controls that has to be adhered to.

If your site grows big enough and you have a QSA or Aquirer review it, you will have a hard time convincing anyone that your site does not store, process or transmit sensitive CHD. If you want to persist in creating your own site, review the various SAQ options to see what controls you will need to consider in your design.

  • SAQ A is only applicable if "The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated service provider(s)." -- this might not be the case so best to verify with Stripe / Square. – withoutfire Dec 21 '18 at 10:10
  • "SAQ-D has a lot more mandatory controls than has to be adhered to." This is just ambigously worded and I'm not sure how to correct it. I think I know what you mean, @Joe, but I don't want to change it to say the opposite if I'm wrong. – Adonalsium Dec 21 '18 at 13:37
  • @Adonalsium Thank you for spotting the typo, I hope it’s clearer than before – Joe Dec 21 '18 at 22:09
  • @withoutfire Both products have iFrame solutions and are widely used in industry. Agree with you that the the original poster should take care to implement the products as prescribed and preferably not make use of custom fields to pass information. Adding custom frames or additional libraries will require more controls to be implemented to meet PCI as you described. – Joe Dec 21 '18 at 22:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.