#brett-t_india-mandate-failed-test
sturdy charmBOT
👋 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/1405623245184434300
📝 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.
- brett-t_webhooks, 5 days ago, 8 messages
turbid solar
well maybe its not a charge object
i just need the charge id
i was expecting it here maybe
"last_payment_error": {
"charge": "ch_id",
pine raptor
Hi 👋
Why are you looking for the Charge object?
turbid solar
see above im not
pine raptor
Or ID,
turbid solar
so i can query the charge
pine raptor
Why
turbid solar
to get the mandate_id so i can deactive the mandate on our end
ultimately i want to query the mandate id in stripe, to see the status of the mandate (active, inactive) and act appropriately
sry, bad timing, i have to step away for 15mins. I will be back in 15
pine raptor
I'll keep looking and post my findings here.
First, I noticed that in the creation request for the Payment Intent, the mandate ID was specified. This indicates you know the mandate ID prior to generating the Payment Intent. Would it be possible to keep a record of that ID and Payment Intent ID so that, when you get the webhook event indicating failure, you can look up the mandate by the Payment Intent ID?
Second, I notice the creation request is using the API version 2025-03-31.basil. I'm looking in our changelog but I think we defer creating the Charge until later in the flow so a Charge object may not be available when this payment fails. I am double checking this assumption currently.
turbid solar
ok im back
for the 1st question, its a possible work around we've discussed, we would just rather be 100% sure of the mandate we are querying before deactivating customer subscriptions and so forth. And today we use the charge to get that mandate for other payment methods we accept payment.success/failure webhooks on (all the others besides India credit cards).
pine raptor
Yeah that's understandable.
turbid solar
So its just not ideal, since we do this already for other payment methods (ach, becs, sepa), to have seperate flows for India mandates
1 thing i was wondering, the 2 test cards i used from your docs, is there something special about that type of failure where no charge was created?
For example, would a more regular decline, say insufficient funds, return a charge? And if so, is there a test card i can use to simulate that for India cc?
pine raptor
Let me test this myself. I just updated my test integration to the latest .basil API version
Hmmm so you are using these test cards. correct? https://docs.stripe.com/india-recurring-payments?integration=subscriptions#testing
turbid solar
yes
specifically these 2 i was thinking would get me a payment.failed webhook, and that turned out to be true
4000003560000297
4000003560000248
But my those 2 cards seem to have specific errors and i was wondering if perhaps those 2 special cases there is no charge created. There is no insufficient funds test card for india mandates that i have found
pine raptor
Hmmm... I'm having trouble getting the same webhook to fire
I'm trying to test out different alternatives here.
sturdy charmBOT
turbid solar
i think it is fired on an off session renewal. Its a little involved, you have to create the mandate with a PI on session, then use the mandate in a PI off session. for example here is the setup: https://dashboard.stripe.com/test/payments/pi_3Rw5SMDvB1CWiwib09ZC5Y5M
then here is the renewal where its used https://dashboard.stripe.com/test/payments/pi_3Rw5lUDvB1CWiwib1UKZzubv
so we do get a latest_charge for payment.success event. https://dashboard.stripe.com/test/events/evt_3Rw5mnDvB1CWiwib0sdblYeo
Just looking for that on a payment.failed event really
stone patio
hi there, taking over for my colleague here. payment.failed events wouldn't have a charge since the payment failed. I see from your request that you are passing the mandate on payment intent creation, are you storing it on your server? can you re-use it from there?
turbid solar
ok so any payment.failed webhook wont have the latest_charge ID, because there is no charge made on a failure?
stone patio
correct
turbid solar
ok
1 min\
What about in the "last_payment_error" object? I am seeing a charge in there, like:
"last_payment_error": {
"charge": "ch_id",
"code": "expired_card",
"decline_code": "expired_card",
....
"the id of the failed charge"
stone patio
are you trying to get the mandate from the charge? if so how?
turbid solar
thats the end goal, right now im looking for the charge id on a payment failed webhook. Today we get the mandate id from a charge like this: charge.payment_method_details.mandate_id
err mandate not mandate_id
i think its actually inside the payment method itself so like here is an example of the payment_method_details for one we use today. In the case of india mandates it would be a credit card type though
{
# "payment_method_details": {
# "bacs_debit": {
# "fingerprint": "VJUnWHshZaSVfJzS",
# "last4": "2345",
# "mandate": "mandate_1RBjOoCjBva2aZpBHDMiIhlI",
# "sort_code": "108800"
# },
# "type": "bacs_debit"
# }
# }
so charge.payment_method_details.card.mandate
stone patio
have you tried listening to charge.failed events and getting it from there? you'd want to test to make sure that the types of declines you get actually create that event
turbid solar
Ive got to run to the bottom of this rabbit hole before we start listening for a brand new webhook just for this India e-mandate case.
we already query the charge for the mandate and use that mandate, all from a payment.failed webhook today. Thats already written, so ive got to be totally sure we wont get a charge id before i create something new. Also i dont see a charge.failed on the failure india test card example today https://dashboard.stripe.com/test/payments/pi_3Rw5lUDvB1CWiwib1UKZzubv
pine raptor
Hi 👋
I'm back again as my colleague has to go.
turbid solar
k. i still think its possible that we might get a charge id inside of "last_payment_error", but maybe something about these failure test cards is special in that it doesnt create a charge for these cases.
but ive got to verify that somehow before i code for it.
pine raptor
I don't see any Charge being created prior to the payment intent failing
turbid solar
i see.
What do you think about my hunch then?
do you think these 2 failure test cards are "special" in that way? But a normal insufficient funds would have a charge id in the last_payment_error onject?
pine raptor
I understand the hesitency here. Unfortunately, recurring payments in India is a very troublesome integration and not all our test mode operations behave exactly as expected.
turbid solar
do you think its a decent assumption? Or should i not assume anything really?
im not going to hold you to it, im curious if you think i may be on the right track. But ultimately ill have to prove it before we do the work.
pine raptor
Honestly, this is where I'd be building some basic Test (or Sandbox) integrations to check any assumptions.
Even working at Stripe and reading the docs pretty much every day, I usually need to build simulations to really understand how all the APIs work in practice