BetAlice appears to be operating without visible operator disclosure while remaining accessible across multiple domains despite Italian blackouts on some URLs. Our payment-rail review found a familiar offshore-casino stack: ChainValley behind cashier-branded methods (including Skrill/NETELLER labels), and an open-banking route layered through payment-gateway.io → puretransfer.io → mellifera.tech, with Paradis Tech Ltd shown as payee and Yapily/Wise Open Banking references in the flow.
Key Findings
- No transparent operator disclosure was identified on the reviewed BetAlice domains (
www.betalice.com,betalice-1110.com), despite active onboarding of users from multiple EU jurisdictions and the UK. - Italian blocking/blackout measures appear incomplete or easily bypassed, as alternative BetAlice domains remain reachable.
- BetAlice offers mainstream rails (cards, bank transfer, PaysafeCard, crypto) typical of offshore casino cashier setups targeting broad retail users.
- ChainValley (Poland) appears behind cashier methods labeled PaysafeCard, Skrill, NTLR, reinforcing prior indications that ChainValley functions as a successor scheme to the formerly used utPay / UTRG UAB (Lithuania) in offshore-casino payment routing.
- In December 2025, BetAlice reportedly still showed utPay as processor in parts of the payment flow, suggesting migration overlap or dual-routing during transition.
- The bank-transfer route is a layered open-banking path:
api.payment-gateway.io→checkout.puretransfer.io→pay.clx.acq.mellifera.tech(Yapily method) → Wise Open Banking endpoints. - Paradis Tech Ltd appears as the payee in the open-banking flow.
- The Mellifera payment pop-up (terms/privacy) identifies Mellifera Kartiera Limited (Malta) as operator and references kartiera.eu and claimed MFSA EMI regulation (per your captured disclosures).
- The Mellifera gateway UI references Yapily as payment method, but the current operational role split between Mellifera and Yapily requires further verification (technology provider vs. active PISP routing vs. legacy label).
- Prior Puretransfer analysis and Jan 2026 traffic signals indicate a tight Puretransfer ↔ Mellifera linkage, with Mellifera traffic referred via Puretransfer, consistent with a specialized casino-payment funnel.
Compliance Analysis
1) Starting Point: Illegal Offer / Unlicensed Gambling Exposure
The compliance assessment must begin with the status of BetAlice itself. Based on your test results, BetAlice was accessible and open to registrations from the EU and UK, despite domain blackouts in Italy and without clear operator transparency on the site. For a gambling business targeting or accepting customers in regulated European jurisdictions, missing operator disclosure + cross-border onboarding + domain hopping are strong red flags.
That matters because payment facilitators in the chain are not just technical vendors in a vacuum. If they enable deposits for an unlicensed casino scheme that is actively onboarding restricted users, they may create AML, sanctions-screening, gambling-law, and conduct risk exposure—especially where they provide scalable rails such as cards or open banking.
Behind Skrill Payment Rail Rapid Transfer, we discovered Novaforge as the payment recipient. In this respect, it is only logical to name Novaforge as the operator of BetAlice.
2) ChainValley Pattern: Continuity After utPay
The findings place ChainValley behind multiple cashier labels (PaysafeCard / Rapid / Skrill / NTLR) at BetAlice. This mirrors a pattern seen across offshore-casino cashier environments where front-end payment labels suggest familiar consumer methods, while the actual routing is handled by an intermediary gateway operator.
The significance here is the continuity hypothesis: after the suspension of UTRG UAB dba utPay (Lithuania), ChainValley appears to have taken over the same functional niche for offshore casino deposit routing. The fact that utPay still appeared at BetAlice in Dec 2025 strengthens the case for a migration/hand-over period rather than a clean break.
3) Open-Banking Rail: Layering, Obfuscation, and Responsibility Splitting
The bank-transfer route you documented is especially important from a compliance perspective because it shows multi-layer gateway orchestration:
- front/API layer (
payment-gateway.io) - checkout abstraction (
puretransfer.io) - acquiring/open-banking routing (
mellifera.tech, Yapily-labeled) - final bank/Open Banking execution layer (Wise Open Banking references)
- named payee (Paradis Tech Ltd)
This kind of architecture can be legitimate in e-commerce, but in the offshore-casino context it raises the classic question: who is merchant-facing, who is payment-institution-facing, and who performs effective merchant due diligence?
Where the end merchant is an unlicensed gambling operator, layered routing can create plausible deniability by fragmentation unless the PSP/EMI/PISP chain applies strong controls (merchant category screening, geofencing enforcement, transaction monitoring, adverse-media triggers, and rapid termination procedures).
4) Mellifera Kartiera (Malta):
The evidence indicates that the Mellifera gateway pop-up names Mellifera Kartiera Limited (Malta) and claims EMI regulation by the MFSA (effective 20 Nov 2024). If confirmed, this is highly material because:
- an EMI-linked open-banking/acquiring interface appearing in an offshore-casino deposit flow raises regulatory perimeter and onboarding-control questions, and
- the presence of a regulated entity’s terms/privacy in a payment pop-up may increase user trust while the underlying gambling merchant appears unlicensed in target jurisdictions.
The key compliance question is not only whether Mellifera is regulated, but what exact service is being provided in this flow:
- regulated EMI/payment service directly to the merchant,
- technical gateway/software layer,
- outsourced/acquiring facilitation, or
- white-label/legacy integration where labels (e.g., Yapily) remain visible but operational roles changed.
5) Yapily / Wise / Paradis Tech:
The captured URL parameters and flow references suggest a Yapily-labeled payment method and Wise Open Banking API interaction, with Paradis Tech Ltd shown as payee. This is precisely the type of setup that requires transaction-level evidence and provider-side clarification:
- Is Yapily directly serving the merchant chain, or merely referenced in a legacy parameter/UI label?
- Is Wise’s Open Banking infrastructure being used via a licensed intermediary, and if so, under what merchant acceptance rules?
- What is the legal/regulated status and role of Paradis Tech Ltd in the fund flow (merchant of record, collection agent, settlement beneficiary, or separate processor)?
Paradis Tech’s public site presents it as a “payment solution” provider offering tools to accept payments and manage online business globally, as well as advisory services and fraud‑detection technology. While it does not explicitly market gambling payments, the observation that Wise Open Banking payments show “Paradis Tech Ltd” as the payee indicates that Paradis Tech is acting as a receiving and routing layer, likely as an MSB or similar regulated entity in its home jurisdiction.
When such an MSB becomes a named beneficiary for flows that are in fact unlicensed gambling deposits, this raises:
- UBO/merchant transparency concerns (end‑beneficiary BetAlice is hidden).
- Potential breaches of scheme/network rules and local gambling/payment regulations.
- AML/CFT risks, as source of funds and purpose of payments are obfuscated.
Summary Table — BetAlice Scheme & Payment Rails (Working Compliance Map)
| Brand / Component | Domain / Identifier | Legal Entity (Observed / Suspected) | Jurisdiction | Regulatory Situation (Observed / Claimed) | Role in Flow |
|---|---|---|---|---|---|
| BetAlice Casino | www.betalice.com; betalice-1110.com | Novaforge | Unclear | Appears unlicensed for UK/EU targeting; Italian blackouts on some domains but accessible via alternatives | Offshore casino frontend / merchant origin |
| BetAlice (cashier labels) | PaysafeCard / Rapid / Skrill / NTLR (cashier options) | Routed via ChainValley (per review findings) | Poland (ChainValley) | Needs deeper verification of licensing/permissions for gambling-related routing | Deposit method presentation / routing via gateway layer |
| ChainValley | chainvalley.pro (dba ChainValley) | Chain Valley Sp. z o.o. (reported) | Poland | Public positioning and regulatory perimeter require further verification; linked by FinTelegram to offshore-casino routing | Successor-style payment gateway / processor role |
| utPay (legacy / overlap) | (Previously used in BetAlice flow in Dec 2025) | UTRG UAB dba utPay | Lithuania | Previously registered VASP; user notes suspension context | Legacy crypto/payment gateway; possible predecessor to ChainValley routing |
| Payment API layer | api.payment-gateway.io | Unknown | Unknown | Unknown | API orchestration layer in bank-transfer route |
| Checkout gateway | checkout.puretransfer.io | Puretransfer-related operator (to verify) | Unknown | Repeatedly observed in offshore-casino gateway context (per prior FT analyses) | Checkout / routing intermediary |
| Mellifera gateway | pay.clx.acq.mellifera.tech | Mellifera Kartiera Limited (per pop-up T&Cs/privacy) | Malta | Claims MFSA EMI regulation (as stated in gateway materials / kartiera.eu); independent confirmation recommended | Open-banking/acquiring/payment interface layer |
| Kartiera | kartiera.eu | Mellifera Kartiera Limited | Malta | Claimed regulated EMI status (user-captured disclosure) | Corporate / regulated-facing website for Mellifera |
| Yapily (method label) | paymentMethod=yapily in Mellifera flow | Yapily entity/entities (to verify involvement) | UK/EU | Role unclear from capture alone (active provider vs legacy method label) | Open-banking payment method label / possible integration |
| Wise Open Banking | wise.com/openbanking / transferwise.com/openbanking references | Wise group entities | UK/EU | Regulated provider(s), but role in this merchant chain requires transaction-level clarification | Open-banking infrastructure / API layer |
| Paradis Tech Ltd (payee) | Payee shown in payment flow | Likely Paradis Tech (user indicates Canadian MSB hypothesis) | Canada (to verify) | MSB status and exact entity match require confirmation | Payee / settlement beneficiary in bank transfer flow |
Compliance Takeaway
BetAlice is a textbook example of why payment-rail reviews must start with the legality of the merchant. Once the casino itself appears to be an unlicensed, cross-border operator using domain rotation and incomplete blocks, every downstream rail—cards, e-wallet labels, crypto gateways, and especially open-banking chains—becomes a compliance-risk transmission channel.
The most important outcome of this review is not a single processor name, but the repeatable architecture:
- offshore casino frontend
- branded cashier labels
- processor/gateway abstraction (ChainValley / Puretransfer)
- regulated-facing or quasi-regulated payment layer (Mellifera / Yapily-labeled)
- bank/Open Banking infrastructure (Wise references)
- payee entity (Paradis Tech Ltd)
This architecture should be added to the FinTelegram Rail Atlas as a high-priority pattern for further testing, screenshots, transaction sampling, and provider-right-to-reply outreach.
