MuchBetter: Tokens and Cards

1) Context and positioning

MuchBetter is an electronic wallet with a mobile application and a tokenized payment confirmation model: the user confirms transactions within the application (SCA, push notifications, device binding), which reduces fraud and increases conversion. In a number of countries, virtual/plastic cards on card rails are available (availability varies by region and issuing partners). The method is popular in digital goods and iGaming (subject to local requirements and provider policy).

Why is this important to Merchant

High mobile-UX: App2App/Push-approval without entering card details.
Low fraud: confirmation in the application + behavioral scoring.
Source flexibility: top-up wallet of cards/A2A/local methods and P2P within the ecosystem.

2) Products and scenarios

2. 1 Wallet and tokens (App2App/Push)

The user stores the balance in a wallet.
On the merchant's check-out, an App2App transition takes place or a deep link application opens; confirmation - via push with SCA.
For the desktop, QR is used: the client scans and confirms in the application.

2. 2 MuchBetter Cards (Virtual/Plastic)

The card is tied to a wallet (availability by country).
Online - 3DS/SCA; POS — PIN/NFC.
Suitable for universal purchases, but for a merchant it is a regular card transaction (with card rules and potential chargeback).

2. 3 Replenishments and payments

Top-up to wallet: cards (3DS2), A2A/open banking, local methods (varies).
Payouts: Merchant payments to users' wallets (by arrangement and geo availability). The user can display on the bank/card/local channels - where allowed.

2. 4 P2P / Request-to-Pay

Transfers between users by contact/number/alias within the ecosystem.
Payment requests (invoice in the appendix) with confirmation in 1-2 taps.

3) Integration flows

3. 1 Hosted/Redirect (fast start)

1. Checkout → Select MuchBetter.
2. Redirect/Deep Link to wallet application → push approval/SCA.
3. Return to merchant site with'status'.
4. Confirmation to the back office: webhook + reconciliation by registers.

3. 2 App2App + QR (mobile/desktop)

Mobile: opening an application via deep link, auto-substitution of the amount/order, confirmation → return.
Desktop: dynamic QR per-order with timer; scan in the application → confirmation → auto-close of the modal and status update.

3. 3 Server-to-Server + Hosted

Your server creates a payment intent, manages statuses and retries; the confirmation interface remains on the wallet side (for PII minimization).

4) Statuses and calculations

Basic status model: 'created → pending → success | failed | canceled | expired'.
'requested → accepted | declined | expired'for requests.
Settlement: enrollments by provider/PSP registries are usually T + 1/T + 2 (opl. days). Separate online success and accounting credit.

5) Limits, KYC and risk policies

Per-txn/24h/7d/monthly limits depend on the user's KYC level, geo and risk profile.
Separate thresholds for new recipients/merchants, top-up and payouts.
Velocity/device/geo-rules, age restrictions and sanctions lists apply.
Store all thresholds and feature availability in a versioned and quick update config.

6) Returns, disputes and finality

Refund - a separate credit transaction (full/partial) back to the wallet/original source.
Chargeback: for purse balance payments, there is usually no classic chargeback; if the payment actually goes on card rails (MuchBetter card), the card rules apply and chargeback is possible.
For digital services, keep issuance logs (timestamps, IP/device, in-game operations) and ODR procedures.

7) Economics and commissions

The MDR for wallet pay-in is usually lower than CNP cards, but depends on geo/turnover/category and PSP contract.
Additional costs: Hosted/SDK, processing 'pending/expired', support/ODR, recon.
Reserves/hold are possible at increased risk or for new merchants.
Reduce cost by A2A top-up inside your wallet and minimizing unnecessary FX conversions.

8) UX practices

Mobile-first: App2App/Push in priority; on the desktop - a large QR with a timer and auto-update status.
Recovery: with 'timeout/expired' - safe repetition, switching to an alternative method (card/A2A/wallet No. 2).

Errors: clear texts "purse/method limit," "SCA failure," "timer expired."

Receipt: amount/currency, 'transactionId', channel (App2App/QR/Hosted), financial reference/UTR.

9) Antifraud and compliance

SCA + device binding and behavioral scoring in the app.
PII minimization: confirmation/authentication on the wallet side, secrets in the vault, IP-allowlist on web hooks.
Webhooks: signature/NMAS, timestamps, replay protection, idempotence and event dedup.
KYC/AML/GDPR, Responsible Gaming (age/self-exclusion), geo-filters.

10) Merchant integration

Options

1. Hosted/Redirect - minimum risk and fast TTM.
2. App2App + Server-to-Server - UX/status control, flexible retrays.
3. Pay-by-Link/Invoice - convenient for deferred payments and support cases.

Backend minimum

API: 'createPayment', 'refund', if necessary 'authorize/capture', 'queryStatus', 'webhook', 'reconcile'.
Idempotence ('orderId' + key), exponential repetitions, DLQ, inbound events.
Recon: daily auto-recon + periodic full-recon; store UTR/Fin. links, alerts by desynchronization.
Observability: conversion, 'pending→success/expired', settlement lag, SCA/limit errors.

11) Payments and Affiliates

Wallet payments increase retention and rate of return to the ecosystem, but comply with limits/CCL and segment by risk/geo.
Keep alternatives: SEPA/RTP/Push-to-Card/local wallets for disputed regions and large amounts.

12) Features for iGaming and high-risk

Check legal eligibility by country/license and current provider policy to vertical.
Expect: tighter limits, selective hold/reserves, extended monitoring.
Plan smart-routing: for new/risky segments - alternative A2A/e-wallet/eCash; for verified - MuchBetter as a priority mobile-UX.

13) KPIs and operational metrics

Approval rate (separately App2App/QR/Hosted).
Pending dwell time и доля `pending→expired`.
Refund rate/ODR and time to resolution.
Settlement lag (success → registry → enrollment).
Cost-to-serve, share of alternatives (fallback methods) and their impact on conversion.
Share of A2A top-up in the wallet (cost reduction).

14) Output checklist

1. PSP/provider agreement: tariffs/MDR, card/payout/geo availability, SLAs by web hooks/registries.
2. Integration: 'createPayment' + App2App/QR/Hosted, error/limit screens, safe repetitions.
3. Security: signature/NMAS web hooks, vault secrets, strict 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/geo/availability of cards and payments - out of code, with versioning.
7. Dashboards SLA: conversion, pending, settlement lag, returns; anomaly/geo alerts.
8. E2E tests: mobile App2App, desktop-QR, timeouts/retrays, partial returns, degradation of the provider.

Landmark card

Statuses: 'created/pending/success/failed/canceled/expired' (+ 'authorize/capture' for split payment).
Settlement: usually T + 1/T + 2 across registries.
Chargeback: none for pure wallet write-off; is for card rail (MuchBetter card).
Limits/LCC: country/level specific; store in config and update regularly.
Return: "first payment → mandate" (SEPA/Open Banking/wallet-mandate) - supported by the script.

Summary

MuchBetter is a tokenized confirmation wallet with strong mobile UX. Integrate via Hosted/App2App/QR, build around webhooks + idempotency + recon, keep limits/LCC/geo/cards/payouts in configuration and use smart-routing by risk and device. In iGaming, follow the legal framework and prepare alternative rails (A2A/local e-wallet/eCash) for sustainability and cost reduction.