#oliviakristiansen-deferred-intent-subscription-start-discounted-to-free
1 messages ยท Page 1 of 1 (latest)
Asking because sometimes users will actually be paying $0 for the initial subscription purchase because they have enough credit on their account, but we still want to collect their payment details for future, recurring payments, but I can't pass in $0 if Stripe views that as a "free trial"
The amount that is charge will be the back end amount on the invoice (payment intent) ultimately
You should aim to get the client-side amount to correctly reflect the final payment amount, ideally
so what happens when they are actually paying $0 but they will not be going into a free trial?
If the payment ends up being $0 due to credit then you won't need to confirm a payment then, you might want to collect a payment method using a setup intent then, but i can see the challenge here
I want to add this to some feedback internally for us to iprove the documentation for the deferred-intent flow to start a subscription
Do you have a concrete example o this happening that you can share?
yeah, right now, the card element allows us to save the default_source no matter what, and I need to continue doing something that aligns with that
no, unfortunately, I just got tickets today to start the migration to payment elements, but I know this is a scenario we will face
So, when you know this is going to happen, you may want to do a setup intent instead: https://stripe.com/docs/payments/save-and-reuse?platform=web&ui=elements
does that just save the payment method to the customer and then when we try and charge the customer on the next billing date, the payment method will be charged?
or will I need to do something to attach it to the subscription?
ah I see "Successful confirmation of the SetupIntent saves the resulting PaymentMethod ID (in result.setupIntent.payment_method) to the provided Customer."
but will I need to update the customer or subscription object to use that payment method id?
Yes, you'll then want to set the resulting payment method to either the subscription default_payment_method or the customer invoice_settings[default_payment_method]
perfect yup cool
๐
thanks so much!
hi again
so what should I pass in for the setupIntent in the above scenario for "amount"? its erroring if I pass in 0 or not include it
oh sorry, I mean for the options oject in stripe.elements
If you're doping a separate setup intent, you'd use setup mode without any amount: https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=setup#add-the-payment-element-to-your-checkout-page
actually, let me try to test something here
ah okay gotcha
ok, so clarification here
When this situation happens (a discount or credit makes the initial invoice a non-payment invoice), there will be no payment_intent on the latest_invoice
Instead, the subscription will automatically generate a setup intent and return that as pending_setup_intent -- you can expand this just like the latest_invoice.payment_intent to get the client_secret
You can then use this client secret to call stripe.confirmSetup()
You can do this with the already configured mode=subscription for the payment element
And the amount will be disregarded
okay so if I do that in the backend for $0 purchases, the payment element will disregard the amount when I call confirmSetup? because it seems I have to send that param in
seems like thats what you're saying if I expand pending_setup_intent
๐ my teammate had to run so I'm stepping in here to help
Yep, that's correct. The amount will be disregarded
awesome
I have one last question if thats okay
you all are so helpful
what is the best way to validate the payment element? right now, we disable the submit button until they fill out the Card element, and I'm wondering if I can do something similar with the payment element
and I'm struggling to find that specifically
oh, you know what, I think I can just do it the same way we do now by listening for a change
I thought for a second we wait until its fully filled out, but we don't lol
Gotcha. There shouldn't be a need for this. The PaymentElement handles displaying any validation errors for you
product definitely will want our own submit button to stay disabled until they type something lol
I see. Listening for change events sounds like what you want