For iGaming operators managing player withdrawals, closed-loop redemption policies are not optional fine print. They are enforceable card scheme rules that, if ignored, can result in chargebacks, fines from acquiring banks, and potential loss of merchant accounts. Understanding what these policies mean and how they apply to your payment flows is a foundational compliance requirement.
What Is Closed-Loop Redemption?
Closed-loop redemption refers to the principle that funds deposited by a player using a specific payment method must be returned to that same method, up to the original deposited amount, before any alternative payout route is used. If a player deposited 200 EUR via a Visa debit card, the first 200 EUR of any withdrawal must be credited back to that same card. Only the portion exceeding the original deposit amount, representing winnings, may be redirected to a different instrument such as a bank transfer or e-wallet.
The term "closed loop" describes the financial circuit: money enters through one defined channel and must exit through the same channel. The loop is closed, not open-ended.
Why Card Schemes Enforce This Rule
Visa and Mastercard introduced closed-loop redemption requirements primarily to combat money laundering and to protect cardholders. Without such rules, a bad actor could deposit funds onto a gambling account using a stolen card, then withdraw those funds to a different, clean payment instrument, effectively converting illegitimate money into untraceable cash. Closed-loop redemption breaks this cycle at the payment-processing layer.
Beyond AML concerns, the schemes also use this rule to prevent what they classify as "cash advance" transactions. When an operator pays out winnings directly to a card without a corresponding inbound transaction, some scheme frameworks flag this as a quasi-cash disbursement, which attracts higher interchange fees and additional scrutiny. Returning funds to the original deposit card avoids this classification.
How the Rule Applies in Practice
Operators need to build payment reconciliation logic that tracks, per player and per payment method, the outstanding deposit balance available for return. Consider this operational sequence:
- A player makes three deposits: 100 EUR by Visa, 50 EUR by Mastercard, and 150 EUR by bank transfer.
- The player requests a withdrawal of 400 EUR after a winning session.
- The payment system must first return 100 EUR to the Visa card, then 50 EUR to the Mastercard, then 150 EUR to the bank account.
- The remaining 100 EUR in winnings can be sent via any approved method in your cashier.
This matching logic must survive edge cases: expired cards, closed accounts, or scheme-imposed refund time limits (typically 365 days for Visa and a similar window for Mastercard). When a return-to-source cannot be completed, operators must document the reason and follow a defined fallback procedure, often a manual bank transfer accompanied by supporting KYC evidence.
Scheme Differences Operators Should Know
Visa and Mastercard share the same underlying philosophy but differ in certain operational details. Mastercard's framework uses the concept of an "original credit transaction" (OCT) for gambling payouts and requires that OCTs not exceed the original deposited amount per transaction cycle. Visa's complementary mechanism is the "funds disbursement" transaction type, which has its own merchant category code requirements for licensed gambling operators. Your acquiring bank should provide scheme-specific documentation, but operators should not rely on acquirers alone to configure these flows correctly.
Implications for Operators and Their Tech Stack
Practically speaking, closed-loop compliance demands the following capabilities from your payment infrastructure:
- Persistent storage of deposit method data linked to individual player accounts, including masked card identifiers and transaction references.
- Automated matching logic that calculates how much of any withdrawal request must be returned to each source instrument.
- Clear player-facing messaging explaining why withdrawals are routed to their original deposit method, to reduce support contacts and chargebacks.
- An auditable exception-handling workflow for cases where return-to-source fails, with documentation suitable for AML record-keeping.
Closed-loop redemption is where payments compliance and AML policy converge. Operators that treat it as a technical afterthought rather than a core cashier design principle are building avoidable regulatory and financial risk into their platform from day one.
Where OnlineShine Fits In
At OnlineShine, we work with operators at the cashier design stage to map payment flows against scheme rules before a platform goes live. Getting this architecture right early avoids costly remediation later, whether that means reconfiguring payment provider integrations, rewriting player communications, or responding to acquirer audits. If you are launching or replatforming, closed-loop redemption policy alignment should be on your pre-launch checklist alongside licensing and KYC configuration.
