arggh-billing-flow

[white imp]

Hey there! To be clear, were you expecting step 3 in your flow to happen? As that is expected with that specific flow (regardless of whether the card had been setup)

[proven glacier]

Yes, I was expecting that.

(though the wording could be better in the test card's description)

I'm specifically trying to resolve the flows where the offline payment fails and I need to get the user to take action.

[white imp]

requires_confirmation is a state in which the payment requires completion via Stripe.js. Specifically this step in relation to subscriptions: https://stripe.com/docs/billing/subscriptions/build-subscription?ui=elements#complete-payment

What is the correct way to handle this scenario so that the invoice gets paid after the new payment method is added by the user?
How are you adding the card to the user? Is it set as the default payment method (invoice_settings.default_payment_method)?

What are your retry settings for subscriptions?

[proven glacier]

I'm adding it to the Customer as the new default payment method, and the subscription doesn't have a payment method set, so it should (as per my understanding) use the default payment method.

[white imp]

That's right, yep

But whether a payment retry will occur will depend on the behaviour on the subscription

Can you share the Payment Intent, Invoice or Subscription ID?

[proven glacier]

I believe these are our retry settings?

[proven glacier]

My latest test case with the described flow completed is with subscription ID sub_1K5xbBGh3krmwCRAIqWSm6jP

[white imp]

This invoice, right? https://dashboard.stripe.com/test/invoices/in_1K5xmjGh3krmwCRA4pBbEuKR

[proven glacier]

I belive so. I have about 10 test cases active so I might confuse things but should be.

Yes that's the one, the invoice number matches in our app ui: C228FCDC-0002

[white imp]

Got it. Seems like a payment will be re-attempted on the 18th (as per the retry schedule) using the default payment method

[proven glacier]

I don't understand what causes the state to transition into requires_payment_method when the user adds a new payment method? To me it seems like it's a sign of a failed payment attempt.

(it also causes our app ui to display a flow to add a new payment method instead of just confirming the charge with the current default payment method)

1. pi state: requires_action
2. user adds new payment method
3. pi state → requires_payment_method 🤷‍♂️

[white imp]

That is expected: https://stripe.com/docs/billing/subscriptions/overview#payment-status

[white imp]

Because it was a failed payment

[proven glacier]

Ok, thanks for your help. I shall return to study the docs, since I still find it confusing to have that state transition happen in the PaymentIntent when user adds a new PaymentMethod. What I would expect to happen for the PaymentIntent is either

a) nothing until retry
b) automatic retry with the new payment method (which should complete succesfully in our test case)

Instead, the state changes to requires_payment_method, which indicates that a new payment method is needed, which causes our app to display a call-to-action for user to add a new payment method.

I guess the solution to overcome my confusion is that we try to confirm the payment manually when the new payment method is added?

To add to the confusion, if I navigate (as the user) to the hosted invoice page attached to the invoice object, the default payment method is not available and I'm being asked to provide payment information (with card 42424242... prefilled for some reason?). The default payment method card on this user ends in 3155. I would expect the newly added payment method to be available here?

(Sidenote: why is the title "Contact information" when you're essentially filling in payment information?)

Here's a screenshot of the same customer in dashboard, displaying the payment method.

[white imp]

since I still find it confusing to have that state transition happen in the PaymentIntent when user adds a new PaymentMethod
To be clear the status didn't transition to requires_payment_method because they added a new card – it transitioned because the initial payment failed (as auth was required by that test card but it was an off-session payment)

In those cases, you would need to reattach a payment method. But the automatic retry system would handle that in the subscription flow

I guess the solution to overcome my confusion is that we try to confirm the payment manually when the new payment method is added?
That is likely a good solution as the customer would be on-session meaning any requested auth by the bank could be completed and increasing likelihood of a successful payment

[proven glacier]

I thought the state requires_action or requires_confirmation were due to the card requiring auth? I need to re-run my test flow. Sorry if I'm wasting your time due to my own clumsiness.

Now I think I see where my confusion originates from. I now have re-run the test flow and the invoice was just finalized and the state of the payment intent is requires_confirmation. Stripe dashboard however says "Payment will be retried in 1 hour", indicating that there already was a (failed) payment attempt.

Apparently it's a somewhat "soft" payment attempts that basically just acknowledges that the 3D secure confirmation will be required, and the actual "fail" comes later (in 1 hour), changing the state into requires_payment_method?

I now understand the flow of things and that the old payment method is still attached to the old (and open) invoice, and that the subscription flow retries should take care of attaching the new default payment method to the invoice when time comes.

I do still think that the dashboard UI is confusing (..."retried" when there has been no "failed" attempt) and the events regarding the first payment are confusing as well: status is requires_confirmation, but an actual attempt to charge the card has not yet happened.

[white imp]

requires_confirmation denotes that the Payment Intent needs confirmation (i.e. process the payment).
requires_action denotes that the Payment Intent likely needs some kind of 3DS/auth approval.

You can have requires_action after confirmation, but it's likely that you'll ever see that state if you're using our recommended integration paths

I do still think that the dashboard UI is confusing (..."retried" when there has been no "failed" attempt)
There was a failed attempt though: https://dashboard.stripe.com/test/events/evt_1K5yX6Gh3krmwCRAAiQLy2N7

[proven glacier]

I was in the context of my new test case already here: https://dashboard.stripe.com/test/invoices/in_1K6Bc8Gh3krmwCRAx3BbaTfr

With that customer & subscription, there is no "failed attempt" event, but the dashboard says "Payment will be retried in 33 minutes"

The previous test case did have the failed attempt (and the payment intent had status of requires_payment_method)

[white imp]

Hmm, not sure why there's the use of that term

[proven glacier]

That's what confused me in the first place.

To me it seems like a bug / wrong translation being used.

Proper would be "Payment will be attempted in 31 minutes"

(or tried)

[white imp]

In most cases there is

Trying to figure out why it isn't with this sub

[proven glacier]

ok

Let me know if you need another customer created, this one has the payment attempt happening in 31 minutes. I can easily replicate the problem.

[white imp]

Wondering why there's 2 invoices on the subscription

[proven glacier]

You mean the one with 0 amount? I think that's for the trial period?

[white imp]

Ah, set a short trial period on creation

[proven glacier]

Yes, few minutes. In production it's longer, but I don't have 30 days to wait while developing..

[white imp]

Yep, got it