daniel-nissenbaum_unexpected

[velvet locust]

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.

• daniel_ach-mandate, 20 hours ago, 53 messages
• daniel-nissenbaum_api, 1 day ago, 22 messages

[humble geyser]

👋 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/1237438793636646922

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

[real lynx]

Did you spcifically enable ACH retries as specified here?

https://docs.stripe.com/billing/revenue-recovery/smart-retries#ach-retries

[barren zenith]

yes exactly

its been enabled for a few months now (since it was even in beta i think)

[real lynx]

Do you have a Payment Intent ID I can look at?

[barren zenith]

pi_3P8VSiJmq474uon81k9wmuXl

i have many examples too, doesnt seem to work for a single failure

[real lynx]

Do they all fail with the same error? If I recall correctly, certain payment failures won't be retried. For example: if Stripe gets a decline for the charge due to "No account" (e.g. the account isn't open anymore), then the payment is not retried. Same for the error you got for this payment:

"The payment failed: The customer's bank account has restrictions on either the type or number of transfers allowed. This normally indicates that the bank account is a savings or other non-checking account."

[barren zenith]

that makes sense, but the vast majority fail for insufficent funds

which should definitely be eligible for a retry

the example i gave oyu is a bad one

[real lynx]

Do you have an example?

[barren zenith]

sorry

[real lynx]

All good! Just want to make sure I'm getting the right context

[barren zenith]

let me get you a insufficient funds example

pi_3P7lOEJmq474uon81yBRrUf2

[real lynx]

I believe, in order for Stripe to retry payments, there needs to be a mandate on file for each payment method. The two examples you sent me don't have any though:

Before retrying, make sure you’ve obtained authorization (https://docs.stripe.com/payments/ach-debit#mandates) from your customer to retry a debit on their bank account.

More on that here: https://docs.stripe.com/payments/ach-debit#mandates

[barren zenith]

const setupIntent = await this.stripe.setupIntents.create({
payment_method_types: ["us_bank_account"],
customer: customerId,
confirm: true,
payment_method: paymentMethodId,
mandate_data: {
customer_acceptance: {
type: "offline",
accepted_at: accepted_at,
},
},
})

is that this?

Actaully we do that elsewhere, not on our subscription flow

but in our subscription flow we confirm the setupIntent:

            await this.stripe.setupIntents.confirm(pendingSetupIntent.id, {
                payment_method: paymentMethodId,
                mandate_data: {
                    customer_acceptance: {
                        type: "online",
                        accepted_at: new Date().getTime(),
                        online: {
                            ip_address: ipAddress,
                            user_agent: userAgent,
                        },
                    },
                },

^ for trials

                await this.stripe.paymentIntents.confirm(paymentIntent.id, {
                    payment_method: paymentMethodId,
                    mandate_data: {
                        customer_acceptance: {
                            type: "online",
                            accepted_at: new Date().getTime(),
                            online: {
                                ip_address: ipAddress,
                                user_agent: userAgent,
                            },
                        },
                    },
                })

^for non trials

[real lynx]

I don't see any explicit confirm() calls for the example you gave me. It looks like Stripe auto-advanced the Invoice through to the attempted payment. In any case, it looks like you might be using the legacy sources integration, which could be what's causing an issue. Is this sort of an older integration?

[barren zenith]

its not older but we use sources because we integrate with plaid

and we cant get away from that because plaid is used by another vendor for users to fund thier account

so we dont want to make the user link their bank twice

[barren zenith]

you mean in the logs?

[real lynx]

correct

[barren zenith]

surely thats impossible

would be on the setup intent of the trialing subscription no?

https://dashboard.stripe.com/events/evt_1P5D6eJmq474uon8yUVMt19p

req_rVg11PEHHyEIUb

[real lynx]

Ah, apologies. For some reason my internal tool isn't surfacing the Setup Intent in my list. So yeah, scratch that. It's a red herring anyway

I don't think Stripe supports smart retries for the deprecated ACH + Plaid integration unfortunately

[barren zenith]

ah is that for sure the issue?

[real lynx]

I'm going to double-check, but I'm pretty sure it is

[barren zenith]

ugh sad

and there is no way to use plaid in the new stuff right?

sources is the only way correct?

[real lynx]

I'm confirming with a colleague. I'll circle back in a few

[barren zenith]

no probs, thank you!!

[real lynx]

Sorry for the wait, still working with a colleague on this

[leaden gulch]

Hello! I'm taking over and catching up...