DavidPr

[coral halo]

Seems expected given that this is flagged as off_session: true. Are you users offline at this point?

Can you share a cus_xxx ID where this is happening?

[covert bobcat]

I have tried it with off_session: false and it does not work, however answering your question, yes users are offline when subscription payments are made.

Well the first one is on_sesssion and the recurring ones are off_session

[coral halo]

First one of what?

[covert bobcat]

For the overages subscription they are all off_session

When the user first clicks on subscribe, it's on session

Because the user is present on site when he makes the payment for the subscription

[coral halo]

But those are 2 separate Subscriptions are you noted, there's always a chance the bank may request 3DS/auth for any/all payments

[coral halo]

Do you have this available?

[covert bobcat]

It is happening for all the customers

[coral halo]

Ok, but I can't really investigate the reason why that may be happening without a specific example

I need to see how you're saving and using the payment methods, basically

[covert bobcat]

However I tried a thing. I created a Stripe checkout session with mode: subscription and redirected the user to that page. If a payment is made via that then it works. Changing subscription products applies prorations and charges correctly.

[coral halo]

Yes, because the user would be on-session at that point to complete any 3DS/auth requests

If you flag as off-session, then any 3DS/auth requests by the bank will automatically decline as the user is not online to authenticate

I need to see a specific example to understand why that may be happening

[covert bobcat]

Okay, let me create a user from the beginning and retry this. Just a moment please

Okay so this customer: cus_NznWjMu2YJz7dQ

It has this subscription with standard plan pricing: sub_1NDnvTIPhaVZ79J6GjJ9QMwc

The usage based subscription is: sub_1NDnvUIPhaVZ79J6HyIbfLmw

[coral halo]

Ok, and which subscription failed due to 3DS?

[covert bobcat]

This one sub_1NDnvTIPhaVZ79J6GjJ9QMwc

For now what we are doing is basically:

1. Trigger subscription creating
2. Let stripe handle the payment in background

Do we need to use stripe.confirmCardPayment using the secret of the last payment intent that failed for this subscription?

Also we noticed that when going through stripe checkout, it did not even trigger a 3DS flow and the payment was successful

[coral halo]

Well the outcome would depend on which test cards you're using

[covert bobcat]

I am using this 4000002500003155, however I tried it with real cards as well

The real cards had three_d_secure: 'optional'

[coral halo]

You shouldn't be testing in live mode, FWIW

[covert bobcat]

We just wanted to test the integration with real cards as well

So it made sense to see how it would behave

[coral halo]

Yeah, but it's against Stripe ToS

[covert bobcat]

Okay we will continue with test cards only

Thank you for mentioning it

[coral halo]

Taking a look at the examples you shared

[coral halo]

So you made an update here: https://dashboard.stripe.com/logs/req_vjA5fggKx1rpa8

That required an immediate payment, so a new Invoice was generated to handle the payment: https://dashboard.stripe.com/invoices/in_1NE77wIPhaVZ79J6J5Ust4eU

But you didn't pass off_session: true on the update: https://stripe.com/docs/api/subscriptions/update#update_subscription-off_session

Therefore we can't request off-session exemptions for the bank and, as noted before, SCA regulations deetermine that banks may requests 3DS/auth on any/all payments even if previoulsly saved

[covert bobcat]

Can you elaborate what this means?

[coral halo]

Which part specifically?

You made an update to sub_1NDnvTIPhaVZ79J6GjJ9QMwc, here: https://dashboard.stripe.com/logs/req_vjA5fggKx1rpa8

Part of that update warranted an immediate payment (seems like you switched plans). So we generated a new invoice to handle payment for that upgrade/downgrade: https://stripe.com/docs/billing/subscriptions/upgrade-downgrade#immediate-payment

As that change requirement a payment we automatically attempted that payment for the invoice, but it was seemingly declined by thye bank: https://dashboard.stripe.com/events/evt_3NE77wIPhaVZ79J60kyOPers

[covert bobcat]

Ah I see. Yes it's a plan switch from one that has a price of $0 to one that has another price. That part is true, however what is the recommended way of handling it?

Since it is an immediate payment do we need to use stripe.confirmCardPayment

