Customer Transfer FAQs

How will E-Invoicing be handled when transferring customers across entities?

For the customer transfer feature, there will be no restrictions in place to prevent customers from being transferred across entities, even if E-Invoicing is enabled and there are failed invoices. At this stage, no additional validation checks will be needed for the transfer.

However, there will be a limitation related to actions such as sending or re-sending invoices in the source business entity. We greatly value customer feedback and will take it into consideration as we work to enhance and refine this process further.
How are yearly or annual subscriptions handled in the customer transfer process since they can't wait for an entire year to let the subscription clone?

You can use a workaround for annual subscriptions where waiting an entire year isn't practical. Pause the annual subscription before starting the customer transfer, then set the resumption date after the transfer to match your transfer plans. This will result in the paused subscription being cloned in the destination business entity on the scheduled resumption date.

If resumption occurs before the renewal date, no new invoice will be generated in the destination business entity, as the source business entity has already issued the invoice. If resumption happens after the renewal date, the subscription will align with the resumption date, and a new invoice will be generated for the destination business entity.
How do you handle the transfer of a customer who has advance invoices, which seems to prevent their transfer?

If a customer is tied to advance invoices or has a billing schedule that includes future dated invoices, the system will not permit their transfer. To navigate this, the following steps can be taken:
- Modify Subscription Invoicing Schedule: Adjust the subscription's invoicing schedule. This change will trigger the generation of an invoice in payment due status, which then can be voided or deleted.
- Proceed with Customer Transfer: With the payment due invoices addressed, you can now continue with the customer's transfer to a different business entity.
By following this method, you can resolve the advance invoice barrier and ensure a smooth transition of the customer between entities. If there are partially paid or fully paid invoices associated with an advance invoicing schedule, the transfer will need to wait until this schedule is completed. Post transfer, new invoicing schedules can be established in the destination entity.
How are customer account currencies handled when transferring a customer across entities?

Currently, in a Multi-entity-enabled domain, business entity-specific currencies are not supported. Instead, all currencies are defined at the site level. This means that when transferring a customer across entities, there are no impacts on the customer's account currency. The customer's account currency remains consistent across the entire domain, ensuring a seamless transfer experience.
What is the reason for validating transactions with statuses like in-progress, failure, timeout, or needs_attention before transferring a customer?

The validation of transactions with these statuses is a critical step in the customer transfer process. This ensures that no transaction is left unresolved, which could lead to complications such as redundant refunds in the source entity. For instance, if an in-progress ACH/DD/SEPA transaction fails after the customer has been transferred, it could create unnecessary complications since credits cannot be allocated to resources that are no longer active or to subscriptions that are in the process of being cloned. To prevent such issues, these transactions must be cleared prior to transfer.
As part of the customer transfer process, if different gateways and accounts are connected to business entities via Smart Routing, what happens when a customer's payment method is linked to a gateway in the original / source business entity? For example, a customer was in our Canadian business entity with a payment method using Stripe-CAD. After transferring the customer to our Australian business entity, why is the payment method still linked to Stripe-CAD instead of being updated to Stripe-ANZ, configured for the Australian business entity?

The Smart Routing rules only affect gateway accounts linked to new payment methods added to the system. Existing payment methods remain associated with their original gateway accounts, regardless of changes to Smart Routing rules. .

When a customer's business entity is changed, and Smart Routing rules are updated, the payment method is copied, but the gateway account linked to the copied (existing) payment method remains unchanged.

Alternatively, you can manually add the customer's payment method to the new gateway account, or follow Stripe's or the relevant Payment Gateway's documentation for updating gateway accounts: Stripe Data Migrations.

If you need assistance for migrating existing customers' gateway accounts to a new one, you can also seek help from our migration team, just as you would do for non-Multi Business Entity sites.
How can a customer be transferred across entities considering the validation checks on Authorization transactions?

For a seamless customer transfer between entities, merchants are advised to follow this recommended workflow: Before the Transfer:
- Examine the existing authorization and capture transactions for each customer scheduled for transfer.
- Determine the status of each transaction to ensure no in-progress authorizations are left hanging during the transfer.
Freeze Period:
- Implement a freeze period for the customer's account during the transfer process to prevent any new authorization requests from being initiated.
- Notify customers about the freeze period and how it will affect their transactions. i.e. let customers know about this freeze and explain how it will temporarily stop their payment activities.
Transaction Closure in Source Entity:
- Complete any pending/remaining authorizations or cancel/void them if they can't be completed before the move.
- Make sure all payments that have been authorized are fully processed so there's nothing left open, that could lead to duplicate charges post-transfer.
Transfer and Setup in Destination Entity:
- Once the customer is transferred, confirm their payment methods in the destination entity as the Payment Methods currently associated with the customer in the source business entity will be transferred to the destination business entity to be linked with the customer's record there.
- Initiate a new authorization in the destination entity as needed for continued service or upcoming billing cycles.
Customer Communication:
- Tell customers clearly what the move means for their payments and what they need to do, like re-confirming their payment methods.
By implementing this procedure, merchants can manage Authorization and capture transactions efficiently and ensure a seamless transition for customers.
How are Orders managed when transferring customers between business entities given the current limitations of the Orders module within the MBE framework?

