[dangrossman]

I always recommend people build their payments on Spreedly (https://spreedly.com/).

It checks off the boxes for minimizing PCI scope; you store no payment information, and collect none on your website either. You can either do a transparent redirect (your payment form points to a URL on their domain, which redirects back to your site with a token) or an iframe.

Once you collect payment information, which they tokenize and store, you can run charges/auths/refunds against it using any of 81 different payment processors and gateways. Balanced one day, Stripe the next, and whatever startup is popular after them in a year -- without changing any of your payment code.

[aethr]

Does anyone know if using transparent redirects actually waives your responsibilities for PCI compliance? Even though the credit card details aren't sent to your backend, they are still collected on a form hosted on your infrastructure.

If your servers are compromised and malicious JS is added to your payment form, couldn't an attacker siphon credit card details via AJAX? It seems like the PCI documentation always uses terminology like "sites that collect credit card data", which I think sounds broad enough to include sites that use transparent redirects.

[dangrossman]

As of PCI-DSS v3 (January 2015), a transparent redirect qualifies you for SAQ A-EP, which is 100+ questions along with quarterly scans and annual pentesting. Basically, your website is "in scope" for securing.

The iframe option still qualifies you for SAQ A, which is the short questionnaire without scanning/testing requirements.

[mirashii]

It's generally transparent redirects in the other direction. You load JS from their servers, the form posts to their servers, redirects back to yours. Often even the form isn't hosted on your infrastructure, but instead embedded into your page through some JS that is hosted elsewhere.

If your responsibilities weren't waived or significantly lessened, I'd imagine companies like Stripe would be significantly less successful.

[aethr]

You generally don't need to load any JS from the payment processor to use a transparent redirect, although I'm sure some work this way. Transparent redirects just require setting the form action property on your payment page to a URL on the processor's site. The processor then silently redirects back to the next step in your process.

Using an embedded payment form also shouldn't require any JS, as it is usually done using an iframe. This method should be safe, as the same-origin policy in the iframe would prevent JS on your domain from interacting with form elements in the iframe. But this is not typically what people are talking about when they talk about a transparent redirect.