#janus-reith-radar
feral tangle
Hey there - the CVC is something you'd collect securely at payment time via elements
The billing details you'd need to associate with the method method, which you can do when confirming the payment by providing billing_details like you see here:
https://github.com/stripe-samples/accept-a-payment/blob/main/custom-payment-flow/client/html/card.js#L63-L73
obsidian arch
Hey @feral tangle, yes that was my understanding too, CVC is collected within Elements during payment, but nothing that needs to be taken care of on our api side separately, since that goes right to stripe from the client side, so that confused me.
Should the billing address be passed with confirmCardPayment, and does passing the address impact the risk evaluation?
And, is "enhancing" an existing payment intent with an address possible later on the server-side, before capturing it?
I would prefer doing that, since we encrypt user addresses internally and I like to keep the surface as low as possible
feral tangle
It can, yes, in countries where issuers use that information., but we can't say precisely what the issuer will use in their decision
obsidian arch
Thanks, okay so that might be enough reason to add it
I just checked out the example you sent, and noticed that billing_details are passed within payment_method.
The payment Intent api also mentions payment_method here: https://stripe.com/docs/api/payment_intents/update, so I might be able to update it server side.
This might work for my usecase of getting the proper risk score (only in case that score gets updated if the intent contains new data and is not determined only once ), it would however not help with potential rejection by issuers during confirmCardPayment, so I can see why it might make more sense to pass it there
covert geyser
catching up here one sec
just confirming your question - you want to pass billing_details under confirmCardPayment() right?
because that is what I would recommend
obsidian arch
Hey, yes in the meantime that's what I decided to likely do too
Originally, I had planned to create the payment intent with minimal data, let the customer confirm it, and then on the server side update the payment intent with theses billing_details - Hoping, that might help with the risk score, which I would then evaluate before the next step, which would be to capture the payment.
Consideration here was that so far we don't have a problem with payments being rejected, but rather fradulent ones potentially passing too.
But I see why passing it with confirmCardPayment makes sense.
Just to confirm, when using Google/Apple Pay with the Payment Request API, we would not pass that info on payment_method, but just pass an ID string there - Instead, the relevant data like address is passed on stripe.paymentRequest here, right?
Atleast thats how we do it currently
covert geyser
so yep I'd highly recommend passing it on confirmCardPayment()
and for your other qs
we would not pass that info on payment_method, but just pass an ID string there - Instead, the relevant data like address is passed on stripe.paymentRequest here, right?
yep with PaymentRequest Button it should already have the billing_details on the PaymentMethod, you just need to pass the PM ID