How to manage discounts and promos in Bubble

The simplest and most scalable way to manage discounts and promo codes in Bubble is to create a Promo data type, validate it at checkout, and then apply a calculated discount to the user’s Order before charging them. You store only the rules in the Promo (percentage, fixed amount, expiration, usage limit), and you store the result (final price) in the Order so nothing recalculates unexpectedly later.

Data Structure

Create a Promo type with fields that control how and when it’s valid:

• code (text, all caps, unique)
• discount_percent (number) or discount_amount (number)
• expires\_at (date)
• max\_uses (number, optional)
• times\_used (number, defaults to 0)
• is\_active (yes/no)

Validating the Promo

When the user enters a promo code, run a workflow:

• Search for Promos:first item where code = Input Promo's value :uppercase.
• Check conditions: is_active is yes, expires_at > current date/time, times_used < max_uses (if you use usage limits).

If no promo matches, show an error message. If valid, store it in the user’s ongoing Order (e.g., Order’s applied\_promo = This promo).

Calculating the Discount

When a valid promo exists, compute the final price before charging:

• If percent: Order’s final_price = Order’s subtotal × (1 - promo’s discount_percent/100)
• If fixed: Order’s final_price = Order’s subtotal - promo’s discount_amount

Store final\_price as a field on Order so Stripe receives a stable number even if database rules change later.

Charging With Discount

When you call Stripe via Plugin or API Connector, pass Order’s final\_price as the amount. After a successful payment, run a backend workflow to increment the promo usage:

// Backend workflow action
Make changes to Promo:
times_used = This Promo's times_used + 1

Common Mistakes to Avoid

• Do not recalculate discount after the charge. Always save a snapshot field.
• Avoid letting Promo codes be public-readable unless needed. Use Privacy Rules to expose only fields required for validation.
• Never rely on front‑end calculations; always compute discount in a workflow before sending the charge amount.