5 ms·

Embedding a credit card field using third-party Javascript sounds scary.

by lamby 15y ago

yarone 15y ago
Why? Many of us use Spreedly / Chargify / Recurly. Imagine embedding a Spreedly form on your site. Still scary?
- ceejayoz 15y ago
  > Still scary? As someone who's currently looking over PCI compliance stuff: YES.
  - untog 15y ago
    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.
    - ceejayoz 15y ago
      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.
      - corin_ 15y ago
        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.
        jtheory 15y ago
        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.
bvdbijl 15y ago
I think you would want to inspect the source code before you use a third-party library in a case like that
- lamby 15y ago
  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.
  - ceejayoz 15y ago
    Well, only if you're linking it off someone else's servers. jQuery is third-party source code too, but I can host it myself.
    - lamby 15y ago
      Obviously. This was a response to OP putting forward a hosted solution.
gauravk92 15y ago
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.
- ceejayoz 15y ago
  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.
  - gauravk92 15y ago
    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.
taf2 15y ago
Nothing a hosted solution for more $$$ can't solve
taf2 15y ago
Nothing a hosted solution for more $$$ can't solve
elliotanderson 15y ago
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
- adgar 15y ago
  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.

Embedding a credit card field using third-party Javascript sounds scary.

by lamby 15y ago

Embedding a credit card field using third-party Javascript sounds scary.

yarone 15y ago

Why? Many of us use Spreedly / Chargify / Recurly. Imagine embedding a Spreedly form on your site. Still scary?

ceejayoz 15y ago
> Still scary? As someone who's currently looking over PCI compliance stuff: YES.
- untog 15y ago
  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.
  - ceejayoz 15y ago
    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.
    - corin_ 15y ago
      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.
      - jtheory 15y ago
        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.

bvdbijl 15y ago

I think you would want to inspect the source code before you use a third-party library in a case like that

lamby 15y ago
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.
- ceejayoz 15y ago
  Well, only if you're linking it off someone else's servers. jQuery is third-party source code too, but I can host it myself.
  - lamby 15y ago
    Obviously. This was a response to OP putting forward a hosted solution.

gauravk92 15y ago

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.

ceejayoz 15y ago
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.
- gauravk92 15y ago
  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.

taf2 15y ago

Nothing a hosted solution for more $$$ can't solve

taf2 15y ago

Nothing a hosted solution for more $$$ can't solve

elliotanderson 15y ago

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

adgar 15y ago
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.