> For the complete documentation index, see [llms.txt](https://docs.hyperswitch.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hyperswitch.io/integrations/cashier-payments/overview.md).

# Overview

Juspay's iGaming Suite is a composable payments stack built for the operational realities of iGaming operators - high-frequency deposits, regulated jurisdictions, closed-loop withdrawals, and a relentless push for faster, smoother cashier experiences.

This section walks through the features that matter most for iGaming merchants: a smarter 3DS engine that protects fresh cards while letting trusted card-on-file deposits fly through, real-time card eligibility checks that fail fast at the BIN level, regulatory tooling for the UK, Germany, and Canada, a cashier that adapts to each operator's brand and player base, and an intelligent withdrawal engine that optimizes for payout success rate and cost - within the closed-loop constraints set by AML rules.

Unlike most platforms in the space that ask merchants to migrate their entire stack, the iGaming Suite is modular and self-hostable. Use the whole stack, or adopt a single component and keep your existing wallet, fraud, cashier, and ledger integrations exactly where they are.

### Cashier Payment Constraints

Cashier payments don't behave like the verticals most payment stacks are tuned for. E-commerce optimizes for one-off purchases at variable ticket sizes. Travel optimizes for high-value, low-frequency bookings with complex post-purchase events. Subscriptions optimize for predictable, low-frequency recurring charges. The cashier inverts all three: deposits are high-frequency and low-ticket, withdrawals are constrained by AML rather than free, withdrawal success rate is a public-facing marketing metric, and the card-on-file pattern dominates volume to a degree most general-purpose platforms never plan for. On top of that, the regulatory ceiling is set by financial-services rules - not retail.

<table><thead><tr><th>Constraint</th><th>What it means for payments</th><th data-hidden></th></tr></thead><tbody><tr><td>High deposit frequency, low ticket size</td><td>Friction per transaction compounds. A small percentage drop-off on 3DS challenge can materially impact deposit conversion at scale.</td><td></td></tr><tr><td>Closed-loop withdrawals (AML)</td><td>Funds can only be returned to the original deposit source. Withdrawal routing is constrained, not free.</td><td></td></tr><tr><td>Jurisdiction-specific bans</td><td>UKGC bans credit cards for gambling. German GlüStV 2021 mandates player-name verification on certain APMs. Canadian Interac transactions require player-name relay.</td><td></td></tr><tr><td>Player-name verification</td><td>Many regulated markets require the depositor’s name to match the bank account holder’s name.</td><td></td></tr><tr><td>Reputation cost of failed withdrawals</td><td>Slow or failed payouts directly drive player churn and public complaints. Withdrawal SR is a marketing metric.</td><td></td></tr><tr><td>High-risk BIN exposure</td><td>Gaming attracts higher-than-average rates of prepaid, virtual, and high-risk-BIN traffic that have low approval probability and elevated chargeback risk.</td><td></td></tr><tr><td>Card-on-file dependency</td><td>Most active players store their card. The COF transaction is the dominant volume; the fresh-card transaction is the higher-risk minority.</td><td></td></tr></tbody></table>

These aren't edge cases - they're the design parameters every cashier payment decision lives inside. The seven constraints below describe what a cashier payment stack must solve for, and the rest of this document is organized as a response to them.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.hyperswitch.io/integrations/cashier-payments/overview.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.