#michal-prc_subs-failed-payments
1 messages ยท Page 1 of 1 (latest)
๐ 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/1299378100785774645
๐ 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.
- michal_paymentintent-bacs, 22 hours ago, 20 messages
- michal-prc_best-practices, 1 day ago, 8 messages
Hi ๐ can you share more details about the flow you're using? I'm not sure I understand what you're trying to describe and accomplish.
Is this regarding a failing recurring payment for a Subscription?
@green pollen checking in to see if you're around to share more details about what you're seeing? Can you share the ID of the Invoice and Subscription you were using for testing?
Hey toby
sorry for the delay
This is the subID sub_1QDkHPPw6OXqOwJctuow1lCX
invoiceId in_1QDkHPPw6OXqOwJc1UEuXTx3
Okay, so this is about the first payment for a Subscription that was just created by a Checkout Session failing asynchronously.
could you please elaborate on this
That's me elaborating on the scenario you're testing, since that context wasn't given and I want it in the thread in case a teammate needs to take over.
So Iv'e created a platform account and a connected account
then subscribed via checkout session using direct debit as a payment method
I used this test data form the docs sc 108800 acc 22222227
according to the docs the payment was supposed to fail with insufficient_funds
and then payment_intend status would change from processing to requires_payment_method
Docs: The payment fails after three minutes with an insufficient_funds failure code and the PaymentIntent transitions from processing to requires_payment_method. The Mandate remains active and the PaymentMethod can be used again.
I don't think that happens for the first payment for a Subscription like this.
Double checking that with a teammate though.
Yup, just confirmed, what you're seeing is expected behavior. If the payment fails based on the payment details provided in the Checkout Session, then we void the Invoice and cancel the Subscription.
The scenario you're describing of ending up with an open Invoice isn't supported if you're using Checkout Sessions.
Thanks for that, is there any alternative to checkout session that can be implemented via API?
Yes, you can use our Payment Element based integration:
https://docs.stripe.com/billing/subscriptions/build-subscriptions?platform=web&ui=elements
Thanks I'll look into that
One last question, so we are still using checkout session bacs DD, if a first payment succeds and then a subsequent one fails will the behaviour stay the same?
Hi ๐
I'm stepping in as my colleague needs to go
Hey, no worries
So you are asking if you create a Subscription using BACS DD, and the first Invoice is successfully paid, but the second Invoice payment fails?
Are you creating the Subscription in that same Checkout Session?
no the chackout session would be expired by then
I've got a platform account and connected account, a plan in connected account I subscribe to the plan via checkout session the payment method is BACS DD which is the only available payment method, the first payment is a success then the second is insufficient_funds. Is there a way to retry that payment?
Okay so in this scenario you
- Create a BACS DD payment method with a checkout session in
setupmode - Create a Subscription with that saved Payment Method
- The payment method fails on the first invoice
Is that correct?
I am not familiar with setup mode
I subscribe to the plan via checkout session the payment method is BACS DD
How is it that you are subscribing to the plan but not paying the first invoice in the same checkout session?
Do you have an example Invoice ID I can review?
I am using test data - in_1QDT4mPw6OXqOwJcIVbXUBUG
Yup makes perfect sense
I would always recommend users build a complete end-to-end simulation of billing processes in Test mode first
So in this case the issue is that BACS DD is an asynch payment method and you don't receive the failure until after the user has completed the checkout
I can't see any test data that would include a scenario where the first payment is success but the second one fails
You can achieve that. What you would do is update the Subscription or Customer's default Payment Method from the test data for a successful payment to one that fails with insufficient_funds error code.
so I have to do that manually? what about all other related events?
We are still talking about testing, right?
yes
Yes you would need to set that up manually (or write a script to perform those actions)
could you please tell me what data I need to update to what status and in what order?
What are you trying to test?
If you want to test a successful first Invoice payment and a failed second one. here are the steps I would take
- Create a Customer and save the successful Bacs Debit payment method as their default: https://docs.stripe.com/testing?payment-method=bacs-direct-debit#non-card-payments
- Create a Subscription for this Customer
- After Invoice is paid, update Customer with a failing Bacs Debit as their default payment method
- wait for the next Invoice payment to fail
You can speed up the process by using our Test Clocks feature which allows you to simulate time moving forward.
https://docs.stripe.com/billing/testing/test-clocks