You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently overage billing happens in charge_for_api_call_count_overages, and uses OrganisationSubscriptionInformationCache to push overage charges to Chargebee as 100K addons (set up in Chargebee). The goal of this issue is to integrate with Chargebee's proper tool for this: Metered Billing, and have Chargebee handle the overage billing logic natively.
The scope is limited to adding an integration that co-exists with the current overage logic, while we transition to Metered Billing using a FoF feature flag chargebee_metered_billing. Responsibility is further cleaned up after GA (see #7971).
Note
It seems that Chargebee is moving towards Usage-Based Billing and may sunset Metered Billing in the future. Regardless, we decided to move forward with Metered Billing because:
As of today, UBB is not yet generally available in Chargebee production.
We encountered issues while experimenting with UBB, and had our account set to Metered Billing automatically.
Integration footprint is lightweight.
Acceptance criteria
Live site in Chargebee has Metered Billing enabled and a single metered add-on with a per-unit price. See Chargebee setup below.
Usage data is pushed to Chargebee via Usage.create (Metered Billing) every hour:
Only for customers having chargebee_metered_billing enabled.
Attach the add-on to the subscription (update_for_items) idempotently so Chargebee tracks overages.
Push data points with dedupe key {subscription_id}:{period_start} on a replace policy, i.e. each data point is the accumulated overage for the subscription and period, in the add-on's unit of 1000 calls: round((get_total_events_count() − allowed_30d_api_calls) / 1000) (allowance is already sourced from Chargebee).
Overages are calculated and charged by Chargebee — the task charge_for_api_call_count_overages (current overage logic) ignores subscriptions with chargebee_metered_billing enabled.
Turning chargebee_metered_billing on for a customer mid-term means the next invoice uses Metered Billing data.
Spiked from #7923
Currently overage billing happens in
charge_for_api_call_count_overages, and usesOrganisationSubscriptionInformationCacheto push overage charges to Chargebee as 100K addons (set up in Chargebee). The goal of this issue is to integrate with Chargebee's proper tool for this: Metered Billing, and have Chargebee handle the overage billing logic natively.The scope is limited to adding an integration that co-exists with the current overage logic, while we transition to Metered Billing using a FoF feature flag
chargebee_metered_billing. Responsibility is further cleaned up after GA (see #7971).Note
It seems that Chargebee is moving towards Usage-Based Billing and may sunset Metered Billing in the future. Regardless, we decided to move forward with Metered Billing because:
Acceptance criteria
Usage.create(Metered Billing) every hour:chargebee_metered_billingenabled.update_for_items) idempotently so Chargebee tracks overages.get_total_events_count.{subscription_id}:{period_start}on a replace policy, i.e. each data point is the accumulated overage for the subscription and period, in the add-on's unit of 1000 calls:round((get_total_events_count() − allowed_30d_api_calls) / 1000)(allowance is already sourced from Chargebee).charge_for_api_call_count_overages(current overage logic) ignores subscriptions withchargebee_metered_billingenabled.chargebee_metered_billingon for a customer mid-term means the next invoice uses Metered Billing data.Chargebee setup
Click to expand