ecoPayz: wallet and bills

1) Context and positioning

ecoPayz (re-branded as Payz) is an electronic wallet with multi-currency balances (hereinafter referred to as "wallet/accounts"), focused on digital services and iGaming (in permitted jurisdictions). The user keeps funds on his wallet, makes P2P, pays merchants, replenishes the balance by various methods and displays it on the bank/card/local channels (access depends on the country/CCP).

Why is it profitable for the merchant

Higher conversion due to Hosted/App2App-UX and recognition in target segments.
Low fraud (SCA, device binding, risk scoring).
Flexible economy (often below CNP cards), quick partial refunds to the wallet.

2) Products and roles

Purse/accounts: multi-currency user balances (top-up/expense/output).
Maps (virtual/plastic on rails of maps) - not available in all countries.
Voucher sources (ecoVoucher and analogues through partners) - where allowed.
PSP/acquirer: merchant onboarding, tariffs/MDR, Hosted/Widget/API, calculations and reports.
Wallet scheme/issuer: AUP, KYC/AML, limits, anti-fraud, wallet book.

3) Channels and user scenarios

3. 1 Pay-in

Hosted/Redirect (recommended): redirect to ecoPayz/Payz → login/SCA → confirmation → return with status.
App2App/Deeplink: the wallet application opens on the mobile, then return to the cashier.
Embedded/Widget: subject to provider security requirements.

3. 2 Top-up to wallet (user)

Cards (3DS2), A2A/Open Banking/local transfers, eCash/vouchers, P2P. The set of sources varies by country and KYC level.

3. 3 Payouts/Withdraw

Merchant payments to users' wallets; further - output by the user to the bank/card/local methods (availability by country/CCM).

3. 4 P2P / Request-to-Pay

Transfers and requests for payments between wallets (where supported).

3. 5 Wallet card

Virtual/plastic card (if available): debit from wallet balance; online - SCA/3DS, POS - PIN/NFC.

4) Statuses and calculations

Typical statuses are 'created → pending → success | failed | canceled | expired' (+ 'authorized → captured' if necessary).
Settlement: enrollment by PSP/provider registries is usually T + 1/T + 2 (opl. days).
In logic, separate online success and actual credit.

5) Limits, KYC and risk policies

Limits per-txn/24h/7d/monthly; separate thresholds for new recipients/merchants and for outputs.
KYC (Basic/Advanced/VIP) Levels: Defines top-up/flow/output highs and a set of supported methods.
Velocity/device/geo-rules, sanctions and age restrictions (especially for iGaming).
Keep limits/rules in configs with the possibility of hot updates.

6) Returns, disputes, finality

Refund - a separate credit transaction (full/partial) back to the wallet/original source.
Chargeback: for a purely "wallet" write-off, classic card chargebacks are usually not; if the actual rail is a card (COF/card inside the wallet), card procedures at the issuer are possible.
Schedule ODR procedures and store complete digital service issuance logs.

7) Economics and commissions

The MDR for merchant is usually lower than CNP cards, but depends on geo/turnover/category.
Additional costs: Hosted/SDK, support for 'pending/expired', ODR/disputes, recon, possible reserves/hold for risk.
Manage the cost: stimulate A2A top-up and multi-currency (less FX), use upsell on VIP.

8) UX practices

Mobile-first: App2App in priority; on the desktop - a clear Redirect.
Timer for waiting for confirmation ('pending'), safe repetition, suggestions of alternatives (cards/A2A).
Transparent errors: purse/method limit, SCA failure, timeout.
Receipt: amount/currency, 'transactionId', channel (App2App/Hosted), financial reference/UTR from the registry.

9) Merchant integration

Options

1. Hosted/Redirect - fast start, minimal PCI/PII footprint.
2. Server-to-Server + App2App/Hosted - custom UX and tight status control.
3. Pay-by-Link/Invoice - for deferred payments/collection.

Backend minimum

API: `createPayment`, `authorize/capture` (если требуется), `refund`, `queryStatus`, `webhook`, `reconcile`.
Idempotence ('orderId' + key), exponential repetitions, dedup of incoming web hooks.
Webhooks: signature/NMAS, timestamps, replay protection.
Recon: daily auto-recon + full-recon, storage of UTR/bank links, alerts by misalignment.
Observability: conversion, 'pending→success/expired', settlement-lag, SCA/limit errors.

10) Safety and compliance

SCA (wallet authentication), device binding, behavioral scoring.
PII minimization: Hosted/Widget for entering sensitive data, secrets - in vault, IP-allowlist for webhook endpoints, strict redirect-URIs.
KYC/AML/GDPR, age, sanctions, geo-filters, Responsible Gaming.

11) Payments and Affiliates

Payments to wallets are often convenient (fast and cheap), but segment by risk/geo/CUS.
Keep alternatives: SEPA/RTP/Push-to-Card/local wallets for disputed regions or large amounts.

12) Features for iGaming

Check the legal permissibility of geo and licenses; include age control and self-exclusion.
Expect: tighter limits, possible hold/reserves, expanded monitoring of transactions and payments.
Plan smart routing (wallet ↔ A2A ↔ ↔ card vouchers) by risk/geo/player profile.

13) KPIs and operational metrics

Approval rate (separately for App2App/Hosted).
Pending dwell time и доля `pending→expired`.
Refund rate/ODR and average decision time.
Settlement lag (success → registry → enrollment).
FX share and average FX margin.
Share of VIP/extended KYC in turnover, Cost-to-serve (support/disputes).

14) Output checklist

1. PSP/provider agreement: tariffs/MDR, FX rules, SLAs for web hooks/registries, geo/vertical allowed.
2. Integration: 'createPayment' + App2App/Hosted, error/limit/repeat screens.
3. Security: signature/NMAS web hooks, vault secrets, redirect-URI, IP-allowlist.
4. Recon: daily + full, UTR/fin reference storage, desynchronization alerts.
5. Refunds/ODR: partial/full, support playbooks, refund↔order bundle.
6. Configs: limits/CCL/tariffs/geo - out of code, versioned and quickly updated.
7. Dashboards SLA: conversion, 'pending', settlement-lag, returns; anomaly/geo alerts.
8. E2E tests: mobile App2App, desktop redirect, timeouts/retries, partial returns, provider degradation.

Landmark card

Statuses: 'created/pending/success/failed/canceled/expired' (+ 'authorize/capture' where applicable).
Settlement: usually T + 1/T + 2 by PSP/provider registers.
Chargeback: missing for net "purse" charge; possible for a card rail.
Limits/LCC: country/level specific; store in config and update regularly.
Return: "first payment → mandate" (SEPA/Open-Banking/wallet-mandate) - if the script supports this.

Summary

ecoPayz/Payz is a mature wallet with multi-currency balances, strong mobile UX and an understandable operating system. Integrate through Hosted/App2App, build around webhooks + idempotency + recon, keep limits/CCL/tariffs/geo in configuration, and for iGaming, follow the legal framework, segment risk and keep alternative rails (A2A/vouchers/cards) with smart-routing by player profile and load.