#brandonjohnson
quaint sinew
dusty pagoda
Hi there!
Are you saying that when you create a subscription in the Stripe dashboard, you cannot use "manual payment capture"? And can you clarify what you mean by "manual payment capture"?
cold heron
S we have stripe integrated within our app. When we create a new customer and attach a price to it and the customer checks out it creates the customer in stripe but fails to capture the payment automatically - in order to capture the payment I have to manually go into the invoice and click charge card then it works
this only started happening around June time
It seems like there is an issue with the logs as they din't really make sense
dusty pagoda
When we create a new customer and attach a price
I guess you mean "attach a payment method"?
and the customer checks out
How does the customer checkes out? Are you creating a subscription with the subscription endpoint? If so, can you share a subscription ID?
cold heron
yes
"sub_1MEElhLNC4byIUUD2vL1nJWL",
This next screenshot shows how it used to work which was correct
?
dusty pagoda
So looking at sub_1MEElhLNC4byIUUD2vL1nJWL
- You had a customer with a default payment method
- You created the subscription
- The first payment of the invoice failed because it required authentification
Is this correct? What were you expecting to happen instead?
cold heron
it didnt require authentication this is the error
I was expecting the payment to be automatically processed as it used to do. Our customers do not have to authenticate the payment on their side so the error is on our side somewhere
dusty pagoda
Our customers do not have to authenticate the payment on their side so the error is on our side somewhere
Why are you saying this? It's completely up to the bank to require or not require 3DS. In this specific case you shared, the bank required 3DS, so the invoice failed.
Was the customer on_session (meaning on your website/app) when you created the subscription?
cold heron
yes
but not all of our customers banks require 3ds
and on our customer's side they do not have to approve or authenticate anything
I did a test and was not presented anything
dusty pagoda
but not all of our customers banks require 3ds
Correct, 3DS won't be required all the time by all banks. But sometimes it will, and your integration needs to handle this case.
Can you answer this question, so it will help me give you some suggestions:
Was the customer on_session (meaning on your website/app) when you created the subscription?
cold heron
yes
dusty pagoda
Then you should follow this integration: https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements
- create the subscription on the backend with
payment_behavior: 'default_incomplete' - retrieve the
latest_invoice.payment_intent.client_secretand send it to the frontend - collect the payment method with the Payment Element and the
client_secret. This way, if 3DS is required, the 3DS flow will automatically start - and the first invoice will be automatically paid
cold heron
is this something that changed in your side?
because we have made no changes
and this all of a sudden started to happen
cold heron
> but not all of our customers banks require 3ds
Correct, 3DS won't be required ...
In relation to this, this is happening with every single payment not just some. This indicates that there is an issue beyond the 3ds
?
vital mica
do you have any other example that shows the issue you're describing?
vital mica
overall you seem very sure that your customers don't require 3D Secure, which is like, not true and not something you can know
vital mica
what do you want me to send you?
maybe like a subscription ID sub_xxx?
cold heron
Not every single customer requires it
and I made myself a customer to test it and nothing required me to do 3ds but in stripe we still had the same issue
vital mica
I mean, SCA is fully in force since the middle of this year https://support.stripe.com/questions/strong-customer-authentication-(sca)-enforcement-date
so in general every on-session payment(like starting a subscription) is likely to require 3DS, as my colleague explained happened in the example you shared earlier
cold heron
"sub_1MFEj7LNC4byIUUD7ijbTwPT",
ok so this is probably what is happening if this SCA has coem into force since the middle of this year
because this is when the issue started
What is the fix?
vital mica
Then you should follow this integration: https://stripe.com/docs/billing/subscri...
the fix is to use an SCA-compliant integration where you prompt the user for 3D Secure if the first payment of the subscription gets declined with authentication_required
vital mica
yep, it's in the reply I quoted from my colleague earlier
taking a look at sub_1MFEj7LNC4byIUUD7ijbTwPT too...
cold heron
yes
vital mica
so similiar to what my colleauge looked at with the other example. You create the subscription, we try to charge the customer's card. To comply with SCA, we require 3D Secure to be completed so we return an incomplete subscription with the next step being for your integration to handle the PaymentIntent and present 3DS on your payment page with the customer
. In this particular case as far as I can tell it's not explicitly the bank declining the payment, it's that we "step up" to 3D Secure per our own logic. We do that because per SCA that's required and it makes it more likely that future payments will succeed. We've had SCA-compatible integrations as the default for multiple years now so we expect that you'd handle the incomplete subscription.
Instead of presenting 3D Secure you manually hit the 'charge' button in the Stripe dashboard, and that happened to decline with an insufficient funds decline from the bank the first time and succeed on a retry.
cold heron
ok