What the BSP memo actually says
- The suspension was approved by the Monetary Board via Resolution No. 805 dated 14 August 2025.
- BSP approved the suspension of in-app gambling access from BSP-supervised institutions’ mobile payment apps and websites.
- The suspension is pending issuance and implementation of the policy that sets standards and expectations for BSP-supervised institutions in providing online gambling payment services.
- Therefore, all BSP-supervised institutions were instructed to remove links that provide in-app gambling access within 48 hours upon issuance of the memorandum.
- “In-app gambling access” includes any product/service that redirects an account holder to a gaming/gambling site.
What “BSP delinking” means in plain language
- It is about in-app access links inside payment apps and websites.
- It is not written as a blanket statement that “all e-wallet payments to gambling are banned.” Instead, it suspends in-app access and signals a broader policy is coming for online gambling payment services.
However, in practice, payment providers may tighten risk rules at the same time. So, even if the memo targets links, your deposit success rate can still drop due to policy enforcement across the funnel.
Why deposits start failing after delinking
1) Your “entry point” disappears
Many players used to start from the wallet:
- Wallet app → casino tile → operator page → deposit prefilled
If that tile/link is removed, the user never reaches your deposit screen. As a result, your conversion looks like “deposit failed,” but it’s actually a journey broken earlier.
2) Redirect flows get blocked or look suspicious
Some cash-in journeys rely on:
- embedded webviews
- deep links
- in-app redirects that resemble “wallet → gambling access”
Since the memo defines in-app gambling access as a redirect to a gambling site, those patterns become high-risk.
3) Users lose trust when the UI suddenly changes
When users don’t understand what changed, they assume:
- the operator is shady, or
- the wallet is “not safe,” or
- the deposit will get stuck
So, they stop trying.
4) Deposit support load spikes
Then support tickets explode:
- “Money deducted but no credits”
- “Pending for hours”
- “No option for GCash/Maya anymore”
- “Where is the casino section?”
If you don’t have clean audit trails and status codes, disputes get expensive.
The fix: a compliant deposit playbook for casino apps
This section is written for product, payments, and engineering teams. Still, it stays practical.
Step 1: Map your current deposit journey end-to-end
First, list every path a user takes to deposit:
- From a wallet app?
- From your app lobby?
- From a browser landing page?
- From an affiliate or CRM link?
Then, tag each step by dependency:
- Operator-controlled (your UI, your API calls)
- Wallet-controlled (wallet menus, wallet landing pages, wallet webviews)
- PSP-controlled (hosted pages, redirect handlers, OTP screens)
After that, you’ll see exactly which steps can vanish due to “link removal.”
Step 2: Remove wallet-dependent “access” assumptions
If your conversion relies on:
- wallet “casino” menu visibility
- wallet-hosted operator directories
- wallet internal redirects to gambling pages
treat it as non-reliable from now on.
Instead, shift acquisition and deposit initiation into channels you control:
- your own app deposit button
- your own deposit landing page
- direct navigation + verified links
This keeps you aligned with the memo’s direction on removing in-app gambling access links.
Step 3: Rebuild deposit UX with clear user choices
Now, redesign the deposit screen around clarity:
A. Start with a “Pick your method” screen
Use simple tiles like:
- E-wallet
- Bank transfer
- Card (if allowed)
OTC / cash channels (if supported)
B. Then show a “What happens next” mini-flow
Users hate surprises. So, tell them:
- “You’ll be redirected to authorize payment.”
- “You will return to the app after approval.”
- “Credits may take up to X minutes.”
C. Add a fallback path
If e-wallet fails, offer:
- bank transfer with reference code
- OTC with generated barcode/reference
- alternate provider rail (where compliant)
This reduces drop-offs, and it reduces support tickets.
Step 4: Implement payment-safe engineering patterns
Even if policy is the trigger, the technical fixes decide your survival.
Use these patterns:
1. Idempotency keys for deposit creation
So, double taps don’t create duplicate deposits.
2. Status codes that match reality
For example:
- INITIATED (deposit created)
- AWAITING_AUTH (wallet authorization pending)
- PROCESSING (provider accepted, waiting confirmation)
- SUCCESS / FAILED
- REVERSED (refund/chargeback/void)
- EXPIRED
3. Webhook + poll fallback
Some providers miss callbacks. Therefore:
- accept webhook events
- also poll by transaction reference for a short window
4. Reconciliation job every X minutes
This catches “money deducted, no credits” cases.
5. User-visible receipt
Show:
- amount
- fee (if any)
- reference ID
- timestamp
- status
- support CTA
That “proof” is what dispute teams need later.
Step 5: Add “delinking-aware” monitoring
Treat this like an incident class.
Track these metrics daily:
- deposit attempt rate
- success rate by method
- fail rate by provider response code
- average time to success
- pending > X minutes count
- dispute rate per 1,000 deposits
Also, alert on sudden shifts:
- e-wallet success drops 20% day-over-day
- pending deposits spike
- refunds spike
What to tell users when deposits fail
Players don’t care about policy language. They care about what to do next.
So, add a short “Deposit help” section in-app:
- “If your wallet option is missing, choose another method on screen.”
- “If you were charged but not credited, don’t retry immediately.”
- “Instead, save your reference ID, contact support from this button.”
- “Most pending deposits resolve within X minutes.”
Keep it calm. Also, keep it specific.
Why GCash removed casino links
If you notice casino links disappear inside GCash (or other wallets), the simplest explanation is compliance with BSP’s instruction to remove links that provide in-app gambling access within 48 hours. In other words, wallets may remove menus, tiles, or directories that redirect users to gambling sites because that redirect behavior is explicitly covered by the memo’s definition.
Operator checklist: what “good” looks like after delinking
Your deposit flow is in a better place when:
- Users can start a deposit from your app in under 2 taps
- Every deposit has a reference ID visible to the user
- Pending deposits auto-reconcile without manual support work
- Failures show plain reasons and next actions
- Support can pull complete logs fast
Conclusion
BSP delinking has made wallet-dependent casino deposit flows unreliable by design. To recover conversion and stay compliant, operators must fully own their deposit journey, remove dependence on wallet-side casino links, and rebuild payments with clear UX, fallbacks, and strong reconciliation. SDLC Corp helps iGaming operators do exactly this by redesigning compliant deposit flows, integrating wallet-agnostic payment rails, hardening payment logic, and setting up monitoring that prevents silent revenue loss when policies shift.
FAQs
Are e-wallets ordered to unlink from online gambling?
BSP’s memo instructs BSP-supervised institutions to remove links that provide in-app gambling access in their mobile payment apps and websites.
So, it is specifically about in-app access/redirect links, as defined in the memo.
What is the BSP 48 hours?
It refers to the compliance window. BSP instructed BSP-supervised institutions to remove those in-app gambling access links within 48 hours upon issuance of the memorandum.
What is the BSP memo for gambling?
For this issue, it’s Memorandum No. M-2025-029, titled “Suspension of In-app Gambling Access in Mobile Payment Apps and Websites.”
It suspends in-app gambling access and orders removal of the relevant links.
Why did GCash remove online casinos?
Most likely, it’s to comply with BSP’s instruction to remove in-app links that redirect users to gambling sites, since that redirect behavior is included in the memo’s definition of “in-app gambling access.”
Does BSP delinking stop all casino deposits?
No. The BSP memo targets in-app gambling access links inside payment apps and websites. However, deposit success can still drop because payment providers may tighten rules and remove casino entry points at the same time.
What is “in-app gambling access” according to BSP?
It includes any product, service, or feature that redirects an account holder to a gaming/gambling site from inside a payment app or website. This definition is the core reason wallet casino links were removed.
How can casino apps reduce deposit drop-offs after delinking?
First, stop relying on wallet “casino” directories or tiles. Then add a fallback ladder inside your deposit flow, show clear error reasons with next steps, and log every attempt with a reference ID. As a result, users retry correctly and support resolves issues faster.
Until when will the suspension stay in place?
BSP said the suspension remains until it finalizes the policy standards for BSP-supervised institutions that provide online gambling payment services. So, operators should treat the current state as ongoing and design deposits to work without wallet-side gambling links.
