Catalog price changes causes retroactive charges

[Felipe Riso Bezerra Leite]

Hi Team,

We realized that when plan price increase changes happen, killbill is attempting to retroactively charge the account for the amount of periods that the subscription was active but with the lower price for example.

Subscription start feb-1 price 100

Price changed to 110

Subscription billing march-1  for 110 RECURRING - 100 REPAIR_ADJ + 110 RECURRING

However we'd like that the price of the plan only get reflected in the future bills and old bill should remain as is. Not retroactive charges should be made.

What we do today in the catalog plugin:
Whenever getVersionedPluginCatalog is called, we:

• construct a VersionedPluginCatalog with exactly one StandaloneAlone catalog
• This StandaloneCatalog’s effective_date is always today’s date.
• This StandaloneCatalog always represents the current snapshot in our system

Thanks,

Felipe

[stephane brossier]

The default strategy for the catalog versions is to grandfather, i.e keep the original price, unless:

• You set an effectiveDateForExistingSubscriptions in your new catalog#Plan version
• You explicitly trigger a change of Plan 

In both of these situations you control the date when the change is effective.

--
You received this message because you are subscribed to the Google Groups "Kill Bill users mailing-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to killbilling-us...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/killbilling-users/2e6bfac8-9d9a-418d-bad3-301647d7e382n%40googlegroups.com.

[Chris Zhang]

Hi Stephane, thanks for the response.  Confused here because we're doing neither.

We *are* still using DefaultPlan as our plan implementation, does that have something to do with it?

Like Felipe said above, our catalog plugin implementation always returns only the current catalog snapshot with effectiveDate set to the current date.  Does that have something to do with it?

Thanks!

[stephane brossier]

Ah, ah, I forgot you were using a catalog plugin. If you make price changes but don't want such changes to be reflected on existing subscriptions, you need to return a multi-version catalog so that the original Plan (with current price) associated with existing subscriptions is still there. Otherwise you will get the behavior you are seeing.

To view this discussion on the web visit https://groups.google.com/d/msgid/killbilling-users/38f8ccee-c051-4610-9c2e-1efad2b3b4d6n%40googlegroups.com.

[Chris Zhang]

That's what I feared, this would be a very costly change for us either way:

* disabling price changes is a costly change because our API is already public

* our internal APIs are not versioned in a way to support what you describe

Is there any way we can apply some temporary hack?   This represents an ongoing incident -- the scope is small for now but the impact is really bad.

[stephane brossier]

If the scope is small, i.e only affects a few Accounts, one thing you could look at is leveraging the fact that catalog plugin is called on behalf of a given Account (typically catalog is global to a Tenant), but the code allows  per-account catalog: you could then serve a catalog without price change for the affected Account -- obviously if you already have an Account that has multiple subscriptions, one with old price and one with new price, this will not work.

Back to real fix, is it really difficult to return multiple versions instead of one ? I suppose the tricky part is to make sure you return the correct effective date for each catalog version, but other than that it should not be a big code change.

To view this discussion on the web visit https://groups.google.com/d/msgid/killbilling-users/ec52a500-4b0b-4fab-a9b7-098e5fdb2b8cn%40googlegroups.com.