Create BillingAccountMembership when processing Zuora Callouts

Problem

In #4795 (closed), the BillingAccount and BillingAccountMembership should be created when a purchase originates from CustomersDot (ie. self service purchase). However, there are still places where the BillingAccount and/or BillingAccountMembership should be created outside of this workflow.

  • Sales-assisted purchases
  • Renewals

In these cases, CustomersDot processes the callout from Zuora in order to update the Customer (to be renamed User) and provision the subscription. The Zuora callout code in CustomersDot needs to be updated to handle BillingAccount and BillingAccountMembership creation.

Proposal

In this issue, the FindOrCreateCustomerService should be updated to create an BillingAccountMembership for a Customer (to be renamed User) when the zuora_account_id attribute is present. It should also consider creating the BillingAccount if it doesn't already exist.

If an existing Customer is found, but the Customer is not associated with the BillingAccount matching zuora_account_id, a new BillingAccountMembership (and potentially new BillingAccount) could be created.

We've decided for this first iteration (&8950 (closed)), that we want to ensure only one BillingAccountMembership for a Customer. This is to keep the same behavior as before, allowing us to step into the new data architecture and roll out the changes more effectively. See the description in &8950 (closed) for more info.

Feature flag

This logic will be feature flagged in the short term using the :account_data_persistence flag. Here is the rollout issue for it: [Feature flag] Persist Billing Account related ... (#5060 - closed). Once we confirm the data is being created as expected and doesn't have any negative effects with the existing creation behavior, we will remove this feature flag.

As this is just creating data in the new models but not using it yet, we shouldn't need to use the :account_data_structure feature flag for this logic. Eventually, the code setting customer.zuora_account_id will be removed but for now both will be set. This will allow us to roll out changes more efficiently without worry of breaking existing functionality.

Availability & Testing

Tests should be created/updated to account for this change. Test to ensure that:

  • Likely Model and Controller specs (to ensure proper validation and relation)
  • UI specs
Edited by Tyler Amos