A ticket purchase looks like one click. Behind that click there are at least three separate companies involved, a banking relationship that took months to set up, and a set of reporting obligations to the Department of Internal Affairs that have to line up exactly, every single draw. Most charities have never had to think about any of this, because most charities have never run a licensed online lottery before. It's worth understanding why it's genuinely complicated, and why that complexity is exactly the problem Swell exists to take off a partner charity's plate.
Layer one: the bank
Every online lottery needs a merchant agreement with a bank willing to accept the money. Gambling sits in its own risk category, and every major New Zealand bank treats it that way. Getting approved means proving the DIA licence is real, proving who the directors are, showing financial projections, and often accepting that a slice of each settlement is held back for a period as a buffer against disputes. None of that is quick. It's a credit and underwriting process, not a software setup, and it has to start well before a single ticket goes on sale.
Once approved, money doesn't land instantly either. Settlement typically takes a business day or two, and a charity running its first lottery, with no track record, can expect more scrutiny and slower settlement than an established operator would get.
Layer two: the payment gateway
Sitting between the checkout page and the bank is the gateway: the piece that actually takes the card details, checks for fraud, and passes the payment through for approval. How that checkout is built determines how much security compliance the organisation running it has to carry. A simple hosted payment page keeps that burden light. A custom-built checkout that handles card numbers directly pushes it up considerably, with real ongoing audit obligations attached.
Layer three: the fees underneath
Every card payment actually stacks three separate charges: a fee to the customer's own bank, a fee to Visa or Mastercard, and a margin for whoever's running the gateway. Charities negotiating this for the first time are usually quoted one blended number that hides which part is actually negotiable. It's worth knowing that only one of those three pieces moves.
There's a second problem no amount of negotiating fixes. Some banks let their own customers switch off gambling-related transactions on their card as a safety feature. When that's on, a perfectly legitimate charity lottery ticket gets silently declined, and it has nothing to do with the charity's bank, gateway or website. The only real answer is offering a second way to pay that doesn't touch a card at all, Online EFTPOS, where the customer approves the payment inside their own banking app.
Layer four: proving it to DIA
None of the above matters if the money can't be reconciled back to exactly what the licence requires. A licensed Class 3 lottery has to keep proceeds identifiable, produce an independently audited prize statement within three months of the draw, and account for every dollar against its authorised purpose. Get the banking and payment setup right but the reconciliation wrong, and the compliance risk is just as real.
Why this matters for a partner charity
Add it up and a charity attempting this alone is looking at a bank underwriting process measured in months, a technical integration decision that sets its compliance burden for years, a live risk that a chunk of its potential buyers get silently declined through no fault of its own, and a reconciliation process that has to satisfy an audit, all before it has raised a single dollar for its cause.
The unglamorous plumbing is the whole point. It's also the reason it's worth having someone else build it once, properly, rather than every charity solving it separately. It's a large part of why we built Swell in the first place.