#whisky_api
rugged sierraBOT
👋 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/1292947354542149653
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
alpine juncoBOT
agile token
Hi there 👋 do you see that Invoice returned in the list request if you also pass the ID of the associated Customer? I know this isn't what you're trying to do in the long term, but I'm trying to narrow down what could be causing this behavior.
elder bison
Yep, can see them in the CLI
agile token
Gotcha! The Customer you're using there is associated with a Test Clock, and I know Customers like that are excluded from Customer list requests unless you specify a test clock ID. I'm wondering if that is cascading into what you're seeing here.
If you create a new Customer in testmode, that isn't associated with a test clock, and create an Invoice for them. Do you see that returned in the list request?
I'm working on running through the same in my test account to see what I see.
elder bison
Give me a sec
Alright! I can an open invoice if the customer is not on a test clock!
So that's probably the problem 🙂
Do you mind to help me on another problem of mine or should I just open a new thread for it?
agile token
Yup, I think that Customer list restriction is cascading into the Invoice list call. I'll be sure to file a suggestion with our teams to at least make that limitation more obvious, if not implement a way for it to be avoided.
Sure, you can ask the additional question here.
elder bison
So currently we're implementing the subscription management from Stripe and I'm working on payments that require actions (https://docs.stripe.com/billing/subscriptions/overview#requires-action). In the documentation it says that the pending_setup_intent will be filled if action is required, but it's still null. For example in this subscription nothing changed: sub_1Q5r4QG3J6HysIYczmoC9azr. Do I have to configure something for it beforehand?
agile token
Let me take a look at that Subscription
elder bison
Ok, great. And thanks a lot for this quick help!
agile token
I see there's the request to create the Subscription, but then also several requests to update it. Can you help me understand where in that process you're hitting a payment requiring additional action, so I know where to focus my efforts?
elder bison
Yep sure. Maybe this one is messed up a little. So it should happen after the first invoice of 4788€ was not paid. This event here evt_1Q7NP1G3J6HysIYcr17cMNlA
What I'm trying to simulate is that a card gets after a while not accepted (for example because of 3DS reasons) and the customer has to authenticate this one
rugged sierraBOT
agile token
So pending_setup_intent is set on the Subscription object when the first Invoice doesn't require a payment. I see it was set on the Subscription, and then was unset when that Setup Intent succeeded.
The intent was confirmed here:
https://dashboard.stripe.com/test/logs/req_FyKot5u7dJHqwU
then 3DS was triggered and completed.
I don't think that field gets repopulated on the Subscription object if a specific Invoice's payment fails, instead you'd reuse that Invoice to continue processing the payment.
elder bison
So do I then have to use the payment_intent from the invoice to process the payment in the frontend?
agile token
Yup, exactly. You use the client secret from the Payment Intent associated with the Invoice that requires action.
elder bison
Okay. Does it make a difference to use setup intents vs. payment intents for subscriptions?
We used always the setup intents to process payments as we thought this is used for future payments
agile token
Setup Intents don't process payments, they only setup Payment Methods for future usage. They're typically used when a Payment Method needs to be created but a payment doesn't need to be processed at the same time.
So like Subscriptions that start in a trial period will generate a Setup Intent that you can use. The trial doesn't involve a payment so no Payment Intent is needed or created, but you can use the Setup Intent to proactively allow the customer to create a Payment Method to be used for the recurring payments.
elder bison
Alright. This makes totally sense now! One last question on this. If we do trials and a trial ends, should we now use a setup intent or payment intent to collect the payment method? It confuses me only in this scenario, because there's no invoice yet created, but with setting up the payment method it happens after.
loud pawn
👋 Stepping in for my teammate, give me a few minutes to catch up please!
elder bison
Alright! Thank you a lot 🙂
loud pawn
If you're working with trials, we recommend using webhooks and listening for customer.subscription.trial_will_end. This way you can proactively collect payment details before the trial ends and an automatic payment fails: https://docs.stripe.com/billing/subscriptions/trials#use-the-customer-portal-to-collect-payment
elder bison
Yep, thats what we're doing. But just to understand this more. Lets imagine a 14 day trial now ended and there is no payment method collected before. It's configured to be paused if the payment method is missing. To collect now the payment method, should we use a setup or payment method? As I now understand we use setup intents for future payments and payment methods if there is an immediate payment behind (like at an unpaid invoice). Should we use then here a setup intent as the payment will be generated after a payment method is collected?
loud pawn
Got it. You can use pending_setup_intent in this case
elder bison
Ok, great. Thanks a lot for the support 🙂