Casino cashier security testing: the test-case matrix

What a cashier-scoped pentest actually checks

A casino cashier penetration test verifies five things: that a deposit cannot be credited twice, that a withdrawal cannot be paid out twice or to an unauthorized destination, that the bonus engine cannot be gamed into paying out more than the promotion allows, that the cashier's APIs enforce the same authorization the web app does, and that privileged back-office actions are logged and cannot be self-approved. Below is the test-case matrix we scope against, category by category.

Who this is for

This is written for a CTO, Head of Security, or compliance lead who is about to sign a Statement of Work for a penetration test and wants to check whether "cashier" in the proposal means a named, tested asset or a line item nobody actually touches. It assumes you already know you want a pentest — if you're still deciding between vulnerability scanning and a full manual engagement, see vulnerability assessment vs penetration testing for iGaming first. It is not a walkthrough of how a credential-stuffing attack reaches the cashier (that's credential stuffing against casino cashiers), and it is not the full engagement scope, tiers, or pricing (that's scoping a penetration test for an online casino).

Why the cashier needs its own test-case list

A casino's cashier is not one feature — it is four separate subsystems (deposits, withdrawals, bonus/promotions, and the APIs and privileged tools that sit behind them) that a generic web-app pentest checklist was never written for. A tester who treats "the cashier" as a single login-and-click flow will verify that the pages render and the forms validate, and miss every finding that actually costs an operator money, because those findings live in what the system allows a valid, authenticated session to do — not in what breaks it.

That is also why automated scanners are structurally unable to help here. Pure-manual testing exists precisely because a scanner cannot know that a bonus should fire once per account, or that a withdrawal destination change should require re-authentication — it can only confirm that the endpoint returns a well-formed response. Every test case below is a business-logic question, not a signature match.

The test-case matrix

Deposits

Test case	What it verifies
Duplicate confirmation replay	A deposit-confirmation callback (from a payment processor or blockchain listener) cannot be replayed to credit the same deposit twice
Server-side amount validation	The credited amount is derived from the processor's or chain's confirmed value, not from a client-supplied parameter that can be tampered with in transit
Responsible-gambling deposit limits	Self-imposed or regulatory deposit limits are enforced at the API layer, not only in the UI form
On-chain confirmation depth	Crypto deposits require the configured confirmation count before credit, and a duplicate transaction ID cannot be resubmitted to credit twice

Withdrawals

Test case	What it verifies
Concurrent withdrawal race	Two simultaneous withdrawal requests against the same balance cannot both succeed
Step-up on destination change	Adding or changing a payout destination requires a re-authentication factor beyond the active session — the single highest-leverage control against account-takeover cash-out
Balance-boundary manipulation	Negative-value, overflow, or fractional-unit tricks cannot produce a withdrawal larger than the actual available balance
KYC/AML hold enforcement	A hold state set by compliance is enforced server-side on every withdrawal path, including any mobile or partner API route, not just the primary web flow

Bonus and promotions engine

Test case	What it verifies
Bonus ID replay	A bonus or promo code cannot be claimed a second time by the same identity through account recovery, session cloning, or a parallel signup path
Wagering-requirement integrity	Voided, cancelled, or refunded bets are excluded from wagering-requirement progress rather than counted toward it
Negative-value abuse	Bet types that can produce a near-guaranteed return (e.g. opposing bets across correlated markets) are excluded from bonus eligibility as designed, not just as documented policy
Cross-account bonus stacking	The same funding source, device, or identity signal cannot claim a "new player" bonus across multiple accounts undetected

Cashier APIs

Test case	What it verifies
Parity between web and partner/mobile APIs	Every authorization and rate-limit check enforced on the web cashier is also enforced on mobile-app and partner-integration API paths — the most common gap we find, because these paths ship faster than they're reviewed
Object-level authorization	Transaction, account, and withdrawal-request IDs cannot be enumerated or substituted to access another player's cashier data
Webhook signature validation	Inbound payment-processor callbacks are signature-verified and rejected if forged or replayed from outside the processor's published source
Session-scoped rate limiting	Cashier endpoints are rate-limited per account/session, not only per IP — a botnet on residential proxies defeats IP-only limits

Privileged access and back-office

Test case	What it verifies
Self-approval prevention	A support agent or back-office user who flags a withdrawal for manual review cannot also be the one who approves it
Privileged-action audit trail	Every manual credit, debit, KYC override, and withdrawal approval is logged with an identity, a timestamp, and a reason — logs a regulator or investigator can actually use
Session hijack resistance	Back-office and admin sessions cannot be replayed or hijacked from a stolen token after the operator's normal session-timeout window
Least-privilege enforcement	A role scoped to "view KYC status" cannot also execute a cashier override — role boundaries are tested, not just documented

Testing money movement without breaking it

Cashier testing carries a constraint most web-app pentests don't: every test case above touches a system that moves real funds, so "just fuzz it in production" is not an acceptable methodology. In practice this means three things get fixed before testing starts, as part of the Rules of Engagement rather than left to the tester's judgment mid-engagement:

• Test accounts with real balances, not production accounts. Deposit and withdrawal test cases run against seeded test-tier accounts (or a staging environment with a mirrored payment-processor sandbox) so a race-condition or replay finding never risks an actual player's funds.
• A capped blast radius for privileged-access tests. Back-office and admin test cases target a scoped set of test identities, with the client's compliance or ops lead on standby to confirm nothing outside scope moved.
• A named stop condition for anything ambiguous. If a test case's outcome is unclear — did that request actually credit an account, or just return a 200 — testing pauses and the client confirms before continuing, rather than the tester guessing and moving on.

None of this slows the engagement down materially; it is the same signed-RoE discipline that governs any AnySec pentest, applied to the specific risk profile of a system that handles money instead of just data.

What you get back

A cashier-scoped pentest deliverable follows the same report structure as any other AnySec engagement: an executive summary in business terms, chained-exploit narratives where multiple medium findings combine into a critical cashier impact, developer-reproducible steps, and remediation guidance mapped to each failed test case above. Pricing follows the same Penetration Testing engagement tiers — cashier testing is scoped as part of a Focused, Standard, or Continuous engagement rather than sold as a separate product, starting at €2,499 for a single-target Focused engagement.

Limitations

This matrix does not cover the platform's game-engine RNG fairness (that is a certification/audit function, not a pentest one), and it does not replace regulatory KYC/AML audit requirements your license already mandates — a pentest tests whether your technical controls enforce your policy, not whether the policy itself satisfies your regulator. It also does not include exploit payloads or reproduction commands here; those live only in the signed-off engagement report delivered under Rules of Engagement, never in public content.

What to check before you sign

Ask your vendor to name the cashier, bonus engine, and privileged back-office as scoped assets in the Statement of Work — not folded into "web application testing" — and ask which of the categories above they intend to cover. If the answer is vague on any of the five, the scope is not actually cashier testing yet. Submit your scope and we will map it against this matrix before you sign anything.

Sources

Test-case categories reflect AnySec's own Penetration Testing methodology and publicly documented iGaming payment-fraud patterns (deposit/withdrawal abuse, bonus engine exploitation) referenced in industry gaming-compliance literature. No client-specific data is used in this article.

---

Related reading

• Scoping a penetration test for an online casino — the full engagement scope, Rules of Engagement, tiers, and pricing this test-case matrix fits inside.
• Credential stuffing against casino cashiers — the attack chain that the step-up-authentication and cross-signal test cases above are built to catch.
• Why we still do pure-manual penetration testing — why business-logic flaws like bonus replay and withdrawal races are invisible to automated scanners.