BORNA

Deposit & withdrawal experience

Designing a flexible payment system for a multi-market iGaming platform.

Context

This project was part of a broader redesign of a multi-market iGaming platform used by players across different regulated markets.

The platform supports deposits and withdrawals across various countries, payment providers, regulatory requirements, and tenant-level configurations.

I was part of the product design team responsible for rethinking the entire Deposit & Withdrawal experience. My role focused on:

  • Structuring payment logic across markets
  • Designing scalable UX patterns for multiple configurations
  • Aligning business, compliance, and technical constraints
  • Creating consistent flows that work across different wallet setups

The goal was not just to redesign forms, but to build a flexible payment system that could scale across tenants while remaining clear and reliable for players.

The problem

The complexity was not optional. Different tenants had different setups:

  • Some operated with a single wallet
  • Others supported multiple wallets
  • Payment availability depended on wallet context
  • Some providers required hosted (redirect) flows
  • Others collected payment details directly on our platform

Without a clear structure, this led to inconsistent experiences and potential confusion.

The challenge was balancing business flexibility with user clarity.

The key decision: Wallet-aware structure

The most important structural decision was to make the flow wallet-aware, but only when needed.

If a tenant supports multiple wallets, the first step becomes wallet selection.If a tenant uses a single wallet, that step is skipped entirely.

Once a wallet is selected, only the payment methods available for that wallet are shown.

This approach:

  • Prevents unsupported method selection
  • Keeps users in the correct financial context
  • Reduces ambiguity before entering sensitive data

Instead of exposing business logic, the UI adapts to it.

Structuring payment methods

Payment methods were grouped into configurable categories (e.g. Card, E-wallet, Crypto, Voucher, Recommended).

Each method follows a consistent structure:

  1. Amount entry
  2. Context information (limits, fees, processing time)
  3. Method-specific inputs
  4. Clear success and error feedback

This shared structure allows different provider behaviors to exist within the same UX framework.

Card flow deep dive

The card flow had to support three different configurations depending on the tenant setup.1. Hosted (3rd-party collection)The user enters the deposit amount on our platform and is then redirected to the provider’s page to complete card details.

The transition is clearly communicated to maintain trust and clarity.

  • 2. On-platform card entryThe flow always begins with amount entry to maintain structural consistency.

    Card details are entered directly on our platform. If enabled, users can save their card for future payments.

    Security, masking, and validation rules are handled within the interface while respecting PCI compliance requirements.

  • 3. Saved card (Fast deposit)If the card is already saved, the flow becomes shorter. The user only enters the amount and confirms the transaction. This reduces friction while still respecting wallet context and verification rules.Although the technical setup differs, the user experience follows the same logic. This consistency reduces confusion and builds trust in a high-stakes financial action.

Business impact

The final structure made all available payment methods clearly visible to the user, while ensuring that only methods supported by the selected wallet could be used.

 

If multiple wallets exist, the user first selects the wallet. From there, the system shows only the payment methods available for that specific wallet. This removes ambiguity and prevents unsupported actions.

 

At the same time, the flow supports both on-platform and third-party payment providers. Depending on the tenant configuration, the system adapts where the input is handled — while keeping the overall experience consistent for the user.

What I learned

In complex payment systems, clarity comes from controlling what the user sees and when.

By filtering payment methods based on wallet selection and adapting to different provider setups, the UX can stay simple even when the business logic is not.

Structure protects the user from complexity.

Let’s work together

Connect with me on:

BORNA

Deposit & withdrawal experience

Designing a flexible payment system for a multi-market iGaming platform.

Context

This project was part of a broader redesign of a multi-market iGaming platform used by players across different regulated markets.

The platform supports deposits and withdrawals across various countries, payment providers, regulatory requirements, and tenant-level configurations.

I was part of the product design team responsible for rethinking the entire Deposit & Withdrawal experience. My role focused on:

  • Structuring payment logic across markets
  • Designing scalable UX patterns for multiple configurations
  • Aligning business, compliance, and technical constraints
  • Creating consistent flows that work across different wallet setups

The goal was not just to redesign forms, but to build a flexible payment system that could scale across tenants while remaining clear and reliable for players.

The problem

The complexity was not optional. Different tenants had different setups:

  • Some operated with a single wallet
  • Others supported multiple wallets
  • Payment availability depended on wallet context
  • Some providers required hosted (redirect) flows
  • Others collected payment details directly on our platform

Without a clear structure, this led to inconsistent experiences and potential confusion.

The challenge was balancing business flexibility with user clarity.

The key decision: Wallet-aware structure

The most important structural decision was to make the flow wallet-aware, but only when needed.

If a tenant supports multiple wallets, the first step becomes wallet selection.If a tenant uses a single wallet, that step is skipped entirely.

Once a wallet is selected, only the payment methods available for that wallet are shown.

This approach:

  • Prevents unsupported method selection
  • Keeps users in the correct financial context
  • Reduces ambiguity before entering sensitive data

Instead of exposing business logic, the UI adapts to it.

Structuring payment methods

Payment methods were grouped into configurable categories (e.g. Card, E-wallet, Crypto, Voucher, Recommended).

Each method follows a consistent structure:

  1. Amount entry
  2. Context information (limits, fees, processing time)
  3. Method-specific inputs
  4. Clear success and error feedback

This shared structure allows different provider behaviors to exist within the same UX framework.

Card flow deep dive

The card flow had to support three different configurations depending on the tenant setup.1. Hosted (3rd-party collection)The user enters the deposit amount on our platform and is then redirected to the provider’s page to complete card details.

The transition is clearly communicated to maintain trust and clarity.

  • 2. On-platform card entryThe flow always begins with amount entry to maintain structural consistency.

    Card details are entered directly on our platform. If enabled, users can save their card for future payments.

    Security, masking, and validation rules are handled within the interface while respecting PCI compliance requirements.

  • 3. Saved card (Fast deposit)If the card is already saved, the flow becomes shorter. The user only enters the amount and confirms the transaction. This reduces friction while still respecting wallet context and verification rules.Although the technical setup differs, the user experience follows the same logic. This consistency reduces confusion and builds trust in a high-stakes financial action.

Business impact

The final structure made all available payment methods clearly visible to the user, while ensuring that only methods supported by the selected wallet could be used.

 

If multiple wallets exist, the user first selects the wallet. From there, the system shows only the payment methods available for that specific wallet. This removes ambiguity and prevents unsupported actions.

 

At the same time, the flow supports both on-platform and third-party payment providers. Depending on the tenant configuration, the system adapts where the input is handled — while keeping the overall experience consistent for the user.

What I learned

In complex payment systems, clarity comes from controlling what the user sees and when.

By filtering payment methods based on wallet selection and adapting to different provider setups, the UX can stay simple even when the business logic is not.

Structure protects the user from complexity.