#florian5262

1 messages · Page 1 of 1 (latest)

winged egretBOT
stray sluice
stone spear
#

Ah, okay, even after creating the subscription, I still need to call paymentIntent.confirm(), even though I already passed the paymentMethodId when creating it via the Java SDK?

stray sluice
#

Yes potentially. As the bank still might request 3DS, which they have in this case

stone spear
#

Do i need parameters for the confirm call or is it without okay because i passed alls informations before?

stray sluice
#

You should just be able to to confirmPayment({clientSecret: ...}) if there's already a pm_xxx attached to the PI

stone spear
#

ok, thank you very much!

stone spear
#

Unfortunately, another question has arisen. I created the subscription using the Java SDK. How do I get from the subscription to the PaymentIntent that needs to be confirmed?

warped horizon
#

subscription.latest_invoice.payment_intent

#

it's described in the docs above

#

to be clear

. When a customer chooses a credit card that requires 3D Secure, this is usually handled by the Elements. Then, a subscription is booked via the Stripe API. However, the subscription is incomplete
your flow sounds backwards here and it sounds like you charge the customer twice? How do you handle 3D Secure the first time?

#

the default/normal flow is that you start by creating the Subscription, then you just use the PaymentIntent on the frontend, which does 3DS/charges the card/activates the subscripion.

stone spear
#

Thank you for the explanation. The entire flow looks like this for us: First, we create the customer via the Java SDK, who can then create payment methods with the Stripe Elements. Then, they select a subscription and book it with the previously defined payment method

warped horizon
stone spear
#

But if the backend calls subscription.create, can't I directly confirm the paymentIntent in the backend afterward?

warped horizon
#

well you can(that attempts the payment) but then what will you do if 3DS is required?

stone spear
#

ah good question. My idea doesnt work if 3DS is on every transaction required

warped horizon
#

sure, which is why our documented flow is what it is and implies client-side payment confirmation