Charity Lottery and Raffle Software: Selling 60,000 Tickets in Three Hours Without Voiding the Draw

The three hours where the whole year is decided

A hospital foundation 50/50 with a jackpot climbing past $400,000. Sales open Monday, tick along quietly all week, and then 70 percent of the money arrives between the second period and the final buzzer on Saturday night. Your platform has to take card payments at that rate, issue every ticket with a number that a regulator can later reconstruct in order, refuse anyone outside the eligible jurisdiction, refuse anyone under the age limit, close sales at the exact second the licence says, run a draw whose randomness you can evidence, and produce a winner. Then you have to be able to prove all of it, months later, to somebody whose job is to find the gap.

What makes this different from ordinary ecommerce is that a defect is not a refund conversation. A defect is a void draw. If tickets were issued out of sequence, if a sale completed after the close, if a person in an ineligible jurisdiction bought in, or if you cannot evidence how the winning number was selected, the regulator can void the draw and put the licence at risk. The revenue is one problem. The public story about a hospital foundation that had to cancel a draw is a much bigger one.

So the build is really two builds sitting on each other: a high concurrency payments and ticketing system, and a compliance evidence system. Most teams underestimate the second one, because it produces nothing a donor sees.

What Rafflebox and Ascend actually cover

Rafflebox is a real and capable product in this space, particularly for Canadian charitable draws, and it will handle a conventional 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. Neither is a weak option and both should be on your list before you consider a build.

They run short in three situations. The first is unusual draw structures. Once you want stacked draws, early bird prizes that themselves need separate numbering, subscription draws that auto enter a supporter every month with a payment that can fail, or a lottery where ticket packs carry different odds, you are outside what a packaged product exposes and into workarounds. The second is multi jurisdiction. If you sell into more than one province or state, the rules on eligibility, ticket numbering, unclaimed prizes and reporting differ, and a product that models one regime will make you manage the other by hand. The third is integration. Your draws generate supporters, and supporters belong in your donor database with a source attribution so next year's appeal knows who played. Getting that link right against Raiser's Edge, Salesforce or whatever you run is usually a project of its own.

Problem one: ticket numbering that has to be provably sequential

Regulators care about ticket numbering because it is the audit backbone. Every ticket sold must be uniquely and sequentially identified, unsold numbers must be accounted for, and the sequence must reconstruct after the fact. That sounds trivial until you are issuing several hundred tickets a second across multiple application servers, at which point the naive approaches all fail: database sequences bottleneck, distributed identifier generators produce gaps, and any scheme with a retry can double issue.

The pattern that holds is a single authoritative issuance path with pre allocated blocks and an append only ledger, where a ticket exists only once payment has actually settled and the ledger entry is written. Reservation happens before payment, issuance happens after, and abandoned reservations are recorded rather than deleted so the sequence has no unexplained holes. Ontario's electronic raffle system requirements are the strictest common reference point on this, and building to that standard tends to satisfy everyone else. If a developer proposes generating ticket numbers on the client or after the fact from a payment export, stop the conversation.

Problem two: eligibility that has to be checked before the sale, not after

Age and location eligibility are conditions of your licence. Checking them after the money arrives is not compliance, it is a refund process. The practical requirement is a gate before the payment step: a self declared date of birth at minimum, geolocation with a documented method and a recorded result, and a block list for jurisdictions your licence does not cover.

The hard part is that geolocation is imperfect and your buyers are real people at a hockey game with bad signal. A build has to decide what happens on an inconclusive check, and that decision is a policy question for your compliance counsel, not for an engineer. What the software must guarantee is that whatever policy you set was applied consistently and that the evidence of each check survives with the ticket. When a regulator asks how you knew that buyer was in province, the answer needs to be a stored result with a timestamp and a method, not a description of your intent.

Problem three: the draw itself is the evidence

The draw is a few milliseconds of computation carrying the entire integrity of the event. What matters is that you can demonstrate afterwards that the selection was random, that it drew only from validly issued and paid tickets, that the eligible pool was frozen at the close time, and that nobody could have influenced it.

