#k3davis-payments
timid scroll
Hi 👋 if you don't have a long-term user for the customer objects then you don't need to create them.
torpid sentinel
If I don't do that, though, there is no PII on the transaction, as far as I can tell (not even name)
unless i'm doing it wrong(tm)
timid scroll
Do you know which of our flows you're currently looking at using?
torpid sentinel
i was trying payment intents (it's a backend only implementation at the moment)
if another is more appropriate, i'm happy to have input
it appeared that charges api and payment intents were the only ones that supported a fully backend use case (no JS), and payment intents seemed upgradeable in the future.
timid scroll
Before we go too much farther, I want to make sure that you're aware that creating payment methods with only a backend requires you to handle raw card information. This means that you will be responsible for your PCI compliance requirements.
torpid sentinel
Yes, that's understood. We currently have PCI scope with our present provider, so we're hoping to do a phased transition and eventually eliminate it, but not rewrite the whole stack at once 🤣
timid scroll
Haha, gotcha, that makes sense.
In that case you will need to create a payment method, and a payment intent at minimum. When creating the payment method the billing_details can be used for storing information about the customer. Is that what you're looking for regarding a place to store PII?
https://stripe.com/docs/api/payment_methods/create#create_payment_method-billing_details
torpid sentinel
ah, i didn't notice that property on the payment method. i'll give that a try. i appreciate your help!