Nark

[errant orchid]

Hey! Yes, with a direct Payment Intents integration you'd only be required to pass the amount parameter equal to the amount of the payment

[light flame]

ah okay, so those other features are for Stripe-hosted?

[errant orchid]

Payment Intents don't support line items, so you can't pass Price objects like you can with Checkout

Same goes for coupons/promotion codes – Payment Intents don't support those objects. You'd need to factor any deductions into your amount calculation

[errant orchid]

Well, you'd use Price objects (line items) with subscriptions in a non-hosted integrations

But for one-time payments with Payment Intents, they're not supported

[light flame]

Alright, seems more flexible then, and more customisable.

Since they're not supported by Stripe, but I could implement that myself.

[errant orchid]

Yep, exactly. Payment Intents generally provide more flexibility and customisation, but also come with more developer overhead

[light flame]

Also, how can I confirm a payment intent without using a frontend Stripe library?

e.g. I just want to call the API

[errant orchid]

There is an end-point for that, but its generally recommended to confirm client-side in case of 3DS/auth request

Also you should be using our front-end UI libs to collect payment details

[light flame]

But what if you wish to create it yourself and call the API yourself?

[errant orchid]

Do you have the necessary PCI compliance to be handling customer credit card data? https://stripe.com/docs/security/guide

[light flame]

Well, no, but I have seen it is required if transmitting the card data server-side.

Since it is client-side, what can go wrong with security anyway?

[errant orchid]

How do you propose sending the payment details you're collecting to us if not server-side?

Either way, in that scenario payment data is touching your server/application and PCI compliance is required

[light flame]

It is not touching your server.

The same way Stripe enforces it, create a payment intent server-side, and confirm it client-side by sending the card data to Stripe.

[errant orchid]

Right, but even in that client-side scenario payment data is still touching your application/server

[light flame]

How?

[errant orchid]

Users are inputting payment data on your site

[light flame]

That is not transmitted to you?

That stays client-side, only on their browser.

I have access to none of that.

[errant orchid]

I really recommend you read this guide as there's a misunderstanding here: https://stripe.com/docs/security/guide

[light flame]

I don't think there is? I don't see how using Stripe's UI framework changes anything to do with security?

Because create payment intent is done server-side (with no knowledge of card data), and then on the client-side, confirm payment intent is called to Stripe's servers with the card data.

That card data NEVER hits my servers.

[errant orchid]

Because we are PCI compliant

[light flame]

PCI-compliance does not affect client-side applications...

[errant orchid]

Users ares are inputting data input form elements on your UI

[errant orchid]

Yes, it does

[light flame]

How? If it is client-side, how am I ever seeing that data?

Just because the user has written their card details on their browser, which I don't have access to.

[errant orchid]

How do you propose sending the payment data you collect to us?

[light flame]

from client-side to Stripe directly, over TLS

same as how they do it with confirmPaymentIntent in Stripe.js

and from reading the PCI compliance regulations you sent, that seems all that is required, the payment data DOES NOT touch your servers and it is sent to Stripe over TLS

[errant orchid]

From the article I linked:

We strongly discourage passing card information directly to Stripe’s API as it means your integration is directly handling card information. Even if you don’t store any payment information, we can only help simplify PCI compliance if you’ve integrated with Checkout, Elements, or our mobile SDKs.

If you continue to send card details directly to our API, you’ll be required to upload your SAQ D annually to prove your business is PCI compliant. SAQ D is the most onerous of all the SAQs, with over 40 pages of requirements you must implement to remain PCI compliant. We highly recommend you migrate to client-side tokenization of card information to substantially reduce the scope of your PCI compliance.

[errant orchid]

Except that method is called using a Element instance from an iframe hosted on our servers

[light flame]

How does this make any sense though?... Stripe.js still handles card information directly, it just abstracts it away with a UI framework that are you in control of?

[errant orchid]

Because we have the required PCI compliance, and by using our hosted UIs (Checkout, Elements) you as a Stripe merchant are covered by that PCI compliance

[light flame]

But how can a UI on the client-side be non PCI-compliant in the first place?...

This is what seems counter-intuitive.

[errant orchid]

Because users are inputting card data into UI elements on your site. Whether its client-side or not, there is still an element of handling/processing card data which falls under PCI compliance

[light flame]

And are not when using Stripe.js? Are they still not inputting that UI data directly on your website?

[errant orchid]

No, because as I stated Elements (via Stripe.js) are iframes that are hosted on our domain. Therefore when your customer inputs card data into them, they're being handled on our servers:

This is possible because Checkout and Elements host all form inputs containing card data within an iframe served from Stripe’s domain—not yours—so your customers’ card information never touches your servers.

[light flame]

Ah, okay, but even without Stripe.js that data wouldn't touch my servers at all, so I wonder if it is a thing of in certain implementations it MAY touch your servers, therefore Stripe.js guarantees it doesn't, therefore they can certify PCI-compliance? But in my case it doesn't anyway :/

[errant orchid]

I think there's some terminology confusion here. I understand you when you say it won't touch your servers (e.g. a backend component), but as I previously stated:

Because users are inputting card data into UI elements on your site. Whether its client-side or not, there is still an element of handling/processing card data which falls under PCI compliance

Any kind of card data handling, whether that's in HTML/JS or a PHP server, requires PCI compliance

[light flame]

There is no terminology confusion, it's just what you are saying is different to the Stripe regulations.

It doesn't say about your application generally, it specifically says 'your servers'.

But, yeah, I sort of understand their logic, it seems like they are trying to remove all possibility of an abusing third-party or something like that, but still, no security damage could be caused on client-side.

[errant orchid]

To be clear, these aren't Stripe regulations. These are industry standard which we (and any other PSP) most abide by as a payment processor: https://www.pcisecuritystandards.org/pci_security/

[light flame]

I know, that's what I mean when I say 'they'.

[errant orchid]

Technically there's a server behind every web application, client-side only or not

[light flame]

Of course, but if that data is NEVER transmitted to the server, then why do you need to enforce that, it's literally handled in a browser?

[errant orchid]

We're going around in circles here

[light flame]

I know, but there is no definite answer you can give I guess.

That would have to given by PCI DSS

[errant orchid]

I've given you the definitive answer. I'd recommend speaking to PCI directly if you disagree with their requirements

[light flame]

You've given me, "the fact is, whether client-side or server-side, you're still dealing with card data", okay, fair enough, but in the client-side what can they enforce anyway, there are literally no security flaws?

Anyway, thanks for your help 👍

[errant orchid]

np!