E-wallets: Overview and Comparison

1) What is e-wallet and why is it merchant

• Higher conversion through App2App/One-tap, local awareness and stored data.
• Low fraud (SCA, device binding, risk scoring provider).
• Flexible sources of funds: card, A2A (bank transfer/open banking), cash vouchers, mobile balance.
• Extended geography and access to classrooms without maps/credit.

2) Wallet classification

1. Stored-value

The user keeps the money in his wallet. Features: top-up, domestic ledger, P2P, balance sheet payments. Examples: Skrill/Neteller, myPaysafe/myNeosurf, local EMI wallets.
Pros: quick replays/returns, off-card audience. Cons: KYC levels, top-up/output limits.

2. Pass-through / Pay-by-bank / Bank-linked

Money is debited directly from the bank account/card through confirmation in the application (often without storing the balance). Examples: MB WAY, Swish, Vipps, TWINT, Bizum.
Pros: low fraud and MDR, instant loans. Cons: limits for banks, lack of classic chargeback.

3. Hybrids

Wallet + card/virtual card/routing (for example, wallet → card rails), or super applications with invoices, QR, P2P, pay-by-link.

3) Sources of funds and flows

Top-up: card (CNP/3DS), A2A (SCT/SEPA Instant, RTP), cash vouchers, agent points.
Pay-in (merchant): App2App/Deep Link, QR per-order, hosted page, tokenized COF/Network tokens (for card wallets).
P2P: by phone/alias, inside wallet/scheme.
Cash-out: bank transfer (SCT/ACH/RTP), to a card (OCT/Push-to-Card), to an offline network, less often - to a voucher.

4) UX patterns affecting conversion

App2App/Deeplink with a return to the cashier and pre-filling of the amount/orders.
Dynamic QR per-order (desktop/offline), life timer, auto-status update.
One-tap/One-click after primary binding (where allowed).
Clear errors and recovery: limit, timeout, SCA failure; safe repeat + alternative method suggestion.

5) Limits, KYC levels and risk

Per-transaction/24h/7d/monthly, separate thresholds for new recipients/merchants.
KYC levels (Anonymous/Simplified/Full): Determine highs by top up/expense/output.
Velocity/device/geo-rules, sanctions, age restrictions.
High-risk vertical (including iGaming): tightened limits, holds, extended monitoring.

6) Returns, disputes and finality

Chargeback: stored-value often has no classic chargeback; wallets on kart rails have card rules.
Refunds: usually a separate credit transaction (full/partial) to the client's wallet/account.
Final A2A: payments are final after confirmation; work with provider ODR procedures.

7) Economics: Fees and hidden costs

MDR/fee is usually lower than CNP cards; depend on geo, turnover, MCC category.
Additional costs: host/SDK, processing 'pending/expired', support/ODR, recon, servicing tickets/subscriptions, AML/KYC checks.

8) Statuses and calculations

• `created → pending → success | failed | canceled | expired`
• Settlement: T + 0/T + 2 in provider/PSP registers. In business logic, separate online confirmation and actual credit.

9) Comparative criteria matrix

Type: stored-value/pass-through/hybrid

Funding Sources: Card/A2A/eCash/Mobile Balance

UX Channels: App2App/QR/Hosted/Pay-by-Link

P2P/Payouts: yes/no, limits and deadlines

Refund/Chargeback: Is there a chargeback; partial refunds

Conversion: mobile priority, One-tap

Commission: landmark against CNP cards

Risk: fraud, finality, regulatory requirements

Geo-Reach/Local Brand: Target Audience Awareness

10) Integration: options and minimum backend

1. Hosted/Embedded at PSP/wallet - fast start, PII minimization.

2. Server-to-Server + App2App/QR is a custom UX, its own wallet selection page.

3. Pay-by-Link/Invoice - convenient for deferred payments/collections.

