0

So we converted our website from an internally created site to a Magento Cloud environment. In the process, we had to change how we handle credit cards.

We used to redirect the user to the payment processor's site to complete the payment then come back to our site for the final receipt.

Now we have to handle the credit cards on the site because the developers could not get that redirection working with our current payment processor. We still do not store anything other than the token.

Since we are in the Magento Cloud and we have no admin rights to the code for the cart. Isn't that essentially a third party handling the payment process for us?

user2091722
  • 17
  • 3
  • 1
    Magento is not a [PCI Service Provider](https://www.visa.com/splisting/searchGrsp.do) so, from PCI's point of view, you're not offloading any of your obligations over to them. You're responsible. You should work harder, faster on getting redirection working. – gowenfawr Oct 09 '19 at 20:50
  • Can you explain how the tokenization works, e.g. redirect/iframe/direct post? – llmora Oct 09 '19 at 22:52
  • We ingest the card info and immediately give off to the payment processor which turns the number into a token we can use to reference the purchase. the number I assume can be skimmed. – user2091722 Oct 09 '19 at 23:06

1 Answers1

2

If the card number touches your servers in a readable form at all, you're under the full PCI SAQ D. You may be able to report N/A for parts of it (such as card data storage if you're not storing anything, assuming you aren't accidentally storing it server logs), but you still have to deal with evaluating the whole thing. Depending on your size, you may also be required to get an external QSA to audit you annually, but you're likely well below that threshold (6 million card transactions per year).

You can mitigate this in several ways other than a straight redirect. This question lists out the general options, and the accepted answer explains which SAQ level they'd each be.

Bobson
  • 1,456
  • 10
  • 12