As of now, the Orders module is not yet aligned with the Multi-Business Entity (MBE) architecture, but this doesn't hinder the movement of customers between entities. If future updates render the Orders module MBE-compatible, there would be no need for additional checks during customer transfers, as Orders data is inherently tied to invoices. To facilitate smooth transfers, it is advisable to ensure that any Orders linked to invoices are finalized---marked as Delivered, Returned, or Cancelled---before you transfer the customer and their subscriptions, since activities related to Orders in the source entity may be restricted post transfer.
How do I cancel an ongoing subscription in the source entity that is scheduled to be cloned in the destination entity but hasn't been due to a billing cycle that doesn't align with the transfer date?

Currently, if a subscription is in the process of being cloned to the destination entity and is in an intermediate state, it cannot be cancelled at that time. You must wait until the subscription is successfully cloned to the destination entity. Once the cloning is complete, you can proceed with canceling that subscription. Following the cancellation, you may either void the latest invoice or issue a credit note to the customer as appropriate.
Can I modify the resumption date of a paused subscription set to be cloned to a different entity, and how should I proceed with the resumption in the destination entity?

Yes, changing the resumption settings for a paused subscription within the source entity while it awaits cloning is permissible. You can either adjust the resumption to occur a few minutes after the transfer, simulating an Immediate Resume, or opt for a "Specific Date Resumption" via the settings page. This flexibility allows you to manage the subscription's resumption to either align with the transfer to the destination entity.
Why can't I see the Upcoming Payment section in the Summary tab displaying the upcoming invoice estimate for a customer after their transfer, when their subscription is yet to be cloned at the next renewal date in the destination business entity?

The Upcoming Payment section reflects estimates based on active subscriptions. In the case of a transferred customer, their original subscription is scheduled to move to the destination business entity upon renewal. Therefore, in the source entity, the Summary tab will indicate No upcoming payments since the existing subscription is no longer active there. However, if you create a new subscription for this customer in the source entity, the Upcoming Payment section will then display estimates for that new subscription.
How does the system manage subscriptions in the event of two customer transfers initiated at distinct times, especially when one subscription is set for cloning post-transfer date and another is cloned right on the transfer date?

Let's consider a scenario: Imagine you transfer a customer on November 21. This customer has two subscriptions, S1 and S2. Subscription S1 is scheduled to renew on November 25 and will be cloned to the new (destination) entity on that date. Subscription S2 is cloned to the new entity on the day of the transfer, November 21. If another transfer of the same customer is initiated before S1's renewal and cloning date, what happens to S1?

In this case, since S1 is still pending renewal and has not yet been cloned, it remains in its original state within the source entity until its scheduled cloning. If the customer is transferred again before S1 is cloned, S1's cloning would be aligned with the latest transfer details. Essentially, the cloning process for S1 would be updated to reflect the customer's new entity post-second transfer, ensuring that S1 follows the customer to the current destination entity.
Are there any APIs available for this feature that I can use instead of the Chargebee application?

Yes, there is a Business entity transfer resource available for this feature that you can use instead of the Chargebee application. Using these APIs you can Transfer resource to another business entity and List business entity transfers.
What would happen with Gift subscriptions created with gift plans having more than two billing cycles?

Gift subscriptions with plans having more than two billing cycles are subject to certain restrictions. Our existing validations prevent customers with unclaimed gift subscriptions from being transferred. This ensures that both the gift giver and the receiver remain within the source entity until the gift subscriptions are either claimed or canceled.

Once a subscription is claimed and created, it is automatically designated as non-renewing. This designation allows the receiver to transfer to another entity while the gift giver continues to belong to the source entity.

However, it's important to note that after the receiver has been transferred to another entity, the same gift giver cannot offer additional subscriptions to the same receiver. This is to prevent any conflicts or issues in managing subscriptions.

In summary, this mechanism ensures smooth management of gift subscriptions and helps prevent any clashes or complications.
Why am I unable to transfer a customer at the end of their contract term, despite waiting for the renewal period and attempting the transfer after their initial 1-year contract has concluded?

