Refunds after every pricing change
Marketing launches a new plan. Product changes the FX markup for one tier and adds a monthly fee for another. Engineering updates the numbers in the code before the launch date. For the next few weeks, support hears from customers who were charged the new fee on the old plan, charged twice for the monthly fee, or not charged at all.
Finance notices a shortfall in fee income in one area and a spike in refunds in another. Ops refund customers one by one in the admin panel. Nobody can easily list every affected customer, so the list is built from complaints.
Where fee logic hides
In a young fintech, fees are usually written into whichever part of the product charges them.
- Card fees in the card service, transfer fees in the payments service, monthly fees in a scheduled job.
- Plan details repeated in several places, sometimes with different values.
- No record of which plan version a customer was on when a fee was charged.
- Promotions and exceptions added as special cases in code.
- No regular check that charges match the plan.
When pricing changes, every one of those places has to change at the right moment, for the right customers.
The cost of getting fees wrong
Overcharging customers creates refunds, complaints and reputational harm. Undercharging loses revenue that is awkward to recover. Every pricing change becomes a risky engineering release. Finance cannot confidently forecast fee income. What customers are told about fees and how refunds are handled is for your own policy; the job here is to make sure you charge what you meant to.
One pricing service with a daily check
What we build moves fee logic into one place and adds a check behind it.
- A pricing service holds every plan and fee rule as data, with a version and an effective date.
- Each customer has a plan assignment with dates, so you always know which version applied on a given day.
- Every part of the product asks the pricing service for the fee rather than calculating it itself.
- Promotions and exceptions are rules in the service with start and end dates, not code branches.
- Pricing changes are made by an authorised person in an admin screen, reviewed by a second person and scheduled for their effective date.
- A daily check recalculates every fee charged the previous day against the plan in force and flags mismatches for ops.
- Plan changes produce a preview of affected customers before they go live.
| Fee type | Previously calculated in | Now |
|---|---|---|
| Card transaction and FX fees | Card service | Pricing service, versioned |
| Transfer fees | Payments service | Pricing service, versioned |
| Monthly plan fees | Scheduled job | Pricing service, versioned |
| Promotions and waivers | Special cases in code | Dated rules in the service |
We can move one fee type at a time, starting with the one that causes the most trouble, so there is no single risky switch.
Pricing changes without the fallout
A new plan is set up as data, reviewed and scheduled. On the effective date, it applies to the right customers. The next morning's check confirms that fees charged match plans. If something is wrong, ops see a list of affected customers straight away, not after the complaints.
Finance get a reliable fee report by plan and version, and product can test pricing ideas without a release for every change.
Does this sound familiar?
- Pricing changes need engineering releases.
- Customers are refunded after most pricing changes.
- Fee values appear in more than one part of the code.
- You cannot say which plan version applied to a past charge.
- Nobody checks charged fees against plans routinely.