#oliviakristiansen-deferred-intent-subscription-start-discounted-to-free

1 messages ยท Page 1 of 1 (latest)

velvet beaconBOT
sage ore
#

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"

elfin lantern
#

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

sage ore
#

so what happens when they are actually paying $0 but they will not be going into a free trial?

elfin lantern
#

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?

sage ore
#

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

elfin lantern
sage ore
#

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?

elfin lantern
#

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]

sage ore
#

perfect yup cool

elfin lantern
#

๐Ÿ‘

sage ore
#

thanks so much!

elfin lantern
#

NP!

#

oliviakristiansen-deferred-intent-subscription-start-discounted-to-free

sage ore
#

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

velvet beaconBOT
elfin lantern
#

actually, let me try to test something here

sage ore
#

ah okay gotcha

elfin lantern
#

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

sage ore
#

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

rich maple
#

๐Ÿ‘‹ my teammate had to run so I'm stepping in here to help

#

Yep, that's correct. The amount will be disregarded

sage ore
#

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

rich maple
#

Gotcha. There shouldn't be a need for this. The PaymentElement handles displaying any validation errors for you

sage ore
#

product definitely will want our own submit button to stay disabled until they type something lol

rich maple
#

I see. Listening for change events sounds like what you want