We have a validation where if a subscription has active contract terms is not allowed to transfer. This means if an active contract term record exists, movement is not allowed to explain it if a contract term is set with rules like "Renewing subscription for the same duration" & "Renewing subscription for a different duration" there will always be an active contract term record exists which prohibits the transfer.

However, if the contract term is set up with rules like, "Cancelling contract and the subscription" & "Cancelling contract but continuing the subscription" then the customer transfer will be allowed when the term is cancelled. For example, if the transfer date coincides with the contract term cancel date then the customer will be cloned in the destination/new entity and if the subscription is continuing then the subscription would continue in the source/original entity and would be cloned on their next renewal term.
What happens to the Customer & Subscription IDs during the transfer process?

Consider you have a customer created in Entity A on December 29, 2023, with a subscription for a monthly billing cycle. In Entity A:
- Customer ID: 123
- Subscription ID: xyz-123
- An invoice is generated for the period December 29, 2023, to January 29, 2024.
Suppose you transfer this customer from Entity A to Entity B on January 29, 2024. The records would then appear as follows: In Entity A:
- Customer ID: 567 (changed)
- Subscription ID: dgh-567 (changed)
- Invoice for December 29, 2023, to January 29, 2024, remains.
In Entity B:
- Customer ID: 123 (original)
- Subscription ID: xyz-123 (original)
- Invoice for January 29, 2024, to February 29, 2024, is generated. This means the original IDs generated during the creation of the customer and subscription are carried forward post-transfer in the new/destination entity. However, since we cannot have the same ID across entities, the ID in the original entity is currently changed to a randomly generated value. This maintains a link between the two records. We use a mapping table to record the relationship between these randomly generated IDs in the source business entity (for the deprecated resources) and their corresponding original IDs in the destination business entity.
Therefore, the IDs post transfer remain as they were when the customer and subscription were initially created.

How will E-Invoicing be handled when transferring customers across entities?

For the customer transfer feature, there will be no restrictions in place to prevent customers from being transferred across entities, even if E-Invoicing is enabled and there are failed invoices. At this stage, no additional validation checks will be needed for the transfer.

However, there will be a limitation related to actions such as sending or re-sending invoices in the source business entity. We greatly value customer feedback and will take it into consideration as we work to enhance and refine this process further.

How are yearly or annual subscriptions handled in the customer transfer process since they can't wait for an entire year to let the subscription clone?

You can use a workaround for annual subscriptions where waiting an entire year isn't practical. Pause the annual subscription before starting the customer transfer, then set the resumption date after the transfer to match your transfer plans. This will result in the paused subscription being cloned in the destination business entity on the scheduled resumption date.

If resumption occurs before the renewal date, no new invoice will be generated in the destination business entity, as the source business entity has already issued the invoice. If resumption happens after the renewal date, the subscription will align with the resumption date, and a new invoice will be generated for the destination business entity.

How do you handle the transfer of a customer who has advance invoices, which seems to prevent their transfer?

If a customer is tied to advance invoices or has a billing schedule that includes future dated invoices, the system will not permit their transfer. To navigate this, the following steps can be taken:

Modify Subscription Invoicing Schedule: Adjust the subscription's invoicing schedule. This change will trigger the generation of an invoice in payment due status, which then can be voided or deleted.
Proceed with Customer Transfer: With the payment due invoices addressed, you can now continue with the customer's transfer to a different business entity.

By following this method, you can resolve the advance invoice barrier and ensure a smooth transition of the customer between entities. If there are partially paid or fully paid invoices associated with an advance invoicing schedule, the transfer will need to wait until this schedule is completed. Post transfer, new invoicing schedules can be established in the destination entity.

How are customer account currencies handled when transferring a customer across entities?

Currently, in a Multi-entity-enabled domain, business entity-specific currencies are not supported. Instead, all currencies are defined at the site level. This means that when transferring a customer across entities, there are no impacts on the customer's account currency. The customer's account currency remains consistent across the entire domain, ensuring a seamless transfer experience.

What is the reason for validating transactions with statuses like in-progress, failure, timeout, or needs_attention before transferring a customer?

The validation of transactions with these statuses is a critical step in the customer transfer process. This ensures that no transaction is left unresolved, which could lead to complications such as redundant refunds in the source entity. For instance, if an in-progress ACH/DD/SEPA transaction fails after the customer has been transferred, it could create unnecessary complications since credits cannot be allocated to resources that are no longer active or to subscriptions that are in the process of being cloned. To prevent such issues, these transactions must be cleared prior to transfer.

