bk_ach-error

[tranquil grove]

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

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

[sweet kayak]

Can you share an exact error's request id req_123 so I can understand what you are doing?

bk_ach-error

[torpid hill]

There's 2 errors I am trying to track down resolution for

Here's the first: req_fHMXDbxepwheKM

I think I understand this error, but I am trying to figure out if simply enabling the payment type of ACH accounts will fix this? Is there a way to tell if someone recently disabled this for our team (I played with it today. Was off and then toggled it on and back off).

[sweet kayak]

so here you are explicitly using our "dynamic payment methods" feature. You wrote code explicitly to enable it. And you never turned on ACH debit in your Dashboard at https://dashboard.stripe.com/settings/payment_methods

So that's the error. Turn it on and the request will work (though really you should be debugging this in Test mode)

[torpid hill]

Hard to debug in test mode (unfortunately) because of some bad business practices

So the 2nd error I am curious about

Here is the 2nd one: req_KwYCKJOL0zvBl0

I am not sure why if providing the same info as is already there it throws an error?

One other note on turning on ACH payments... this will show the ACH option in the UI, right? I am not thinking that we want that. We want to continue to use plaid to just connect the accounts.

We currently just hide the stripe element for ACH payments and then on submit (with all the info in the form we need) we kick off the plaid process. How will this change if we put the ACH option in the stripe element?

[sweet kayak]

Yes turning it on would show ACH in the UI. At this point if you use PaymentElement you really should just use our product fully instead of Plaid

But based on what you described then change your server-side call. Do not pass automatic_payment_methods since you explicitly do not want it to appear. You know it's ACH so force it instead by passing payment_method_types: ['us_bank_account']

[torpid hill]

Gotcha.

[sweet kayak]

Try that, see if it works. Then we can look at the other one (but again this absolutely should not be tested in production 😅 )

[torpid hill]

Does this have the same sort of built in bank account linking as Plaid does?

[sweet kayak]

Yes! We shipped this a couple years ago already: https://docs.stripe.com/financial-connections

we also document it here: https://docs.stripe.com/payments/ach-direct-debit

[torpid hill]

Are there extra costs for using your connections? I'm sure we pay plaid something, but just wondering if someone who is not me made the call on this workflow because of cost or if it's just so old it wasn't an option

Just want to be informed so if I say "let's just use Stripe for it all" someone doesn't call me an idiot because it'll triple our costs or something lol

because... I am guessing that if we do go down this route and use Stripe for this, we won't even have to worry about #2

[sweet kayak]

I'd recommend reading https://stripe.com/pricing to better understand the costs. It'll depend on what else you do on Plaid too like looking at the balance or transactions (which we also support and also has a cost)

But for now let's focus on fixing your issues! I just wanted to mention it so that it might simplify your integration overall

[torpid hill]

I think that should work for our current implementation. I am still not sure on #2 error, though.

We have a somewhat weird implementation now. We have no known/logged in users who donate. So a donor will input their personal info in at the same time they choose a payment method. We do some find or create customer type stuff in the process to see if a use exists in stripe (based on email).

So do I simply need to check to see if they already have a bank account on file and if it is different than the one provided to avoid this issue?

[sweet kayak]

Error #2 is because you are using a really old/legacy integration where you attach the BankAccount to a Customer first using an old API. That API has a limitationw here we do not let you add the same bank account details twice

so yeah you need to handle this in a special way. You can also just catch the error and if code: 'bank_account_exists' then you know it's a duplicate.

[torpid hill]

Cool. That's sort of what I was thinking but want to confirm.

I think that has me squared away for now.

[sweet kayak]

yay!

[torpid hill]

One more piece of clarification

We have sort of a generic endpoint for these one-time payments. It takes credit/debit, apple and google pay and should take ACH too. When I set the payment_method_types I can pass all those in, right? or do I need to add a different conditional to know the payment type before it reaches that code?

We sort of have it dynamic at this point.

[sweet kayak]

You're going to have to special-case ACH and handle it with payment_method_types. Don't try to do both because you could hit errors later you'll regret. So just make surgical changes explicitly for the ACH flow

[sweet kayak]

Anything else I can help with before I close this thread?