#[LBG] India-subscription-sfu

1 messages · Page 1 of 1 (latest)

silk sorrel
#

You don't need to pass that parameter. The Checkout Session will setup the card regardless of that parameter in mode: 'subscription'

spice pier
#

Ok so the card will be set to accept off_session payments ?

silk sorrel
#

Yep it should

spice pier
#

It should or it will ? 😅

#

I need to be sure we went from 17% to 40% of churn in 1 weekend due to a bad SCA implementation from our end

silk sorrel
#

What do you mean by 'accept'?

#

The API won't fail, but the bank could still request 3DS for an off-session payment

#

There's no guarantee that setting up/saving a card for off-session payments will result in an SCA exemption

spice pier
#

Yes of course. I am currently trying to understand why we have this SCA trend :

unknown.png
#

What we do today is we create a Customer Session in setup mode to save the customer's card. Then on our frontend, the user chooses a subscription. We then create a subscription for this customer

silk sorrel
#

Can you share the ID of a failed Payment Intent?

spice pier
#

pi_3KljzjLJLkeHRLt10LggsxGv

#

Please don't tell me it has insufficient funds, I already know. I bet it is a default error code for SCA non authentication error

#

Most of our subscriptions are in insufficient funds error, and the SCA exemptions went down to almost None

silk sorrel
#

I bet it is a default error code for SCA non authentication error
That's not how it works

spice pier
#

So, I know we can't guarantee that saving a card for off-session payments will result in an SCA exemption, but I wonder if saving the customer's card during a Session in "subscription" mode, where the SCA really authenticates the future payment for subscription, and not the "setup", would help prevent this

silk sorrel
spice pier
#

How can you explain the drop of SCA exemption and the raise of churn then ?

silk sorrel
#

pi_3KljzjLJLkeHRLt10LggsxGv failure of this payment isn't related to SCA/3DS

silk sorrel
spice pier
#

How can I find one ?

silk sorrel
#

Hmm, are you using createPaymentMethod from Stripe.js?

spice pier
#

How can we have so much "insufficient_funds" but only 3 payments exempted ?

#

How the "authorized" payments not tagged as "exempted" as well ?

silk sorrel
#

Yet that Setup Intent is never confirmed via Stripe.js confirmSetup

spice pier
#

Let me check

silk sorrel
#

I suspect that's related here. Although you are setting up the PM via Checkout, so I'm not sure

#

Why do you setup the card separately?

spice pier
#

Because customers can also use the card to create direct charges to Connect Standard Accounts

#

That's a more recent one, a subscription pending setup intent

#

I did not know we were generating pending setup intents when creating a subscription on the customer

#

Could that be related to our issues ? The payment method is never confirmed to off_session for the subscription ?

#

From what I see all "pending_setup_intent" from our subscription creations are incomplete

#

I can confirme that our workflow does not go further than subscription creation, we do not Stripe.js confirmSetup

#

From my POV, in our current workflow, we authenticate the card setup, but not the subscription creation (setup intents in incomplete state). If we go through a Session en subscription mode to create the Subscription AND the card, will all setupIntents be completed ?

#

You there ?

torpid kestrel
#

HI 👋 jumping in as my teammate needed to step away, bear with me a moment while I get caught up.

spice pier
#

Sure

#

Hi @torpid kestrel 🙂

torpid kestrel
#

Would you mind helping me understand the core concern here? Is it the insufficient_funds errors?

spice pier
#

We have abnormal churn raise since 2 weeks (from 16% to 40%, this is not normal behavior), and SCA exemption drops to 0%. Our workflow : we create a customer, the customer navigates on our frontend. When he wants to subscribe to our services, we force him to setup a card through a Stripe checkout en "setup" mode, and we set it as default payment_method. The user goes back to front and chooses the subscription he wants, when he chooses, we create a subscription from API calls. This subscription is set to the current customer with no payment method so Stripe uses the default one saved earlier

#

Since 2 weeks, a majority of our payments are going "insufficient_funds". I maintain the fact that those are "generic" error code for SCA problems. There is just no way ALL our clients have no funds at the same time

#

Knowing that :

#

@silk sorrel found that when we create a subscription, we do not confirm it with Stripe JS. Leading to SetupIntents incompleted

#

I check, and it is the case for all of them, our workflow stops at "create sub"

spice pier
torpid kestrel
spice pier
#

This is the JSON response for a LIVE creation subscription currently setup :

#

And this is a JSON response for a subscription with a Session on mode "subcription" from test env :

#

There is no pending_setup_intent on the subscription created with a Session, and other fields are missing in our live example

#

Globally, creating a subscription through a Checkout Session seems cleaner

#

We are going to make it live asap. I can bet that it will reduce failed payments

#

What do you think ?

torpid kestrel
#

I'm not really following. You seem to be pivoting away from investigating the insufficient funds errors, so I'm not sure what you're trying to accomplish.

spice pier
#

How can I investigate insufficient funds errors ?

torpid kestrel
#

Look at them to see if there is a trend of a particular brand/etc that is throwing the errors. It's very possible that previously these errors were masked by SCA issues, and now that you've addressed those the insufficient funds errors are coming to the surface.

spice pier
#

We've been having issues with insufficient funds for 3 months now. When our integration did not handle even a little SCA, we were having NO ISSUE with SCA but only insufficient funds

#

I managed to work along with my team and examined the failed payments on your account. Indeed, we found a high number of declines due to “insufficient_funds”. This kind of error is specific to cards not having enough funding and that we don't receive very detailed information on declines from the cardholder's bank, so we don't have any additional insight other than what we are able to provide you via the Dashboard and API.

#

That's the reply from Stripe support

#

3 weeks ago

#

The truth is that I am convinced that insufficient funds is a default message hiding other issues

torpid kestrel
#

I can assure you that on our end it is not used in that fashion.

spice pier
#

I am not saying it is Stripe's fault, I am blaming issuers

#

Anyway, we'll go live on a subscription creation with a Session workflow, if in two weeks our churn goes back to 15-20% and failed payments drop, there is a good chance that insufficient funds are default messages

#

I have other questions

torpid kestrel
#

Ask away

spice pier
#

I have activated this :

unknown.png
#

If I understand, an email is sent only if a 3DS is required for a subscription payment ?

spice pier
#

?

torpid kestrel
#

Yes

spice pier
#

But no email would be sent if this setting is not enabled :

unknown.png
#

Right ?

lunar pumice
#

That setting control the application of Radar rules for Setup Intents, which is separet from the 3DS emails

spice pier
#

Ok

#

Last question

#

How come from this direct charge (pi_3KltdcPugnuXY9nV12TA4Gs7), that had to be completed by a 3DS, there is no "3DS requested" on Radar for the acc_ ?

spice pier
#

Is it possible to create a Session in mode "subscription" with the customer not having the country set when using Stripe tax ?

#

Can Stripe Tax define the customer's country with the card's country only ?

lunar pumice
#

Hey there, sorry for the delay here

#

No it cannot depend on the card country only