A Really Complicated Function to Perform - What's the "Bubble Way?"

I have transactions and I have users that have “refund policies.”

It’s just like it sounds. People are selling things/services and they have refund policies. So, the app needs to occasionally apply a refund policy to a transaction. Sounds simple enough, until you start doing it in Bubble. It’s amazingly fast for some things. Unexpectedly quite complicated for other things. ha ha ha

The app needs to:

  1. calculate the number of days/hours before the appointment that the client cancels
  2. reference a thing called a “refund policy” that contains information like 50% refund if canceled within 7 days of appointment, 20% refund if canceled within 5 hours of appointment. Each user has a refund policy.
  3. Use both of those pieces of information, in conjunction with the transaction amount, to kick off the Bubble API plugin and send refund amounts to Stripe.

YIKES!!! Seems pretty straightforward if I were doing this in a coding environment, but where can I do these calculations in Bubble? What’s the “Bubble Way?” As in…what’s the best practice and correct way to do something like this in Bubble?

I’m thinking of creating a new thing called a “refund” and populating it with all these numbers then crunching them in a workflow but that seems wasteful. I could delete thing thing when done, but still. Seems like a lot of steps to perform some simple calculations.

I generally use a Refund Policy datatype with two list of numbers: Day Boundaries, & Refund percentages. Make sure they are sorted in the same way. I liked starting with the smallest day + smallest refund percentage first, but it doesnt really matter.
Typical Example would be Days [3,7,14] & percentages [0,50,100]

I then used a simple backend loop that checks whether Booking Date-Currentdatetime>Refund Policy's days' item#Looping Variable. If its larger, reschedule the Backend workflow and increase the looping variable. If it is not, then send the current looping variable to a second Backend workflow which triggers the Stripe APIs and uses theRefund Policy's refund percentages item # looping variable

If creating a new data type bothers you, put the two lists of numbers directly on the seller datatype, but there is nothing wrong with creating a new datatype.

You’ll have to do some calculations somewhere :laughing:

It’s not the most efficient thing, in python/javascript you could do it in one line, but (hopefully) this workflow wont run very often so do not sweat over a few WUs.

3 Likes

Awesome response. Thank you!

I never imagined anyone else was doing built in refund policies like this.

I think I’ll go ahead and make a new data type (thing) called a refund. As it’s created, nearly all the math can be done and it’ll then be straightforward to use it in a workflow to calculate and send the stripe refund amount and adjust app account balances.

Just needed to know if I was missing some better way that is more the “bubble way” and I’m glad I was on the right track actually.

Luckily, the users will apply their own refund policies in my app so they kick it all off with a button press. That makes it easier in that I don’t need to have a backend workflow running for this feature.

Thanks again. Really good post, my refund policy brother… or sister… or whatever it might be.

Also instead of a loop you could probably just have multiple Refund Policies, each with a “Min Days” (number) and “Max Days” (number) (or do a number range). Then have a percentage tied to that. Then it just needs to search for the first item that fits between those days. The age of the order being Current date/time - Order date/time:format as days:ceiling

2 Likes

Nice, I definitely prefer your approach :slight_smile: less error-prone and more versatile.
New refund policy meta. Thanks Tyler

1 Like