#originalowl_error

1 messages · Page 1 of 1 (latest)

frozen pagodaBOT
#

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

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

pastel quiver
#

We've tried v3, basil, & canopy for js version. Our API is using 2024-04-10.
This only happens with subscriptions. If we create the PI directly for a one-time donation, then Stripe confirms the PI fine with the payment the customer has entered and ignores their default PM.

gusty tartan
#

hi! looking at this now

#

any chance you can share a request ID that resulted in this error?

pastel quiver
#

Here's one req_LCsvGqpUKy8kHp

orchid vine
#

👀 Here watching this thread (we're on the same team)

gusty tartan
#

do you have a test mode integration where you can try something for me real quick? i'm not recommending this as a solution but can you first

  1. reproduce the error you're currently getting in test mode and then
  2. add this parameter to your "create subscription" call with the value ["card", "us_bank_account"]
pastel quiver
#

Yes declaring payment_method_types was our only lead as well.
Can you tell me the difference between ach_debit and us_bank_account?
Why would elements/js choose the customer's default PM over the one declared?

gusty tartan
#

ach_debit is the legacy version of ACH and us_bank_account is the current one

pastel quiver
#

I've not attempted to reproduce in a test/sandbox env. I would need to find a customer with this setup.

pastel quiver
#

So presumably this is only a problem with customers whose default PM is an ach_debit

#

or really default source

gusty tartan
#

yeah, that would make sense

#

is this something that just started happening suddenly? do you know if there are any examples of it working in the past?

pastel quiver
#

@orchid vine ideas?

#

We migrated to PM/confirmation tokens about 15 months ago (July 24). We haven't heard any complaints until recently. But it would be user dependent so it's hard to say

orchid vine
#

Yea. This is the first time I have seen thing happen, but also who knows if it has happened and just wasn't reported.

And @pastel quiver - we migrated to the new Stripe flow (from charges to payment intents) then, but I think we added on using Stripe's ACH instead of plaids either earlier this year or late last year.

#

Just searched and it looks like we removed plaid in October last year

gusty tartan
#

hmmm ok.

#

i'm not super familiar with ach_debit since it's a legacy payment method but let me do some additional digging here, i'm sure this is something other users have run into.

pastel quiver
#

@orchid vine I wonder how many live customers we have with an active subscription using ach_debit

orchid vine
#

^ this was what we were trying to pull at one point but since we didn't store the token from when we set them up, we can't query them now to see.

pastel quiver
#

Maybe we can filter by ID's with ba_ instead of pm_?
@gusty tartan that corresponds to ach_debit source vs new PM right?

frozen pagodaBOT
tranquil tusk
#

Hello
Taking over here 👋
Can you give me a quick summary of the question while I catch up on the context?

pastel quiver
#

PM fails to confirm with customer's whose default PM/source is ach_debit

tranquil tusk
#

Gotcha. Let me take a quick look

#

Yeah It's odd that ach_debit is being added as a supported payment method on the invoice's PaymentIntent

Taking a step back, is the goal here to keep the customer's saved sources and use that for subscriptions? OR you don't mind deleting the sources as you're already having them add a new payment method?

pastel quiver
#

I don't mind deleting them if they don't have any other active subscriptions. If they do then that would be some work for our business.
We are not trying to use their saved source for this new subscription though. And further more at this point they've already given us their payment method they want to use.

tranquil tusk
#

Gotcha. If you already have a pm_xxx object, one option here would be to pass that as default_payment_method on the Subscription creation

pastel quiver
#

We don't have a pm_. We have a ba_ and they are trying to create the subscription with a new card.

tranquil tusk
#

I believe you can pass card_xxx IDs to default_payment_method parameter as well

pastel quiver
#

Also we can't really re-use an existing pm, because this is an anonymous form where they are identified by their email address. So we can't really use a saved PM since we cannot confirm their identity.

tranquil tusk
#

I see. So in that case, can you try unset default_source on the customer and see if that helps?

pastel quiver
#

can a default be unset without deleting the source overall?

tranquil tusk
#

You mean deleting the source?

#

I think so.

#

I'd say give it a try as this API predates my time @ Stripe 😅

pastel quiver
#

Yeah you guys move quick, it's hard to keep up lol

#

Would that affect existing subscriptions? This code was created ~5 years ago where a source could not be declared on the subscription. So any new subscriptions would set & use the customer's default source. I know that now subs can have their own dedicated PMs, but any active subs will not have this set I don't think. And I worry that unsetting the default will cause the sub to not charge.

tranquil tusk
#

Do you use Stripe subscriptions or your own system to make recurring PaymentIntents requests?
If I can recall correctly, Subscriptions API requires a mandate which ach_debit did not support

pastel quiver
#

I guess overall though the idea is to avoid this path. so specify payment_method_types, or don't have a default source of ach_debit somehow.

We can do some digging to see how wide spread this is for us, now that we have more clarity.

tranquil tusk
#

Do you have an example Subscription I can take a peek at?

pastel quiver
#

We do use stripe subscriptions

tranquil tusk
#

The issue is that you can't control payment_method_types of an Invoice's PaymentIntent as it's pulled from your billing settings

#

you can't pass that as a parameter

pastel quiver
#

And perhaps that missing mandate is why the PM is failing to confirm

tranquil tusk
#

Can you share the client-side code you're using to create a Confirmation Token?

pastel quiver
pastel quiver
tranquil tusk
tranquil tusk
#

sorry about that

tranquil tusk
pastel quiver
pastel quiver
tranquil tusk
#

Thanks, yeah your code looks fine

#

If you don't want to deal with unsetting or detaching existing sources, I believe explicitly specifying payment_method_types would be the only workaround

orchid vine
#

testing that now

pastel quiver
#

Ok cool sounds we have a couple options then.

#

Thanks @tranquil tusk. rip overwatch

tranquil tusk
#

Happy to help!

pastel quiver
#

Oh while I have you. unrelated. can you help illuminate how/when a setupintent would be used for a subscription instead of a payment?
Is that based on payment_behavior/collection_method?

tranquil tusk
#

It's based on the initial Invoice amount. If you have a trial period for example, the first invoice is generated for $0

#

In that case, we automatically generate a SetupIntent for the Subscription

#

so you can use that to collect a PaymentMethod

pastel quiver
#

So essentially there wouldn't be an invoice when the sub is created if it's $0, or at least not one requiring payment. So because of that, if we wanted to collect a PM it would have to be for future use, hence the setup intent.

tranquil tusk
#

Correct

pastel quiver
#

The browser workflow is the same though right? at least code wise. other than switching confirmPayment/confirmSetup method.

tranquil tusk
#

Yup

pastel quiver
#

And if we wanted to provide an API to allow users to manage their saved PMs those would need to be established with setupintents, right?

orchid vine
#

Hey @tranquil tusk - Trying to find a list of the valid types for payment_method_types. I got an auto-fill on the IDE for this payment_method_types: ["card", "us_bank_account", "apple_pay", "google_pay"], but trying to initialize it says invalid, but I can't find a list. Is apple_pay and google_pay just "wallet" or something?

tranquil tusk
tranquil tusk
pastel quiver
tranquil tusk
pastel quiver
#

@tranquil tusk Does that payment_method_types have to be on the subscription creation call? Or can it be in the elements code?

tranquil tusk
#

Good question 🤔
Since you're using defer intent flow, I'm not exactly sure as in some cases, we do require matching payment method types on both.

Try just setting it on the Subscription first and if you get an API error upon confirmation then you'd need to set it on the Elements as well

pastel quiver
#

kk we just tried the opposite lol