[coral halo]

Is this a user initiated upgrade (like are they clicking a button?) or something you're automating? You shouldn't need to manually confirm the payment in this scenario no, as you've a saved payment method on file so we will automatically attempt to charge that as we did in this example

Just for whatever reason the bank declined it (non-3DS related)

[covert bobcat]

This is a user initiated upgrade. They are clicking on a button. The customer/user has a payment method already attached to him that is saved via the Stripe checkout with mode: setup.

But I am wondering what is the difference between what we are currently doing vs. Stripe checkout?

[coral halo]

Have you tried this flow in ttest mode with test cards? WHat was the outcome? The example you've shared are livemode examples of I assume you testing (which I've advised against)

[covert bobcat]

Yes the example I shared is in live mode. In test mode it was the same outcome. I can share some examples for that as well

[real arrow]

no need. What is the outstanding question/confusion we can help with?

[covert bobcat]

Okay so in test mode you can check this customer cus_O084w6S2rB9V6s

[real arrow]

what specifically am I checking for? what would you like to know or what is the question?

[covert bobcat]

Why do payments fail and subscription is moved to past_due?

And why does this not happen via Stripe checkout with mode: subscription?

@coral halo mentioned that the upgrade required an immediate payment. How can that be handled?

[real arrow]

one question at at time

[covert bobcat]

Okay

[real arrow]

because you updated with proration_behavior:always_invoice, which forces an immediate payment for the proration calculated. So when processing the Update Subscription API call, we generate an Invoice and try to charge it to the customer's saved payment method. https://dashboard.stripe.com/test/logs/req_7mbyxOW7c09Dgz

[real arrow]

that's an entirely different concept though? Using Checkout would be creating a Subscription, not updating one.

[real arrow]

well in this case ,it was done, and it failed due to 3DS being needed. So you would detect that via webhooks and contact the customer and can send them a link to the hosted_invoice_url for example to pay there, or to a custom payment page on your site where you confirm the PaymentIntent from the Invoice, there's a few options.

[covert bobcat]

Yes, It creates the subscription but when we try the same flow upgrading/downgrading with that subscription_id (changing prices), then payments do not fail.

Will recurring payments also fail for this reason? Or once the payment is made via the hosted_invoice_url it won't require 3DS for recurring payments as often?

[real arrow]

the flow doesn't really matter? like, in the flow, a payment is required. That payment might fail or it might not. That depends on the customer's bank really like if their card still exists/has funds/bank decides if 3DS is needed. I don't understand the point you're making.

in test mode there are different test cards you can use to test different scenarios.

[real arrow]

any payment can fail for any reason. In general recurring payments don't require 3D Secure no, since banks grant exemptions if the card was authenticated with 3D Secure when first used. In test mode if you use the 3155 test card it simulates getting that exemption.
https://stripe.com/docs/testing#authentication-and-setup

[covert bobcat]

I am using 4000002500003155

[real arrow]

note that in your case updating the subscription is not a recurring payment, we treat that as an "on-session" payment and in test mode that always requires 3D Secure on 3155.

[real arrow]

yep, see above

if you want you can use https://stripe.com/docs/api/subscriptions/update#update_subscription-off_session set to true on the update call you're making

if the update you are doing is with the customer not present(like a backend action), and in test mode with 3155 that will trigger the exemption from 3DS.

[covert bobcat]

I see. Do recurring payments with 3155 require authentication?

[real arrow]

no because they're recurring and off-session

hence why it says "After you set it up, off-session payments no longer require authentication." in the description of the card.

[covert bobcat]

Okay thanks for this information

I am wondering about real cards and recurring payments. Suppose this flow happens:

1. First invoice fails and we send the customer an email with hosted_invoice_url
2. User pays that invoice and passes 3DS

What will happen with recurring payments for that customer. Whill he always be asked for 3DS if three_d_Secure on the card is 'optional'?

[real arrow]

it's up to the bank

as mentioned, recurring payments should always be exempt(see https://stripe.com/guides/strong-customer-authentication#exemptions-to-strong-customer-authentication). It's up to the bank to grant that. The payment could fail for any other reason of course too like insufficient funds or expired card or so on