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?
In cases involving yearly or annual subscriptions, where waiting for an entire year isn't practical, a quick workaround is available. You can pause the yearly/annual subscription before initiating the customer transfer and then set the scheduled resumption date after the transfer, aligning it with your transfer plans. This action will result in the cloning of the paused subscription in the destination business entity at the scheduled resumption date, creating a new invoice for that subscription term in 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:
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.
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:
Freeze Period:
Transaction Closure in Source Entity:
Transfer and Setup in Destination Entity:
Customer Communication:
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?
Please note that the APIs developed for the Customer Transfer feature are currently internal and not accessible to the public. While there are no immediate plans to make them publicly available, this may be considered in the future depending on market demand.
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.