As part of the customer transfer process, if different gateways and accounts are connected to business entities via Smart Routing, what happens when a customer's payment method is linked to a gateway in the original / source business entity? For example, a customer was in our Canadian business entity with a payment method using Stripe-CAD. After transferring the customer to our Australian business entity, why is the payment method still linked to Stripe-CAD instead of being updated to Stripe-ANZ, configured for the Australian business entity?

The Smart Routing rules only affect gateway accounts linked to new payment methods added to the system. Existing payment methods remain associated with their original gateway accounts, regardless of changes to Smart Routing rules. .

When a customer's business entity is changed, and Smart Routing rules are updated, the payment method is copied, but the gateway account linked to the copied (existing) payment method remains unchanged.

Alternatively, you can manually add the customer's payment method to the new gateway account, or follow Stripe's or the relevant Payment Gateway's documentation for updating gateway accounts: Stripe Data Migrations.

If you need assistance for migrating existing customers' gateway accounts to a new one, you can also seek help from our migration team, just as you would do for non-Multi Business Entity sites.

How can a customer be transferred across entities considering the validation checks on Authorization transactions?

For a seamless customer transfer between entities, merchants are advised to follow this recommended workflow: Before the Transfer:

Examine the existing authorization and capture transactions for each customer scheduled for transfer.
Determine the status of each transaction to ensure no in-progress authorizations are left hanging during the transfer.

Freeze Period:

Implement a freeze period for the customer's account during the transfer process to prevent any new authorization requests from being initiated.
Notify customers about the freeze period and how it will affect their transactions. i.e. let customers know about this freeze and explain how it will temporarily stop their payment activities.

Transaction Closure in Source Entity:

Complete any pending/remaining authorizations or cancel/void them if they can't be completed before the move.
Make sure all payments that have been authorized are fully processed so there's nothing left open, that could lead to duplicate charges post-transfer.

Transfer and Setup in Destination Entity:

Once the customer is transferred, confirm their payment methods in the destination entity as the Payment Methods currently associated with the customer in the source business entity will be transferred to the destination business entity to be linked with the customer's record there.
Initiate a new authorization in the destination entity as needed for continued service or upcoming billing cycles.

Customer Communication:

Tell customers clearly what the move means for their payments and what they need to do, like re-confirming their payment methods.

By implementing this procedure, merchants can manage Authorization and capture transactions efficiently and ensure a seamless transition for customers.

How are Orders managed when transferring customers between business entities given the current limitations of the Orders module within the MBE framework?

As of now, the Orders module is not yet aligned with the Multi-Business Entity (MBE) architecture, but this doesn't hinder the movement of customers between entities. If future updates render the Orders module MBE-compatible, there would be no need for additional checks during customer transfers, as Orders data is inherently tied to invoices. To facilitate smooth transfers, it is advisable to ensure that any Orders linked to invoices are finalized---marked as Delivered, Returned, or Cancelled---before you transfer the customer and their subscriptions, since activities related to Orders in the source entity may be restricted post transfer.

How do I cancel an ongoing subscription in the source entity that is scheduled to be cloned in the destination entity but hasn't been due to a billing cycle that doesn't align with the transfer date?

Currently, if a subscription is in the process of being cloned to the destination entity and is in an intermediate state, it cannot be cancelled at that time. You must wait until the subscription is successfully cloned to the destination entity. Once the cloning is complete, you can proceed with canceling that subscription. Following the cancellation, you may either void the latest invoice or issue a credit note to the customer as appropriate.

Can I modify the resumption date of a paused subscription set to be cloned to a different entity, and how should I proceed with the resumption in the destination entity?

Yes, changing the resumption settings for a paused subscription within the source entity while it awaits cloning is permissible. You can either adjust the resumption to occur a few minutes after the transfer, simulating an Immediate Resume, or opt for a "Specific Date Resumption" via the settings page. This flexibility allows you to manage the subscription's resumption to either align with the transfer to the destination entity.

Why can't I see the Upcoming Payment section in the Summary tab displaying the upcoming invoice estimate for a customer after their transfer, when their subscription is yet to be cloned at the next renewal date in the destination business entity?

The Upcoming Payment section reflects estimates based on active subscriptions. In the case of a transferred customer, their original subscription is scheduled to move to the destination business entity upon renewal. Therefore, in the source entity, the Summary tab will indicate No upcoming payments since the existing subscription is no longer active there. However, if you create a new subscription for this customer in the source entity, the Upcoming Payment section will then display estimates for that new subscription.

How does the system manage subscriptions in the event of two customer transfers initiated at distinct times, especially when one subscription is set for cloning post-transfer date and another is cloned right on the transfer date?

