MerchantBridge Advisors / Licensed gaming operators / Payment-flow comparison
Licensed Gaming Payments: Compare Player Deposits, Withdrawals and Operator Settlement
Evaluate three flows separately: the player's deposit, the player's withdrawal and the provider's settlement to the operator. A working deposit method does not establish a supported withdrawal route, and money reaching the operator's bank is not necessarily available operating cash.
MerchantBridge can explore payment relationships for licensed gaming opportunities after the operator, permitted markets and requested functions are clear. Each provider must confirm its scope; a gaming license does not guarantee processing acceptance or support in every jurisdiction. MerchantBridge Advisors: Payment processing for licensed online gaming businesses
In this guide
Give each money movement its own requirements
| Flow | What it does | What the proposal must explain |
|---|---|---|
| Player deposit | Funds the player's gaming account through an approved method. | Who accepts it, who may use it, transaction status and when the player balance is credited. |
| Player withdrawal | Pays an entitled balance to the player through an approved route. | Destination checks, funding source, approval responsibilities, timing and failure handling. |
| Operator settlement | Moves provider-held proceeds to the operator's designated account. | Gross or net basis, deductions, currency, payout schedule and reconciliation. |
A refund of an original deposit is also different from a withdrawal of winnings or an accumulated player balance. Ask the provider which transaction type it supports rather than treating all money sent to a player as a refund. Describe the required function before discussing a method or integration logo.
Identify the contracting entity for each flow. If the cashier platform connects several providers, establish who holds funds, who pays players and who owns exceptions. A single interface can conceal several different contracts and funding arrangements.
Review the activity by country or state, not by website reach
Create a market-by-function map using the licensed entity, relevant permission, player location, deposit method, withdrawal destination and settlement account. List only the activity actually under review. A site being accessible in a country does not establish permission to serve it.
Great Britain's Gambling Commission condition 6.1.2 prohibits credit-card gambling payments for the licences within its scope, including payments made by credit card through a money service business. That is a concrete reason why a generic promise of card deposits is insufficient; debit and credit cannot be treated as interchangeable. Gambling Commission, Great Britain: LCCP condition 6.1.2: Use of credit cards
In the United States, the Federal Reserve's Regulation GG guide explains restricted-transaction controls and due-diligence examples for covered payment participants. A state licence can be relevant evidence, but neither the licence nor an international acquiring relationship removes the provider's review. The guide is longstanding explanatory material, not a new 2026 approval rule. Board of Governors of the Federal Reserve System: Regulation GG: A Small Entity Compliance Guide
- Confirm the exact licensed entity and permitted gambling activity.
- Separate existing markets from proposed expansion that has not yet been authorized.
- Ask each provider to confirm the specific deposit and withdrawal functions in each market.
- Identify dependencies on the cashier, gaming platform, bank and any payout provider.
- Keep unsupported functions visible instead of assuming another party will provide them.
Use a completed comparison that exposes the unanswered function
The following two arrangements are entirely fictional. Assume the same operator and permitted market are under review, with legal and provider approvals still to be confirmed. The table is not an offer, an actual partner comparison or evidence that a particular method is available.
| Requirement | Arrangement A | Arrangement B |
|---|---|---|
| Deposits | Provider proposes eligible deposits through the existing cashier. | Provider proposes eligible deposits through a new cashier connection. |
| Player withdrawals | Separate payout relationship required; destination support not yet confirmed. | Provider proposes withdrawals, subject to the market and beneficiary review. |
| Withdrawal funding | Operator must fund the separate payout account. | Proposed deduction from provider-held proceeds; shortfall funding terms unresolved. |
| Operator settlement | Deposit proceeds paid out after stated deductions. | Settlement also nets completed player withdrawals. |
| Reconciliation | Two provider reports must connect to one player ledger. | One provider report is proposed; event identifiers still need validation. |
| Decision blocker | Withdrawal coverage and prefunding arrangements remain open. | Netting authority, shortfall treatment and integration evidence remain open. |
Arrangement A is incomplete for an operator needing withdrawals unless the separate route is established. Arrangement B is not automatically better because it promises more functions. Its funding, reporting and integration claims need evidence. Compare the complete operating arrangement, including the cost of the unresolved pieces.
Reconcile the cash movements without calling them gaming revenue
Use this separate fictional U.S.-dollar accounting illustration. Assume $100,000 of completed deposits, $2,000 of processing costs, $5,000 temporarily restricted by the provider and $70,000 of completed player withdrawals, all in the same comparison period. The amounts and restriction are invented, with no other adjustments. They are not a reserve quote or a regulatory-funding calculation.
| Cash movement | A: withdrawals paid separately | B: withdrawals netted by provider |
|---|---|---|
| Deposits less fees and restricted amount | $100,000 - $2,000 - $5,000 = $93,000 | $93,000 before withdrawal netting |
| Player withdrawals | $70,000 paid from operator-funded payout account | $70,000 deducted before operator settlement |
| Provider settlement to operator | $93,000 | $23,000 |
| Combined cash movement after withdrawals | $93,000 - $70,000 = $23,000 | $23,000 |
The $5,000 restriction is treated here as temporarily unavailable funds, not a permanent fee. The $23,000 net movement is neither gross gaming revenue nor profit. It says nothing by itself about outstanding player balances, taxes, opening cash or the amount the operator is free to spend.
For a separate simplified player-ledger check, assume opening player balances of $20,000, the same $100,000 deposits, net player winnings credited of $5,000 and $70,000 withdrawals, with no other balance movements. Closing player balances are $55,000. This demonstrates why net bank receipts and player liabilities answer different questions; it does not establish compliance with any jurisdiction's required funding calculation.
New Jersey's published internet-gaming regulation, for example, requires a separate bank account and measures the required balance using specified player balances, funds on game and pending withdrawals. Apply the actual local rule with the responsible advisers rather than substituting the simplified example above. New Jersey Division of Gaming Enforcement: New Jersey Administrative Code, Chapter 69O: Internet and Mobile Gaming, section 13:69O-1.3(j)
Resolve withdrawal exceptions before launch
Map the path from a player's request through any required checks, provider instruction, successful delivery and ledger update. A status such as submitted or accepted should not be silently interpreted as received by the player. Ask how the system identifies a rejected, returned or duplicate instruction.
- What establishes that the destination belongs to the entitled player?
- Which rules govern returning funds to an original method versus using another permitted destination?
- Who handles closed accounts, expired cards, changed details or a method that cannot receive a payout?
- What happens when the payout account lacks funds or a banking cutoff is missed?
- How are partial, rejected and returned withdrawals reconciled and communicated?
- Which team owns the decision, escalation and audit record at each stage?
Great Britain's condition 17.1.1 requires identity verification before gambling and limits demands at withdrawal for information that could reasonably have been requested earlier, while preserving other legal obligations. Do not design unnecessary withdrawal friction as a substitute for earlier controls. This is a Great Britain example, not a universal timetable or a statement that all withdrawals can proceed immediately. Gambling Commission, Great Britain: LCCP condition 17.1.1: Customer identity verification
Test the events behind a settlement-speed claim
When a proposal says fast settlement, ask which clock it describes: deposit authorization, funds available to the provider, a bank payout instruction or receipt in the operator's account. For withdrawals, distinguish the operator's review time from the payment rail's delivery time. Record cutoffs, currencies, business-day assumptions and exception procedures.
Build an agreed test plan for a permitted environment. Include a failed deposit, a reversed event, a withdrawal rejected after submission, a duplicate notification and a reconciliation mismatch. The operator, provider and platform team should agree how the player ledger responds before relying on the integration.
Do not count test success as regulatory approval or promise a player-facing delivery time that the provider has not confirmed. Keep the reporting detailed enough to explain the transaction without circulating player identity documents, card data or confidential account records through a general inquiry.
Ask MerchantBridge to review the missing function
An operator with functioning deposits might need a withdrawal route, a different settlement arrangement or clearer reconciliation. Those are more useful opening questions than a request for a generic gaming processor. State the operator entity, permitted market, current platform and exact function you want evaluated.
MerchantBridge can explore whether available relationships offer a relevant next discussion. The first form should contain business and contact information, not player records, licensing-document bundles or payment data. Detailed requirements can follow through the appropriate review process. Acceptance, pricing, supported methods and timelines remain partner-specific. MerchantBridge Advisors: Payment processing for licensed online gaming businesses
Questions & answers
Does a deposit provider automatically support player withdrawals?
No. Confirm the withdrawal transaction type, destinations, markets, funding and integration separately. A refund capability alone may not meet the requirement.
Is the operator's settlement amount its gaming revenue?
No. Settlement reflects particular money movements and deductions. Player balances, gaming results, fees, taxes and other accounting items require separate reconciliation.
Does an existing licence guarantee acceptance in another country or state?
No. Establish the actual permission for each market and activity, then confirm the provider's willingness and ability to support it.
Can MerchantBridge promise instant withdrawals or a particular settlement currency?
No. We can explore relevant relationships and the required functions. Each provider must confirm supported destinations, currencies, timing, controls and contractual terms.
Your next step
Which gaming payment function needs a clearer route?
Request a Processing Review with your licensed operating model, permitted markets and the deposit, withdrawal or settlement requirement under review. MerchantBridge can explore a relevant partner conversation using business-level information.
Request a Processing Review