Player accounts & wallet
Give every entry somewhere to live.
A customer account brings together the relationship between the player and the operator. Entries. Results. Wallet. Spending controls. Account status.
Beaver keeps those things attached to one customer record rather than spreading them across unrelated tools.
Account basics
Start with a real account.
Live Current account functionality includes:
- Registration with a date of birth age gate
- Login, logout and password reset
- Entry history
- Competition results
- Wallet balance
One player. One record.
-
Show the customer what they actually entered.
Every entry can be associated with the relevant competition and ticket number in the player's account. That gives the customer a clear record rather than relying entirely on email receipts.
-
Bring the outcome back to the customer.
The account can show live and past competition results relevant to the tickets that customer holds. This ties naturally into public draw verification.
Wallet
Treat money as money.
The Beaver wallet stores balances using integer minor units rather than floating point values.
Behind the displayed balance sits an append only ledger. Every movement records a reason and a running balance. The balance is derived from those movements rather than somebody simply editing the number.
The balance is the result of the record. Not the other way around.
| Movement | Reason | Amount | Balance |
|---|---|---|---|
| 1 | Top up | +2000 | 2000 |
| 2 | Entries purchased | −1500 | 500 |
| 3 | Refund, cancelled order | +500 | 1000 |
Amounts in pence, stored as whole numbers. The balance is derived from the movements.
Illustration with example movements.
-
Promotional credit
Keep promotional value separate.
Built
A promotional credit account separate from cash, with its own expiry behaviour. Operators can distinguish cash from promotional value rather than pretending every balance movement is the same thing.
-
Withdrawals
Withdrawal rules belong in the platform.
Built
The design includes minimum thresholds and the ability to trigger KYC related requirements above configured amounts.
Not yet used against real payment infrastructure, so we do not describe it as proven production behaviour.
Protection on the account
Controls that follow the account, not the browser session.
| Capability | Status | What that means |
|---|---|---|
| Player set monthly spend limit | Live | Set by the player, enforced at checkout. |
| Operator platform cap | Live | A ceiling the customer cannot exceed. |
| Cooling off on limit increases | Built | A raise does not take effect immediately. |
| Take a break | Live | A genuine stop state on the account. |
| Self exclusion | Live | Designed to survive re registration. |
| Marketing suppression on a care flag | Live | The campaign does not outrank the account state. |
| Closed account marketing stop | Live | No marketing, except contact required about a prize still owed. |
| Channel preferences (email, SMS, push, on site) | Built | Independent preferences per channel. |
| In product data export and deletion | Built | Player level data rights workflows. |
Live proven on the deployed platform. Built in the product with passing tests, not yet proven with live customers. Roadmap planned, not a working feature.
Closing the tab is not player protection.
