nikoschns_api

[tough jackal]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1460948545531285639

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

• nikoschns_best-practices, 6 days ago, 17 messages

[slim lynx]

hey! yes this is expected - if an invoice's amount due is below the minimum charge amount, then the invoice is automatically marked as paid, and the amount is added the customer's balance (to be added to their next invoice)

https://docs.stripe.com/invoicing/overview?locale=en-GB#open:~:text=If the amount due is less than the minimum chargeable amount%2C the invoice automatically transitions to paid status and Stripe debits the amount from the customer’s credit balance.

[charred elm]

Thanks. it seems reasonable. However, the next invoice failed to be paid. And it's the first time that something like that happened. I thought it was related with that.

[slim lynx]

ah, you're actually right that it's related, but it's a bit of a 'chicken vs egg' situation - I'll explain 🙂

so in a normal subscription-creation flow where a payment is due on on creation, you use the latest_invoice.confirmation_secret to collect the customer's payment method

this is then used to pay the invoice, and is used for future payments

but since there's no payment due for the first invoice in this scenario, this doesn't work (i.e. the invoice is marked as paid, without you needing to confirm the PaymentIntent)

the solution is to not use latest_invoice.confirmation_secret to collect and store the customer's payment method on the subscription

instead, when no payment is due on subscription creation, you should use subscription.pending_setup_intent.client_secret to collect/save the payment method

https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=subscription#create-intent:~:text=For subscriptions that don’t collect a payment up front (for example%2C subscriptions with a free trial period)%2C use the client secret from the pending_setup_intent.

this is the approach we recommend whenever you create a subscription with no payment immediately due - the subscription.pending_setup_intent is only populated in these scenarios

[charred elm]

Okay I see, so just to confirm, if a payment is made immediately I can keep using the latest_invoice.confirmation_secret
However, if no payment is made immediately I have to use the subscription.pending_setup_intent Is that right?

[slim lynx]

yep, exactly!

[charred elm]

Nice. Is there a way to identify if no payment is happening immediately?

[olive condor]

Well they are mutually exclusive properties meaning only one is ever set and the other is null. So you can infer from that

[charred elm]

Okay, so I expand both of them expand: ['latest_invoice.confirmation_secret', 'pending_setup_intent'] and I use the client secret from the one that exists (since they are mutually exclusive). And if the client confirms the with the extracted client_secret, the next invoice will not fail, right ?

[olive condor]

And if the client confirms the with the extracted client_secret, the next invoice will not fail, right ?
I don't think we can guarantee that it won't fail, no. The bank can decline payments/request auth at their discretion. We obviously apply optimisations and exemptions where eligible

Our recommendation is to have an integration that can handle declined/failed invoice payments, and bring the customer back on-session to handle the payment

[charred elm]

Sorry I wasn't very accurate. Let me rephrase. What I wanted to say, is that by picking the right confirmation_secret, next invoices will have the payment information needed so that a payment can be made. After this point, as you said, many things can go wrong.

[olive condor]

Ah, you mean you want to ensure that the payment details are saved and used for future invoices? You should be sure to set this parameter when you create the subscription: https://docs.stripe.com/api/subscriptions/create#create_subscription-payment_settings-save_default_payment_method

Then the resulting pm_xxx will be saved to the default_payment_method property on the subscription and used for each future invoice

[charred elm]

Yeah, this is what I meant. Okay nice. I basically do the same request as suggested in the guides. There was only this special case I mentioned in my initial message, where Glo also explained very nicely, and it seems that the pending_setup_intent could do the job.

[olive condor]

Yes, save_default_payment_method works in both cases where there is/isn't a payment so you're covered