Cash vouchers and retail chains

1) What it is and when to apply

Cash vouchers and eCash networks allow you to accept payment without bank cards and IBAN. The user buys a prepaid voucher (PIN) or receives a barcode/QR (pay-at-store) and pays for the order at the partner's offline point (kiosk, supermarket, gas station, post office) or at an Internet bank/ATM. Money goes to the merchant through the PSP/provider on bank rails; there is no chargeback, the risks of fraud are minimal.

• Digital goods/games, content, low/medium check subscriptions.
• Regions with a high share of cash or low card penetration.
• Audiences who prefer privacy/prepayment.

2) Typology of eCash instruments

1. PIN vouchers (prepaid codes):

Examples: Paysafecard, Neosurf, Flexepin.
UX: enter a 16-/10-digit PIN on the hosted form or pay from the wallet (myPaysafe/myNeosurf).
Features: partial write-offs, a combination of several PINs, the balance is saved.

2. Barcodes/QR "Cash payment barcode":

Examples: paysafecash, local networks (OXXO Pay - MX, RapiPago/PagoFácil - AR, Efecty/Baloto - CO, PayPoint/Payzone - UK, ePay/Paylink - EU, etc.).
UX: merchant generates barcode/QR → the client pays in cash at the checkout → the provider sends a confirmation.
Features: the check is valid for a limited time (expiry), the amount is fixed.

3. Reference/Slip for ATM/online banking (invoice details):

Examples: Multibanco References - PT, Konbini - JP.
UX: displays code/reference + amount, payment in ATM/online bank/partner store.
Features: minimum fraud, strict reference reconciliation.

3) Ecosystem participants

Provider/scheme (eCash/vouchers): issues PIN/barcodes, maintains retail catalogs, KYC/AML, anti-fraud, gives API/widgets.
PSP/acquirer: connects merchant, hosted cash desk/SDK, statuses, web hooks, registries and calculations.
Retail/cash desk: cash receipt/barcode reading, synchronization with the provider.
Bank/clearing: settlements and crediting of funds to merchant.
Merchant: initiates payment/invoice, processes statuses, returns and recon.

4) Payment flows

4. 1 PIN voucher (Hosted/Redirect)

1. Checkout → eCash selection (e.g. Paysafecard/Neosurf).
2. Redirect/Hosted form of the provider → entering a PIN/entering a wallet → confirmation (SCA/behavioral scoring).
3. Return to merchant: 'success/pending/failed/canceled/expired'.
4. Actual credit - according to daily registers (T + 1/T + 2).

4. 2 Barcode/QR "pay in store"

1. Merchant creates an invoice: amount + barcode/QR + expiry.
2. The client goes to the retail outlet and pays in cash → the cash desk confirms the operation to the provider.
3. The provider sends the merchant an online success, then a loan in the registers (T + 0/T + 1).

4. 3 Reference/Slip (ATM/online-banking/konbini)

1. Generation of reference (entity/reference/amount) + validity period.
2. Payment in ATM/online bank/partner store.
3. Online status' paid'and subsequent settlement in registries.

5) Statuses and calculations

Online statuses: 'created '/' pending '/' success' paid '/' failed '/' cancelled '/' expired '.
Settlement: usually T + 0/T + 2 banking days (per contract/channel).
In business logic, separate online confirmation and actual credit.

6) Limits, KYC and risk

• Per-transaction, 24h/7d, limit on the number of PINs per payment/day.
• For new recipients/merchants - reduced thresholds/shutter speed.
• Geo-rules (voucher country vs customer/merchant location), velocity, device signals.
• There is no Chargers; disputes - by provider/PSP ODR.
• Recommendation: keep the config limits by country/network/CCP and do not hardcode the amounts.

7) Returns and partial write-offs

Refund = new credit transaction (to the eCash wallet/bank transfer - according to the provider's rules).
Partial refunds are usually supported.
Partial charges and PIN combination are often available for PIN vouchers; for barcode invoices - the amount is fixed.

8) Economy and tariffs

The commission for merchant is usually lower than the CNP-card MDR, but varies by geo/volume/category.
Additional costs: hosted/SDK, point of sale advertising, support/ODR, 'expired/pending'processing, recon.

9) UX patterns

PIN payment: understandable UI for several PINs and a balance indicator; error messages "incorrect/used," "limit exceeded," "region not supported."

Barcode/QR: large code + expiration timer, print/send to messenger/email buttons.
Offline payment instructions: 3-4 steps with network logos; nearest points map/operating hours.

Order status: "Pending payment" with auto-update; with'expired '- the button "create new code."

Receipt: amount, time, 'paymentId', channel (PIN/Barcode/Reference), UTR/ref. from the registry, support contacts.
Localization: currency/language/tax texts, local brands of networks.

10) Safety and compliance

PII minimization: PIN/wallet are entered on the provider side (Hosted/Widget).
Web hooks: HMAC/nonce, replay protection, event dedup, audit log.
KYC/AML/GDPR: age/limit rules for prepaid funds, sanctions/geo-restrictions.
Anti-fraud: device/session limits, cooling-off, step-up, monitoring of repeated PIN/barcodes.

11) Integration and architecture

Connectivity options

1. Hosted/Embedded at PSP/provider - fast launch, minimal responsibility for sensitive data.
2. Server-to-Server + Hosted - your own checkout with status control, without processing your PIN.
3. Pay-by-Link/Invoice - reference payments and support cases.

Backend minimum

API: `createPayment|createInvoice` (amount + expiry), `refund`, `queryStatus`, `webhook`, `reconcile`.
Idempotence ('orderId' + key), exponential retrays, DLQ, web hook dedup.
Directories: countries/networks/limits/CCL levels, error codes, SLA metrics by channel.
Observability: conversion (PIN vs Barcode/Reference), 'pending→expired' share, average timings before payment/settlement, geo-anomalies.

12) Geographical notes (landmarks)

Европа: Paysafecard, paysafecash, Neosurf, PayPoint/Payzone (UK), ePay/Paylink (EU), Multibanco (PT).
ЛатАм: OXXO Pay (MX), RapiPago/PagoFácil (AR), Efecty/Baloto (CO).
Asia: Konbini (JP) and local area networks (FamilyMart/Lawson/7-Eleven).

13) Output checklist

1. Select provider/PSP and target networks (PIN/Barcode/Reference), agree on tariffs/SLA/settlement.
2. Implement 'createPayment' createInvoice 'with expiry, statement pages and fallback scripts.
3. Connect webhooks (HMAC), idempotency, retrai and dedup events.
4. Set up daily auto-recon + full-recon, store UTR/fin references.
5. Include partial refunds, ODR procedures, and clear fault/limit messages.
6. Run SLA dashboards (conversion, 'expired', time to pay/settlement) and alerts on out-of-sync.
7. Conduct e2e tests: multiple PINs, expired barcode, incorrect amount, double payment, refund in installments.

Landmark card

Статусы: `created/pending/success|paid/failed/canceled/expired`.
Settlement: usually T + 0-T + 2 by PSP/provider registers.
Chargeback: missing; refund - a separate credit transaction.
Limits/ACLs: depending on country/network/channel and customer profile.
Recurrence: the first eCash → mandate (SEPA/Open-Banking/local) for subsequent write-offs.

Summary

Strategy: eCash mix (PIN + barcode/QR + reference) to reach cash audience and reduce MDR.
Architecture around webhooks + recon, strict idempotence and understandable UX 'pending/expired'.
Config limits/CUS and geo-rules - out of code, with regular updating.
For subscriptions - the first eCash → ticket, transparent management and notifications for the user.