Charity Raffle and Lottery Software Problems: The 6 That Void a Draw or Risk Your Licence, and How to Avoid Them

Why does ticket numbering get underestimated so often?

Because on paper it is a counter, and every developer has written a counter. The requirement reads as one line in the licence conditions, it produces no visible feature, and it is the single hardest engineering problem in the whole build.

What makes it hard is that three things have to be simultaneously true at several hundred sales per second across multiple servers. Every ticket sold carries a unique number. The full sequence reconstructs afterwards with no unexplained holes. And no number is ever issued twice, including when a payment processor times out and the buyer presses the button again.

The common approaches each fail in a specific way. A database sequence bottlenecks under load and becomes the reason checkout times out in the final hour. A distributed identifier generator scales beautifully and leaves gaps that a regulator will ask you to explain. Issuing the number before payment settles produces holes wherever a card declines. Issuing it after settlement without idempotency produces duplicates the first time a webhook is delivered twice.

The pattern that holds is a single authoritative issuance path with pre allocated blocks, tickets that exist only once payment has actually settled, and an append only ledger where an abandoned reservation is recorded as abandoned rather than deleted. Reservation before payment, issuance after, nothing removed. Ontario's electronic raffle system requirements are the strictest widely available reference on this, and building to that standard tends to satisfy other regulators too. If a developer proposes generating numbers on the client, or reconstructing them afterwards from a payment processor export, that is the moment to stop the conversation rather than the moment to negotiate.

What goes wrong when you migrate supporter and prior draw records?

Most charities arrive with three years of history spread across a packaged raffle platform, a payment processor, a donor database and a spreadsheet somebody maintained for the calendar draw. The instinct is to bring all of it into the new system so the reporting is continuous. That instinct causes two specific problems.

The first is that historical ticket records were never designed to be re verified. If you import old draws as live data, your new ledger now contains sequences it did not issue and cannot vouch for, and the integrity guarantee you just paid to build is diluted by records that predate it. Keep completed draws as an archive: immutable, queryable, clearly labelled as imported, and outside the issuance ledger. Reporting can join across both. The ledger should only ever contain tickets your system issued.

The second is supporter identity. The same person appears as a ticket buyer under an email address, as a donor in your fundraising database under a household record, and as an event attendee under a misspelling. Merging those badly is worse than not merging them, because a raffle purchase is not a gift and treating it as one distorts every fundraising metric you have and can create receipting problems. Decide before migration which system owns the constituent record, keep the raffle transaction linked to it rather than duplicated inside it, and record the transaction type explicitly. Charities that skip that decision spend the following year explaining to their board why total income moved.

The third, smaller trap is subscription draws. If supporters are already on a recurring monthly entry with a stored payment method, migrating those mandates is a payments exercise with its own consent and authorisation questions, not a data load. Plan it as a separate workstream and expect a proportion of mandates to need re authorisation rather than transfer.

Why do payment webhooks and in venue devices break after launch?

Two integrations decide whether a draw night goes well, and neither of them is the one people ask about during procurement.

The first is the payment processor callback. On a quiet Tuesday, a payment succeeds and the confirmation arrives instantly. On draw night, callbacks arrive late, arrive twice, or never arrive at all while the charge has definitely gone through. If your system issues a ticket on receipt of a callback with no idempotency key, a duplicate delivery issues a second ticket for one payment. If it issues nothing when a callback is lost, you have a buyer who has been charged and holds no ticket, which is a regulatory problem rather than a support ticket. The fix is unglamorous and non negotiable: idempotency keys on every issuance, a reconciliation job that compares settled charges against issued tickets on a short cycle, and a visible exception queue rather than a log file. Test it by deliberately replaying callbacks and by dropping them.

The second is in venue hardware. Handhelds, thermal printers and arena connectivity turn a web problem into a field operations problem. The failure is always the same shape: a seller in a concourse loses signal mid transaction and either the buyer is charged with no ticket printed or the seller retries and issues two. Devices need to hold a local queue, generate their own idempotent request identifiers, show the seller unambiguously what has reached the server, and refuse to print anything the server has not confirmed. Test that in the venue, with the venue's own network, on a busy night, before you rely on it for a jackpot.

What happens when prize claim and licence reporting are not covered?

