Chargebee Release Notes

Release notes

You can now skip exclusive tax calculations in the Subscription Renewal Estimate API when using third-party tax providers, by adding the exclude_tax_type parameter.

Why is this important?

Previously, taxes were calculated by default in Subscription Renewal Estimate API responses. This contributed to additional charges from third-party tax providers. You can now manage and potentially reduce those external costs.

How can you use it?

Pass the exclude_tax_type=exclusive parameter in Subscription Renewal Estimate API calls to skip exclusive tax calculations, but only when your tax configuration uses a third-party provider. If no value or none is passed, taxes are calculated as usual. This feature is limited to exclusive tax types and will be ignored for inclusive tax setups or non-third-party providers.

A reauthorization flow has been introduced to handle expired HubSpot tokens for Chargebee integrations.

Previously, if a Chargebee app was uninstalled from a HubSpot portal, the associated refresh token would become invalid without the Chargebee integration being aware. This caused repeated sync failures. Now, this fix ensures that Chargebee detects the invalid token, stops further sync attempts, and waits for you to reconnect the integration.

This will be a backend operation. If token invalidation is detected, all forward and backward syncs are paused. You’ll see a banner on the integration dashboard prompting you to reauthorize the connection. Once you complete the reauth flow, the setup resumes from where it stopped ensuring minimal disruption.

You can now generate an estimate and backdate a subscription change beyond the current term in the past. For instance, you can upgrade a subscription beyond the current term, allowing you to move the subscription to a new plan starting from the original subscription start date, even if multiple renewal cycles have already been billed.

Why is this important?

If your business follows a sales-led growth model, contract negotiations often take place over several months while the customer continues on an existing monthly plan. During this time, the subscription may renew multiple times at the old price before the new terms are finalized, making it challenging to apply the agreed changes correctly.

For example, a customer starts on a monthly plan in January. In February, discussions begin to upgrade them to a higher plan with revised pricing, effective from the original subscription start date. However, the negotiations conclude only in May, after several monthly renewals have already been billed. Without the ability to backdate changes beyond the current term, you would need to issue manual credits or adjustments to account for the difference.

How can you use it?

To backdate a subscription change in your Chargebee Billing site, follow these steps:

• Select the subscription record you want to change to open the details page.
• Click Edit Subscription and make the necessary changes.
• In the Apply Changes section, select On a specific date and choose a date from the past to specify when the changes should be applied. Click Apply.

You can now automatically send email notifications when a subscription cancellation is scheduled and when a previously scheduled cancellation is removed, ensuring customers are informed at key moments in the subscription lifecycle.

Why is this important?

This helps you meet regulatory requirements such as the UK Digital Markets, Competition and Consumers Act 2024, by providing clear acknowledgment of cancellation requests. Customers receive confirmation that includes the effective cancellation date and any applicable refund details, which reduces ambiguity and builds trust while supporting your compliance and audit needs.

How can you use it?

Follow these steps to configure the email notifications in your Chargebee Billing site:

• Navigate to Settings > Configure Chargebee > Email Notifications > Customer Retention > Subscription Cancellation.
• Enable the email notifications On cancellation scheduled and On scheduled cancellation removed.

When enabled, Chargebee sends automatic emails acknowledging cancellation requests with the effective date and refund information. If the customer later decides to continue the subscription, a follow-up email confirms that the scheduled cancellation has been successfully removed.

Change overview

Chargebee has updated the behavior of the payment_initiated and payment_failed events to provide clearer visibility into payment attempts. These changes ensure events reflect the actual state of a transaction and include relevant context:

• payment_initiated is now triggered for all payment attempts, including those that enter a needs_attention state (e.g., timeouts, authorization issues).
• payment_failed is triggered only when an attempt fails or moves to needs_attention, and is not triggered for successful or in-progress attempts.
• Event payloads now include the invoice entity if linked to the payment; otherwise, the event is still triggered without it.

Why is this important?

This enhancement provides more accurate, real-time insights into payment behavior. It helps your team identify failed or stalled payment attempts sooner, enabling quicker follow-up and better tracking of the customer payment journey.

How can you use it?

No action is needed on your part. These updated events will automatically reflect in your existing webhooks or event listeners.

Chargebee Checkout now collects shipping addresses for Apple Pay transactions in compliance with Apple’s updated requirements. This ensures compatibility with Apple’s latest processing policies.

Why is this important?

To comply with Apple’s updated policies, Apple Pay transactions now require the collection of the shipping address. Without this, transactions may fail or be rejected by Apple during checkout.

How can you use it?

When a customer selects Apple Pay during Checkout, Chargebee will now automatically request their shipping address. No additional configuration is required on your end, ensuring your Apple Pay integration remains compliant and functional.

When setting allow_offline_payment_methods to true while creating Checkout sessions, some checkouts could still fail at submission even after the customer selected an offline option. This issue occurred when the parameter was passed but Allow customers to use offline payment methods setting was disabled, resulting in errors such as "data not formatted properly" or "there is no card on file". This has now been fixed. Checkout consistently respects the parameter value as an override, regardless of the site setting.