Partner Payout & Incentive Engine
Calculates, verifies and releases commission for thousands of channel partners — slab-based schemes, multi-tranche disbursals, and a reconciliation trail that holds up per rupee.
Client
Fintech (India)
Service
Distributed Systems
Date
March 1, 2026
Challenge
Commission is a function of which lender, which product, which slab the partner is in, and how much of the loan has actually been disbursed so far. Disbursal arrives in tranches, schemes change mid-quarter, and every wrong number is money that either went missing or went out twice.
Solution
A scheme model that resolves lender group, product and slab into a point value, an eligibility gate that runs before anything reaches finance, idempotent payout legs so a retry cannot double-pay, and an append-only log that makes every calculation reconstructable after the fact.
Why this is hard
Paying commission looks like multiplication until you look closely.
The loan disburses in tranches, so a partner earns against each tranche rather than each case. The rate depends on a scheme, and a scheme is not one number — it is a lender group, a product, and a slab range that the partner’s own volume determines. Schemes get revised, and a revision must not retroactively change what was already paid. Some partners sit on payin rather than payout, which inverts the direction of the money.
And the whole thing is idempotent-or-broken. A retried message, a double-clicked button, a replayed webhook: any of them can create a second payout leg for a tranche that was already settled, and that error leaves the building as real money.
What was built
A resolvable scheme model. Lender groups, financers, products and slab ranges compose into a single point value for a given tranche. Resolution is a pure lookup against versioned scheme rows, so a payout computed in March still recomputes to the same number in September.
An eligibility gate. Before anything is pushed to finance, a tranche is checked against a set of explicit conditions — disbursal confirmed, mapping present, partner active, no live leg already existing for this payout type. A tranche that fails does not half-process; it stays visible as blocked, with the reason attached. Most support questions turn out to be one of those conditions, which is why the gate reports rather than just refuses.
Idempotent legs. A payout leg is keyed on the tranche and the payout type, so duplicate creation is a constraint violation rather than a silent second payment. Detecting existing duplicates was its own exercise: the same tranche and partner holding two live legs is invisible in aggregate reporting and obvious in a targeted query.
An append-only log. Every MIS row written or deleted is also appended to a log, so a gap discovered weeks later can be reconstructed instead of re-derived by hand. This is the difference between an accounting discrepancy that takes an afternoon and one that takes a week.
Stack
Node.js, Python, MySQL, RabbitMQ, Redis.