A serious build seals the sales pool at close into an immutable snapshot with a cryptographic hash, uses a documented random source, records the draw inputs and outputs in an append only log, and produces a draw certificate showing the pool size, the hash, the timestamp, the selection and who witnessed it. Some jurisdictions require a witness or an independent observer, some require the system itself to be certified before use, and you must confirm your specific obligations with your regulator and your counsel rather than with an article. What is universal is that reproducibility is the deliverable. A draw you cannot reconstruct is a draw you cannot defend.

Problem four: after the draw, when everyone stops paying attention

Prize claim is where operational discipline collapses. The winner has to be contacted, identified, and paid, sometimes with tax withholding and reporting obligations depending on jurisdiction and prize size. Unclaimed prizes have rules about how long you hold them and what happens to the money afterwards. Then the licence report is due, and it has to reconcile gross sales, expenses, prize payout and the charitable proceeds figure your licence conditions require.

Building the claim workflow and the reporting pack is unglamorous and it is where a custom system earns its keep, because these are the artefacts that go to the regulator. Generated from the same ledger that issued the tickets, they take minutes. Assembled by hand from a payment processor export and a spreadsheet, they take a week and they disagree with each other.

Cost, timeline and what drives it

In Digital Heroes delivery experience, a first release covering compliant ticket issuance, eligibility gating, high concurrency payments, the draw with evidence, and winner notification runs $80,000 to $170,000 and ships in 14 to 20 weeks. A full platform with subscription and calendar draws, bonus and early bird structures, in venue point of sale with handheld devices, prize claim workflow, regulator reporting and donor system integration runs $200,000 to $450,000 over 8 to 14 months.

What pushes the price up: the number of jurisdictions, because each is a separate rule set and often a separate certification. In venue sales hardware, since handhelds, printers and unreliable arena connectivity turn a web problem into a field operations problem. Payment architecture at draw night concurrency, which needs load testing against realistic spikes rather than average traffic. Certification, where a regulator requires the system to be reviewed before use, which adds calendar time you cannot compress. And subscription draws, which look small and bring recurring billing, failed payment handling and entitlement questions with them.

What keeps it down: launching with a single draw type in a single jurisdiction, online only, and treating in venue and subscriptions as later phases once the compliance core is proven.

When to buy instead

Buy if you run one or two draws a year, sell in one jurisdiction, and your jackpot is modest. Buy if your team has no appetite for owning a system that regulators inspect. Rafflebox and Ascend both exist because most charities should not be building this, and there is no prize for reinventing ticket numbering.

Build when the draw is a recurring revenue programme rather than an event, when you sell across jurisdictions with different rules, when your draw structures do not fit the shapes a product offers, when the per ticket fees on packaged platforms have become a large number against your proceeds, or when the supporter data from draws is strategically important and you need it in your own systems with clean attribution. The tipping point is usually a mix of scale and structure: once draws are a programme with a calendar, the compliance and reporting overhead of running them on someone else's fixed workflow starts costing more than the software would.

How to choose a developer

Ask how they will guarantee sequential ticket issuance under concurrent load, and listen for whether they mention settlement ordering, reservations and an append only ledger. Anyone who answers with a database auto increment has not thought about what happens at 300 sales a second across several servers.

Ask what happens when a payment succeeds at the processor and the response never reaches your system. The correct answer involves idempotency keys and reconciliation against the processor, because on draw night this will happen and a buyer who paid without receiving a ticket is a regulatory problem rather than a support ticket.

Ask them to describe the evidence pack the system produces for a completed draw. If they cannot list its contents, they are building an ecommerce checkout with a random number at the end.

Ask about load testing specifically, including what peak they will test to and how they will simulate it. Then settle ownership before kickoff: the repository, the cloud accounts and the right to hire anyone else should be yours in writing. At Digital Heroes the client owns the code from the first commit, which matters here because your licence obligations sit with your charity and your evidence needs to be reachable without asking a vendor's permission.