Let's consider a scenario: Imagine you transfer a customer on November 21. This customer has two subscriptions, S1 and S2. Subscription S1 is scheduled to renew on November 25 and will be cloned to the new (destination) entity on that date. Subscription S2 is cloned to the new entity on the day of the transfer, November 21. If another transfer of the same customer is initiated before S1's renewal and cloning date, what happens to S1?

In this case, since S1 is still pending renewal and has not yet been cloned, it remains in its original state within the source entity until its scheduled cloning. If the customer is transferred again before S1 is cloned, S1's cloning would be aligned with the latest transfer details. Essentially, the cloning process for S1 would be updated to reflect the customer's new entity post-second transfer, ensuring that S1 follows the customer to the current destination entity.

Are there any APIs available for this feature that I can use instead of the Chargebee application?

Yes, there is a Business entity transfer resource available for this feature that you can use instead of the Chargebee application. Using these APIs you can Transfer resource to another business entity and List business entity transfers.

What would happen with Gift subscriptions created with gift plans having more than two billing cycles?

Gift subscriptions with plans having more than two billing cycles are subject to certain restrictions. Our existing validations prevent customers with unclaimed gift subscriptions from being transferred. This ensures that both the gift giver and the receiver remain within the source entity until the gift subscriptions are either claimed or canceled.

Once a subscription is claimed and created, it is automatically designated as non-renewing. This designation allows the receiver to transfer to another entity while the gift giver continues to belong to the source entity.

However, it's important to note that after the receiver has been transferred to another entity, the same gift giver cannot offer additional subscriptions to the same receiver. This is to prevent any conflicts or issues in managing subscriptions.

In summary, this mechanism ensures smooth management of gift subscriptions and helps prevent any clashes or complications.

Why am I unable to transfer a customer at the end of their contract term, despite waiting for the renewal period and attempting the transfer after their initial 1-year contract has concluded?

We have a validation where if a subscription has active contract terms is not allowed to transfer. This means if an active contract term record exists, movement is not allowed to explain it if a contract term is set with rules like "Renewing subscription for the same duration" & "Renewing subscription for a different duration" there will always be an active contract term record exists which prohibits the transfer.

However, if the contract term is set up with rules like, "Cancelling contract and the subscription" & "Cancelling contract but continuing the subscription" then the customer transfer will be allowed when the term is cancelled. For example, if the transfer date coincides with the contract term cancel date then the customer will be cloned in the destination/new entity and if the subscription is continuing then the subscription would continue in the source/original entity and would be cloned on their next renewal term.

What happens to the Customer & Subscription IDs during the transfer process?

Consider you have a customer created in Entity A on December 29, 2023, with a subscription for a monthly billing cycle. In Entity A:

Customer ID: 123
Subscription ID: xyz-123
An invoice is generated for the period December 29, 2023, to January 29, 2024.

Suppose you transfer this customer from Entity A to Entity B on January 29, 2024. The records would then appear as follows: In Entity A:

Customer ID: 567 (changed)
Subscription ID: dgh-567 (changed)
Invoice for December 29, 2023, to January 29, 2024, remains.

In Entity B:

Customer ID: 123 (original)
Subscription ID: xyz-123 (original)
Invoice for January 29, 2024, to February 29, 2024, is generated. This means the original IDs generated during the creation of the customer and subscription are carried forward post-transfer in the new/destination entity. However, since we cannot have the same ID across entities, the ID in the original entity is currently changed to a randomly generated value. This maintains a link between the two records. We use a mapping table to record the relationship between these randomly generated IDs in the source business entity (for the deprecated resources) and their corresponding original IDs in the destination business entity.

Therefore, the IDs post transfer remain as they were when the customer and subscription were initially created.

Product Updates

Getting Started

Implementing Chargebee

AI in Chargebee

Developer Resources

Product Catalog

Subscriptions

Customers

Entitlements

Usage Based Billing

Chargebee CPQ

Invoices, Credit Notes, and Quotes

Taxes

Hosted Capabilities

Site Configuration

Multi Business Entity

Mobile Subscriptions

Reports and Analytics

Integrations

Data Privacy & Security

Data Operations

Customer Transfer FAQs

Product Updates

Getting Started

Implementing Chargebee

AI in Chargebee

Developer Resources

Product Catalog

Subscriptions

Customers

Entitlements

Usage Based Billing

Chargebee CPQ

Invoices, Credit Notes, and Quotes

Taxes

Hosted Capabilities

Site Configuration

Multi Business Entity

Mobile Subscriptions

Reports and Analytics

Integrations

Data Privacy & Security

Data Operations

Customer Transfer FAQs