lafafm

[quick roost]

Hi there. So why can't you pay the invoice generated by the proration by marking it out of band too?

[undone gazelle]

It wouldn't place it as customer don't have a payment method attached

E.g. it would make an immediate charge attempt

And the only option I'm seeing now - to convert subscription to past_due on every update with proration, which is rough

[quick roost]

Ah do you require that prorations be invoiced immediately?

[undone gazelle]

It's not required to place invoice immediately

But I don't want the update to be applied if payment is failed

E.g. pending_updates on paper worked perfectly for me, but they're require payment method to be attached

And if invoice wouldn't be placed immediately - the change can't be easily reverted to the previous stage

[quick roost]

But I don't want the update to be applied if payment is failed
You're saying if the out of band payment fails?
And if invoice wouldn't be placed immediately - the change can't be easily reverted to the previous stage
Why not? You can always make a subscription update again and set prorations to none

[undone gazelle]

Roughly, the idea in code (php pseudo)

Subscription->update();

try {
  if (!$canBePaidOutOfBand) {
    throw new \Exception('fail');
  }
  
  $outstandingInvoice->pay(out_of_band);
  // Subscription update proceeded
} catch (\Exception) {
  $outstandingInvoice->void();
  // Subscription update hasn't happened
}

So, in case of pending_updates - that logic is applicable

As I can make a pending update which comes into force just when it's invoice is paid

[quick roost]

I see what you mean. Yeah unfortunately pending updates just don't work with this flow. I think best bet is to not invoice immediately for the proration. Then if the out of band payment fails, you can revert by updating the subscription again to the previous price and set prorations to none. Reverting state isn't exactly the easiest in this case, but it's still doable

[undone gazelle]

Another option that I see - is to create one-off invoice for the proration

E.g. calculate proration with invoice->upcoming() by passing future attributes

Then charge one-off inovice
And update subscription without proration

Do you see any problems with such flow?

In theory it will allow such flow that I want with pending_updates with a price of manually doing proration

[unreal urchin]

Hi 👋

The problem there would be it would decouple the charges from the one-off invoice and the billing history of the subscription.