Paysafecard prepaid vouchers

1) What is Paysafecard and when to choose it

Paysafecard is a prepaid voucher payment method: the user buys a voucher for cash/card from retail partners (or replenishes myPaysafe wallet) and pays online by entering the voucher PIN or logging in to the wallet. Funds are debited instantly, chargeback is not in the cards; the refund is made as a separate credit transaction to the wallet/bank details according to the provider's procedures.

Where it works well

Digital content, games, low/medium subscriptions.
Low card penetration/credit trust audiences.
Markets with a strong cash economy and a developed voucher retail network.

2) Ecosystem and roles

Scheme/provider: Paysafecard (part of Paysafe Group) - voucher issue, KYC/KYB rules, anti-fraud, myPaysafe wallet.
Retail chain: sales of vouchers/replenishment of wallets, check with PIN.
PSP/acquirer: merchant connection, hosted cash desk/SDK/API, reports, calculations.
Merchant: initiates payment, accepts statuses/web hooks, conducts returns and reconciliation.
Payer: enters a PIN or logs in to myPaysafe and confirms the charge.

3) Products and scenarios

PIN voucher: on the check-out, the user enters a 16-digit PIN; partial write-offs and a combination of several vouchers (within limits) are allowed.
myPaysafe (wallet): payment from the balance, comfort for frequent purchases; multiple vouchers can be linked and currencies can be managed.
Paysafecard Mastercard (virtual/plastic): found in users as a separate product (card rail, outside the basic PIN flow).
Payment by link: invoice/Rau-by-Link from PSP with further PIN entry in the hosted office.

4) Payment flows

4. 1 Hosted/Redirect (recommended)

1. Checkout → Paysafecard selection.
2. Redirect to the PSP/provider hosted page → enter a PIN or login in myPaysafe → confirm.
3. Return to merchant site with 'status' (success/failed/canceled/pending) and 'paymentId'.
4. The final calculation is reflected in the daily reports (reconciliation).

4. 2 Embedded/Widget

Embedded PIN/myPaysafe input widget inside the cash register. Requires strict compliance with UI and hosting security requirements.

4. 3 Server-to-Server (PII minimization)

The merchant server initiates the payment and polls the status; PIN entry always remains on the provider/widget side.

5) Limits, KYC and behavior

• Per-transaction and daily/weekly limits.
• Voucher combination: Limit the number of PINs per payment.
• New merchants/categories: lowered thresholds, additional checks.
• Antifraud: velocity, voucher country vs merchant country, device/behavioral signals.

6) Statuses, settlements and returns

Online statuses: 'success', 'pending', 'failed', 'cancelled', 'expired'.
Settlement: bank credit according to PSP/provider reports (usually T + 1/T + 2 working days; depends on the contract).
Chargeback is missing.
Refunds: issued as a separate credit transaction (to myPaysafe wallet/bank according to the provider's procedure); partial refunds allowed.
Partial deductions from the voucher: with a check above the face value, a combination of vouchers is allowed; if the check is lower, the balance remains on the PIN/wallet (depending on the country and settings).

7) Economy and tariffs

The commission for a merchant is usually lower than the card MDR for CNP, but depends on geography, volume, category (iGaming/digital goods, etc.).
Add-costs: hosted widget/SDK, reporting, ODR/support, processing 'pending/expired', recon.

8) UX box office patterns

Sales network visibility: A short "Where to buy voucher" tip boosts new customer conversion.
PIN combination: Provide an interface for adding multiple vouchers and clearly show the balance.

Clear errors: "incorrect/used PIN," "limit exceeded," "region not supported."

Receipt: amount, time, 'paymentId', method (PIN/myPaysafe), on return - 'refundId'.
Localization: currency, language, time/date format, local legal texts.

9) Compliance and safety

SCA/provider-side authentication, device binding, and behavioral scoring.
PII minimization: do not process PIN on the merchant side; use the form host/widget.
Web hooks: HMAC/nonce, replay protection, event deduplication.

GDPR/KYC/AML: accounting for age, country limits, sanctions restrictions and rules for "prepaid funds."

10) Reconciliation and reporting

Log: 'paymentId', 'orderId', method (PIN/myPaysafe), currency, amount, status, timestamps, financial reference/UTR from PSP reports.
Daily: auto-recon cash events with financial registers (credits/returns/corrections).

Out-of-sync alerts: "success without registry," "double write-off," "hanging pending."

11) Merchant integration

Options

1. Hosted/Embedded by PSP - fast start, UI/security compliance.
2. Server-to-Server + Hosted PIN - flexible status control and own-checkout without processing your PIN.
3. Pay-by-Link/Invoice - convenient for deferred payments/support.

• API: `createPayment`, `capture/confirm` (если применимо), `refund`, `queryStatus`, `webhook`, `reconcile`.
• Idempotency ('orderId' + key), exponential retrays, DLQ for unstable responses.
• Catalogs: countries/currencies, limits/CCL levels, error codes, SLA metrics.

12) Features for subscriptions and re-debits

• myPaysafe as a source of funds (where allowed),
• or first payment → mandate/alternative A2A (SEPA/Open Banking).
• Always show the user the ticket management screen (per debit limit, frequency, notifications).

13) Antifraud and risk policy

Checks: region of issue PIN vs IP/device, behavioral profile, frequency of unsuccessful attempts, account communication via PIN repetitions.
Mitigation: limits on the number of PINs per session/day, captcha/step-up, cooling periods, "soft" failures with an explanation.

14) High-risk verticals (including iGaming)

Availability and thresholds vary by country, local law, and provider/PSP policy.
Expect reduced limits, increased transaction monitoring, and reporting requirements.
Keep alternative rails (maps, A2A, vouchers of other networks) and smart-routing.

15) Paysafecard Gateway architecture

Cash/billing API layer (REST/GraphQL).
Event queues: statuses → billing/CRM/analytics/support.
Security: vault of secrets, IP-allowlist, strict redirect-URI validation, anti-replay tokens.
Observability: conversion (PIN vs myPaysafe), 'pending→success/expired', average latency, share of partial/combined write-offs, segment returns.

16) Output checklist

1. Connect the channel at the PSP and enable Hosted PIN/myPaysafe.
2. Implement 'createPayment' + web hooks (HMAC) + idempotency and repetitions.
3. Enable partial refunds and ODR/support procedures.
4. Set up daily auto-recon + periodic full-recon; keep fin references.
5. Add UX for PIN combination and clear error/limit messages.
6. Run SLA dashboards and alerts on conversion/suspended 'pending'.
7. Run e2e tests in target countries/currencies and extreme cases (multiple PIN, partial return, expired PIN).

Landmark card

Statuses: 'success/pending/failed/canceled/expired'.
Settlement: more often T + 1/T + 2 by registers.
Chargeback: none; refund - a separate credit transaction.
PIN combination: allowed within limits.
Recurrence: via myPaysafe or alternative mandate (after the first payment).

Summary

Use Hosted PIN/myPaysafe for fast integration and security.
Build the process around webhooks + recon, support partial refunds and a combination of vouchers.
Do not "hard" code the amounts: keep limit/CCL configs by country and update regularly.
For subscriptions, the first voucher →/myPaysafe ticket, with transparent management and notifications.