#morunas

1 messages · Page 1 of 1 (latest)

misty violetBOT
haughty lantern
#

👋 happy to help

#

if the latest_invoice.payment_intent.status is requires_action then yes

primal reef
#

Hi Tarzan 🙂 ok. I was just unsure if that was the correct way to "reuse" the payment method already stored

haughty lantern
#

I'm unsure though with it's past_due and not directly paid

#

since there is a default pm

primal reef
#

well I'm running the subscription update with the following parameters

'items' => [
[
'id' => $currentSubscription->items->first()->id,
'price' => $choicePrice->id
]
],
'billing_cycle_anchor' => $choicePrice->recurring->interval == $currentPrice->recurring->interval
? 'unchanged'
: 'now',
'payment_behavior' => 'allow_incomplete',
'payment_settings' => [
'save_default_payment_method' => 'on_subscription'
],
'proration_date' => time(),
'proration_behavior' => 'always_invoice',
'cancel_at_period_end' => false,
'expand' => [
'latest_invoice.payment_intent'
]
]

#

Are these correct, considering that this is an ongoing subscription with a payment method? or is some of it redundant? like payment.settings.save_default_payment_method

haughty lantern
#

@primal reef this really needs time to investigate and with how busy discord is nowadays it's pretty much impossible to do so

primal reef
#

oh ok sorry I did not mean at all to steal your time 🙂 it was only if there was something obvious

haughty lantern
#

no that's not it on the opposite, I want to help you but I need you to send all of the info code etc. through that link I gave you and mention that you were speaking to tarzan on discord, so someone from my team/myself could pick this up dig through and take the time needed to help you with this tricky Q

#

does that sound good to you?

primal reef
#

Sounds fine 🙂 but you did answer "if the latest_invoice.payment_intent.status is requires_action then yes" which does answer my question. What I did not really get was when you said "I'm unsure though with it's past_due and not directly paid", but it is stated here https://stripe.com/docs/billing/migration/strong-customer-authentication that "If the charge requires SCA, the subscription status changes to past_due". So I guess that is correct :- )

haughty lantern
#

hmmmm, that I didn't know. It's really interesting how much we still need to learn at Stripe and how we can learn from each other (staff and community). The amount of knowledge is infinite. thanks for that @primal reef

primal reef
#

indeed the amount of knowledge is insane xD and the documentation is pretty good... but there is just so much (and sometimes multiple ways of achieving the same(ish)) that I find myself often doubting my steps :/ and then come and nag you guys here xD

haughty lantern
#

as long as we can help you achieve this then we're happy to

#

now I get the confusion 🤦

#

sorry about that

primal reef
#

hehehe 😄 happens!

#

I do have one more question though, but should I create a separate thread on dev-help? or can I ask it here?

haughty lantern
#

no you can ask here

#

go ahead

primal reef
#

Alright so when a customer on-session choses to upgrade their subscription (with proration), I want to show them the changes for confirmation and in case there is need for SCA, they can authenticate, as we just previously talked.

Can you confirm the correct flow than is:

  1. Use upcoming invoice to show proration amount
  2. when the client hits confirm I then call the server to execute the subscription update
  3. if the latest_invoice.payment_intent is require_action, then I return to client side and run confirmCardPayment with the existing payment_method

So the key differences are:
-> for first subscription payment, I need to create a subscription with default_incomplete to get a payment intent so the user can provide a payment method (since there is none) and pay, and if applicable do the SCA in one go
-> for subsequent subscription changes that required payment (protating on upgrade), I can use the UpcomingInvoice feature first (and not immediately change the subscription before showing the proration preview), because there is already a payment method, so when the customer clicks confirm then I try to execute the update, which tries to charge, and may end up requiring the extra SCA step

Does this make sense? Do I have it clear?

nimble crown
#

Hey! Taking over for my colleague. Let me catch up.

primal reef
#

Oki 🙂 I think you only need to read my last comment (I just need to know that I understood things correctly)

nimble crown
primal reef
#

And I had to adapt our flow because what we did before was:

  1. use setup intent to collect card info together with billing info (including info relevant for tax rates)
  2. then use upcomming invoice to preview charges for either a new subscription or a change to a subscription
  3. then the user would confirm and we'd execute the changes

3DS worked fine with setup intent, but now - as I understand - with 3DS2 and SCA, certain payments may require (re)auth regardless, so I had to change our flow to:

  1. start by creating first chosen subscription with default_incomplete and use the payment intent client secret to collect card info and pay the first invoice in one go
  2. then for subscription changes use (as before) the upcoming invoice to preview charges
  3. and now when the user confirms the changes, I must attempt to effect the changes but if SCA is needed I need to return to client side to call confirmCardPayment with the existing payment_method
nimble crown
#

Ok I see,

#

That make sense

nimble crown
#

I don't see any particular issue with this if you want to remain with the old integration. I invite you to test it and come back if you have any follow up questions.