The same quiz could pay a child points again and again
A rewards scheme paid per attempt, so a retry was safe but a retake paid again. A flat price also made payouts grow with the quizzes added. Found in review.
You run a rewards scheme. Customers, or children, earn points for completing something, and the points are worth something. The promise is simple: do the thing once, get paid once.
In a children’s learning app, a quiz pays points when a child submits it. The first design paid per attempt. It passed the test everybody thinks of: if the tablet sends the same submission twice, say because the signal dropped, the child is paid once. And it left a child free to start a fresh attempt at the same quiz, over and over, and be paid every time.
The cost would have been the scheme itself. Points that can be farmed stop meaning anything, and a reward a parent has to honour for work that was never done is an argument nobody can settle, or a refund in a business.
What was actually going on
The payment was tied to the attempt. That distinguishes two cases, and gets the important one the wrong way round. A retry is the same attempt sent twice. A retake is a new attempt at the same quiz. The payment recognised a retry and treated a retake as brand new.
The product plan had already said a retake does not pay again. We found the gap reviewing the code that had just been built, not from a report, and the log does not record any child having used it.
A second thing turned up once a lesson could hold several quizzes. Every quiz paid a flat 25 points. That meant a lesson’s payout grew with however many quizzes a parent happened to add, and nobody had chosen that.
What we changed
The payment now hangs on the quiz: one payment per child per quiz. The earliest submitted attempt decides what the response says, so a retry returns exactly the same answer as before, while a retake reports zero.
Each quiz now carries its own price, and progress is recorded against the quiz rather than the lesson. We checked it on the devices: the second quiz on a lesson paid 10 rather than 25, with two progress rows and two points entries for that one lesson, which the old arrangement could not produce.
What it did not fix
A child can still retake a quiz for practice. They are simply not paid again.
The price per quiz is now a parent’s choice, which removes the accidental multiplication. And a screen already open on a tablet can keep offering a quiz that has just been unpublished. The server refuses the attempt, so it does no harm, but the screen still offers it.
The pattern, for anyone running points, credits or vouchers
Decide what the thing being paid for actually is, then make that the key. “Do not pay twice for the same request” and “do not pay twice for the same work” are different rules, and only the second protects you.
Ask two questions of any scheme you run. What happens if the customer does the thing again from the start, not just resubmits it? And what happens to the payout when somebody adds one more of whatever it is attached to? If you cannot answer both from how the system behaves, go and watch it.
Where this ends up
A points ledger that has to be right under retries, retakes and later changes is the kind of system we build under custom software development.