Stripe does this really well using a js lib. The sensitive data thus never hits your servers and it's a much better experience for devs who don't want/have to deal with PCI compliance.
I'm not convinced using Stripe or similar services gets you out of PCI compliance.
The vast majority of PCI compliance requirements - those relating to server security - would seem to still apply. If someone hacks your server, they could easily add an additional bit of JavaScript that sends the CC field to a second, malicious server.
That's a worst case scenario and things could be worse if they hacked your production code base.
All data should be 256bit ssl encrypted for point to point security and asset tampering protection. After that, i doubt stripes js lib is much of a problem, it communicates in a secure tunnel from the client to stripe.
They as well say you don't have to worry about PCI compliance then because you are never handling financially sensitive data directly, only indirectly.
The GP is referring to doing client side Luhn validation on the credit card number, giving the user feedback if they mistype a number.
It's a technique I use, along with only allowing digits and doing some format masking (i.e. spaces or dashes to split the number into 4 digit blocks) to make the number more readible
Actually, the GP is talking about somehow building a startup based on... form widgets. He specifically said a "(subscription) service" - which would invariably require server-side support for these apparently startup-backed form fields.
Actually, these third party services can be a lifesaver when it comes to PCI compliance. If you use a service like Stripe in it's entirety then you don't have to worry anywhere near as much about PCI compliance yourself.
Has there been any actual confirmation of that? i.e. an official ruling from the PCI standards council?
Other than the long-term storage of credit card numbers stuff, most of it focuses on security measures I'd want someone using Stripe to have implemented.
After all, if someone hacks the server, they're going to have an easy time adjusting the flow to save the CC# that's supposed to only be going to Stripe.
But on the other hand, if anyone hacks any server, they're going to have an easy time putting up a page with a form asking for credit card numbers. For example say somebody hacked HN and added a "pay for premium membership" form, that just mailed off credit card numbers to the hacker...
Just thinking out loud really, I know nothing about PCI compliance or law.
I've written more on this elsewhere, but you're generally right.
PCI compliance rules are designed to test the serious risks that can be tested.
If the credit card data doesn't pass through your servers, then it doesn't pass through your servers.
Stripe complies the same way as PayPal; it just looks different to the user.
It's also worth noting that there's a big difference between data at rest and data in motion. If your site is hacked tomorrow and starts redirecting CC info, then all of the CC info between tomorrow and the day someone stops the hack is compromised.
If CC data is stored on your server in any way -- and this if it passes through your server, this may be the case even if you aren't putting it in a database -- then when someone hacks your server tomorrow, it's quite possible that all CC info entered since 2003 (or whenever you started) is compromised. That's a much greater risk.
The whole point is that third-party source code can change without your knowledge (or permission, etc). Or, worse, the third-party can simply be hacked.