05.04 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 deposits across the casino, online business, and payment processors market.

It does not define a database schema.

2. Operator Context

The merchant can represent an operator or white-label operator.

The merchant can have several brands.

Each brand can represent a brand/URL or product line under the merchant.

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

3. End User Context

The customer in the payment flow is the end user, a natural person.

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;
• 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 deposits, it should be modeled as a concrete payment method.

5. Risk and Conversion Context

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.