05.04 Casino Payment Context

Status: draft for discussion

1. Goal

This document describes the business context that matters because the product is a white-label payment orchestrator for casino deposits.

It does not define a database schema.

2. Casino Operator Context

The merchant can represent a casino operator or white-label operator.

The merchant can have several brands.

Each brand can represent a casino site or product line.

Payment methods are configured inside brand because different brands may need different payment availability, routing, and customer experience.

3. Player Context

The customer in the payment flow is the casino player.

The system should store enough customer context to support routing, velocity limits, provider execution, and investigation.

Business-relevant customer context can include:

• customer/user reference from merchant;
• email;
• country;
• IP;
• address;
• city;
• payment account reference when received from provider;
• attributes required by selected execution option.

Exact field names and validation are proposed by the development team.

4. Payment Method Context

Payment methods should be specific and business-readable.

Examples:

• Cards;
• Apple Pay;
• Google Pay;
• Sofort Uber;
• BLIK;
• Skrill;
• Neteller;
• Paysafecard;
• crypto;
• open banking;
• bank transfer;
• local payment methods by country.

APM should not be used as a generic customer-facing method.

If a method is important for casino deposits, it should be modeled as a concrete payment method.

5. Risk and Conversion Context

Casino deposits need both conversion and control.

The product should help balance:

• allowing successful deposits to go through quickly;
• trying fallback when provider path fails;
• stopping traffic when velocity limits reject an option;
• keeping the customer experience simple;
• giving support enough visibility to explain the result;
• hiding sensitive provider details from merchant users without access.

Anti-fraud/manual review is not part of MVP, but the system should not block future risk features.

6. Brand-Level Configuration

Brand-level payment method setup is important because:

• brands can operate in different markets;
• brands can have different available methods;
• brands can have different routing;
• Hosted Payment Page receives brand context;
• migrated transactions must be assigned to a specific brand.

7. White-Label Expectation

The product should support multiple merchants and brands without making Back Office confusing.

Users should always understand which merchant and brand context they are working in.

The UI should avoid exposing platform-internal or provider-internal information to users who should not see it.