Dynamically Update Subscription Price

I am struggling to figure out how to organize the data to calculate a dynamic price for a subscription.

Each subscription is unique and I am building ways to track them separately.
But… a customer could have more than one and I want to reward them if them have more than one.

So it looks something like this…
Sub A - Started 10th of Month, cost $19.99/mo
Sub B - Started 21st of Month, cost $19.99/mo

What I’d like to do is give them a discount on the second subscription, say $10 because they have the FIRST subscription.

That’s pretty easy in and of itself, but where I start getting mixed up is this… what if they cancel Sub A? In that case, the price of Sub B needs to go up to $19.99

If I create something like “If there are more than one subscription then give a $10 discount” it will discount ALL Subscriptions.

I feel like I need something like “If this is not the first subscription for this user, then give the $10 discount” but unsure how to create this.

So my questions are:

  • How do I store the variable price of the subscription
  • What are your thoughts on how I can update it dynamically?

I would store the variable price in your DB (on your subscription object) rather than trying to calculate it on your app pages.

If I’m understanding you correctly, you could setup a backend workflow which updates the price field of each user’s subscription (make changes to a list of things (assuming the list is relatively small) every time you add/remove a user’s subscription. You can tie that workflow either to a database trigger that fires when user’s list of subscriptions changes, or trigger it from any workflow that modifies a user’s list of subscriptions.

That workflow should only fire when user's subscriptions:count > 1, and should update the prices for items from #2 (i.e. every subscription in that list, excluding the first option (sorted by created date).

This sounds like it’s just the ticket. Quick follow up question - what is “relatively small”? Just wondering what limitations you forsee.

I expect most users will have no more than four subscriptions at a time. But you may be referring to the Subscription database in it’s entirety?

No I mean the list on the user.

Single digits is definitely small. If it was going to be hundreds or more of subscriptions for a single user then it could be worth doing this recursively. make changes to a list has a habit of timing out on large lists, though I haven’t visited this in a while and it might be more reliable now.

1 Like