ironbeard

[errant tiger]

Hi there 👋

[dire salmon]

Heyo 🙂

My ideal flow would be something like this (Including steps not involving Stripe)

1. First form: visitor creates a "User" (email + password
2. Second form: visitor creates a "Contact" (first/last name, phone number, etc).
3. Once the Contact is created, I can create a "Customer" (stripe model) and a "Subscription" in the backend, and pass the invoice client secret to the front end via a third "Payment Form"
4. The "Payment Form" has the Card Element, etc. If the visitor was already a Customer, I want to provide an option to use their default card, or add a new card.

My concern is that when I create the Subscription, if the visitor is already a Customer, that it'll charge their default card then, instead of waiting for the next step to either get the new card or use default card (depending on what the visitor chooses).

Does this make sense?

When they submit the "PaymentForm", the front end would grab the client secrety from a (hidden) form field in the PaymentForm and run confirmCardPayment

[errant tiger]

Yup, that's an understandable concern, and is valid if you're setting the invoice_settings.default_payment_method value on the Customer object as that would be used to immediately process a payment when creating a Subscription.

I need to run a test to double check whether you can create a Subscription for a Customer that doesn't have a default payment method.

[dire salmon]

Yeah, my current method (which waited to create the Subscription until they had pressed that final "Submit" button, so I knew if they wanted to use default or new card), had logic that said "If they said use default payment method, grab their default payment method and set subscription.default_payment_method = payment_method"

That method relied on using js to send a post request to create the subscription after they either filled out card element or decided to use default. I guess I'm trying to create the Subscription a step earlier so I can pass the client secret to the front end via a form, instead of using ajax triggered by the final button submit.

(also, btw no rush from me, I know you guys are super busy. In 12 minutes I need to put my daughter down to nap anyways).

[errant tiger]

I did encounter an error initially when I tried creating a Subscription for a Customer that didn't have a default payment method, but I was able to avoid that by setting payment_behavior to default_incomplete.

I think the caveat with that approach, is that if you have the default payment method set in invoice_settings.default_payment_method we'll still try to charge that payment method. So I think you'll need to avoid setting that field, and leverage metadata or something similar to track what the default payment method for the customer is.

[dire salmon]

Interesting, I think I follow. So if I create the Subscription with payment_behavior='default_incomplete', pass the client secret to the front end and 1) use the card element to complete the transaction, then the Subscription will be paid and moved to active, right?

If, however they then decide to use their default payment (e.g., no need for the card element), what do I do? Update the Susbcription in the backend to use default payument? I guess that might cause an issue if the payment fails. 🤔

[errant tiger]

Yup!

There are two options for trying to handle the scenario where you're using a previously set up card.

You can set the default payment method for the subscription and then try to confirm the Payment Intent for the Subscription server-side, but if the payment fails due to the customer needing to complete a 3DS/SCA challenge then you'll need to use your frontend to display that challenge to your customer.

Alternatively, you can set the default payment method on the subscription, and then go straight to using your frontend. You can pass in the ID of the Payment Method via the payment_method parameter when calling confirmCardPayment:
https://stripe.com/docs/js/payment_intents/confirm_card_payment#stripe_confirm_card_payment-data-payment_method

[dire salmon]

Gotcha! So when I send the final form, before sending it I can create the subscription, then send both the client_secret and the id of their default payment method (if it exists) in hidden form fields and let them choose there which I use when calling confirmCardPayment.

[errant tiger]

Yup, that's what I'm envisioning.

[dire salmon]

Great, I'll try it out this morning and see! Thanks 🙂

[errant tiger]

Any time! Let us know if that doesn't work out.