Every project in this category is scoped around the sale and the draw, because that is the exciting part. The work that follows the draw is where operational discipline collapses and where the regulator actually looks.

The winner has to be contacted, identified and paid, sometimes with withholding and reporting obligations that depend on jurisdiction and prize size. Unclaimed prizes carry rules about how long you hold them and what happens to the money afterwards. Then the licence report is due and it must reconcile gross sales, expenses, prize payout and the charitable proceeds figure your conditions require, against a ledger that also has to explain every number you issued.

Built into the system, that report is generated from the same ledger that issued the tickets and takes minutes. Assembled by hand from a payment export and a spreadsheet, it takes a week, and the two sources disagree because the payment processor knows about refunds the spreadsheet does not. That disagreement is exactly what a monitor looks for.

The other uncovered gap is close time enforcement. Sales must stop at the second the licence specifies, and a transaction that was in flight when the clock struck has to be handled by a rule you decided in advance rather than by whoever is watching the screen. Decide with your compliance counsel whether an in flight authorisation completes or is voided and refunded, write it into the system, and log every decision it makes. A single sale that completed after close is enough to put a draw in question.

Should you build custom or configure what you already own?

Buy if you run one or two conventional draws a year in a single jurisdiction with a modest jackpot. Rafflebox is a real product with genuine experience in Canadian charitable draws and will handle a standard 50/50 or calendar raffle without you writing anything. Ascend Fundraising Solutions has serious experience with large in venue draws and the hardware and staffing that go with them. There is no prize for reinventing ticket numbering, and a charity that builds when it should have bought has converted a solved compliance problem into an unsolved one.

Build when draws have become a recurring revenue programme rather than an event, when you sell across jurisdictions whose eligibility, numbering and reporting rules differ, when your draw structures include stacked, early bird or subscription formats a packaged product does not expose, when per ticket platform fees have grown large against your charitable proceeds, or when supporter data from draws is strategically important and needs to sit in your own systems with clean attribution.

How do hidden costs get into the quote?

Jurisdiction count is the largest multiplier and the most commonly missing. Each additional province or state brings its own eligibility rules, numbering expectations, unclaimed prize handling and reporting format, and in some cases a requirement that the system be reviewed before use. A proposal that does not name the jurisdictions in scope is priced for one.

Certification is the second, and it is calendar time rather than engineering time. Where a regulator reviews a system before it may be used, that review happens after the software is finished and cannot be compressed by adding people. Charities that discover this in month four lose a draw season.

Load testing is the third and is routinely quoted as a line item rather than a phase. Testing to a realistic peak means building traffic generation, running against production grade infrastructure and fixing what it finds, and what it finds is usually in the payment path.

In venue hardware is the fourth, since handhelds, printers, spares, seller training and venue network testing are an operations programme, not a feature. Subscription draws are the fifth, because recurring billing, failed payment handling and entitlement questions arrive together. And the sixth is your own people: your compliance counsel deciding the inconclusive geolocation policy and the close time rule, which sits on the critical path and appears in no developer's number.

What separates a build that works from one that fails here?

Sequence first. The builds that work ship one draw type, in one jurisdiction, online only, with the compliance core complete: issuance ledger, eligibility gate, draw evidence and reporting. In venue sales and subscriptions come afterwards, once the core has survived a real draw night. The ones that fail try to launch every channel into the first season and discover the ticket ledger problem with a jackpot on the line.

Second, treat the evidence pack as a deliverable with a name, not as a reporting screen. Ask any developer to describe its contents before you sign: pool size at close, the hash of the sealed pool, the timestamp, the random source used, the selection, the witnesses. If they cannot list it, they are building a checkout with a random number at the end.

Third, make the append only ledger a day one decision. Immutability cannot be retrofitted onto tables that have been doing updates, and a system that has restated its own history is precisely the thing a challenge attacks.

Fourth, rehearse. Run a full dress rehearsal with synthetic load at your expected peak, replay and drop payment callbacks deliberately, and run a test draw end to end including the evidence pack. Then do it again in the venue with the real network.

Finally, settle ownership in writing before kickoff: the repository, the cloud accounts and the right to hire another firm. At Digital Heroes the client owns the code from the first commit. The licence obligations sit with your charity, and if a regulator asks for draw evidence you cannot be waiting on a vendor to grant access to your own records.