• API: `createPayment`, `refund`, `webhook`, `queryStatus`, `reconcile`.
• Idempotence ('orderId' + key), exponential retrays, event dedup, DLQ.
• Webhooks: HMAC/nonce, replay protection, strict redirect-URI validation.
• Recon: daily auto-recon + periodic full-recon; store UTR/Fin. reference.
• Catalogs: providers/countries/limits/CCL/error codes; SLA metrics by channel.
• Observability: conversion (by wallets/channels), 'pending→success/expired', latency to settlement/return.

11) Subscriptions and mandates

• First payment → mandate (SEPA DD/Open Banking/purse mandate).
• Store the per-debit limit, frequency, write-off window, pre-notification and control UI (pause/cancel/update).

12) Anti-fraud practices

Device profiling and behavior, geo signals, velocity.
Step-up (additional authentication) in case of anomalies.
Limits on new recipients/payments, cooling-off, deferred services until settlement.
Content fraud (digital keys/skins): delayed issuance, verification of account history.

13) Reconciliation and reporting (operational maturity)

• 'PaymentId/transactionId ',' orderId ', wallet/channel (App2App/QR/Hosted/Link), source of funds (card/A2A/eCash), status, amount/currency, timestamps, UTR/bank link, return details.
• SLA dashboards: wallet conversion, 'expired' share, time to enrollment and to refund, SCA waiver/limits.
• Rassynchronous alerts: online success without an entry in the register, double write-offs, "hanging" pending.

14) iGaming and other sensitive verticals

Check provider policy and local entitlement (availability, limits, holds).
Plan alternative rails (cards/A2A/eCash) and smart-routing by risk/geo/wallet.
Prepare advanced reporting (source of funds, player limits, payout speed, responsible-gaming signals).

15) Mini-comparison by typical profiles

A. Local bank-linked wallets (MB WAY/Swish/Vipps/TWINT/Bizum-like)

Conversion: high (App2App/QR, familiar brand).
Fraud/chargeback: low/absent; refund as a separate loan.
Limits: set banks/scheme; tougher for new recipients/payouts.
Usage: mass payments, tickets/services, iGaming - according to PSP/bank policy.

B. Stored-value (Skrill/Neteller/myPaysafe/myNeosurf и др.)

Conversion: High with active user base.
Fraud: Low, but require strict KYC/AML.
Pros: quick partial refunds, instant reps, P2P.
Cons: Top-up/output limits on KYC levels.

C. eCash/voucher sources inside wallets

Audience without cards/banks: critical for geo with cash economy.
Finality: high; return - credit transaction.
UX: It is important to show "where to buy a voucher" and an invoice/barcode action timer.

16) e-wallets output checklist

1. Market fit: choose 2-4 wallets by geo/audience; evaluate brand recognition.
2. Contract/PSP: rates, SLAs by webhooks/registries, settlement deadlines, returns policy.
3. Integration: 'createPayment' + App2App/QR/Hosted, error/limit screens, safe repetitions.
4. Security: HMAC/nonce, allowlist IP, strict redirect-URI, vault secrets.
5. Recon: daily + full, UTR storage, out-of-sync alerts.
6. Refunds/ODR: partial/full, binding to the original order, support regulations.
7. CCM/limits: config by provider/channel, UI of reasons for refusal and proposals of alternatives.
8. Observability: conversion/latency/expired dashboards, slices by device/bank/wallet.
9. Testing: e2e by main banks/wallets, desktop QR, weak network/timeouts, "hanging" pending, returns in parts.

Landmark card

Статусы: `created/pending/success/failed/canceled/expired` + webhooks.
Settlement: T + 0-T + 2 according to provider/PSP reports.
Chargeback: more often not (except for kart rails); refund - a separate loan.
Limits/CCL: levels in the wallet + channel thresholds for banks/schemes.
Subscriptions: "first payment → mandate" (SEPA/Open Banking/wallet-mandate).

Summary

Build a cash register around a multicard of wallets with App2App/QR and clear recovery-UX - this raises conversion and reduces fraud.
Store limits/CUS/errors in the config, not in the code; Update regularly by provider.
Operational reliability is provided by webhooks + hard recon, idempotency and pending→success/expired analytics.
Use tickets for subscriptions; for high-risk hold alternative rails and smart-routing by risk and geography.