zlacker

Glad you're liking Radar!

You're right that, if you don't use Stripe.js, PCI compliance will be more work.

And, yes, you can definitely include Stripe.js only on a single page.

>>pc+(OP)
We are, indeed.

As far as PCI compliance, I was just saying your comment about more work is true depending on your setup w/o using Stripe.js.

In our business we already have our own proprietary fraud models and other PII we secure, so the level of effort to keep PCI compliance for the additional Stripe components is a wash whether or not we use Stripe.js

I totally agree if you're going to use Stripe and you don't have to deal with PCI already in your normal course of business it's a complex area to navigate & using stripe.js is a much smoother path to take.

Basically goes back to basic principles, don't add more stress or work for something outside your core competencies unless necessary & in many cases, I can see where companies should just leverage stripe.js plus the UI utilities as they're well done & save a lot of time.

Big fans of Stripe, even if your ACH rates are significantly more than Wells Fargo or others :P

>>pc+(OP)
Wouldn't it be just a server side to stripe call on a form submit? Even easier than using js (probably not as good user experience wise)

>>wolco+C1
Sure, you could.

We more or less do this today, but if you need to setup a new workflow to take payments (one-time or recurring) there's a lot of work already done for you in the Stripe.js ecosystem.

So in our case, to take one-time payments it would've been more work to stand-up the checkout page itself and all of that work behind the scenes. It is much easier to just create a checkout session (basically just hitting the DB to pull the outstanding payment record and creating a stripe customer if one doesn't already exist) and redirect to Stripe's checkout.

The PCI part isn't overstated either, that checkout session lives on Stripe's domain not ours and that's where payment method is collected & stored within Stripe so you're not having to worry about it.

It's pretty nifty, give it a look - https://stripe.com/docs/payments/checkout/one-time

>>wolco+C1
I think that you will be on the hook for PCI compliance if card data touches your server, while with Stripe.js your server never sees the card data. Of course, it's extremely stupid, because your server is still the one serving the original page and can change it to silently exfiltrate the card details if it gets compromised.

>>Nextgr+h6
I mean, if your server is compromised, you are completely screwed, no matter what services you do or don’t use.

>>skoski+Ad
I believe the point was, if your server is compromised but you're using stripe.js, you're not legally on the hook for exposing CC details, even though they definitely could have been exposed.

(I have no idea if this is even true, this was just my reading.)

>>wolco+C1
> Wouldn't it be just a server side to stripe call on a form submit? Even easier than using js (probably not as good user experience wise)

Sure! You just have to also handle PCI-DSS.

One of the nasty things I've had to accept about PCI-DSS is that if you think you have a clever hack for getting around it, you probably don't. It's really a remarkable work of standards authoring.

>>pc+(OP)
> You're right that, if you don't use Stripe.js, PCI compliance will be more work.

That is not what @brogrammernot wrote. What @brogrammernot wrote was:

> As far as not using the JS, I was under the impression as long as you’re not storing the account or card numbers & utilizing the tokens properly you’re still at the base level of PCI compliance - meaning you’re securing your website, endpoints, data store etc in the same manner you should be already.

Note the the conclusion of "... in the same manner you should be already."