ecoPayz: carteira e contas

1) Contexto e posicionamento

ecoPayz (transferido como Payz) é uma carteira eletrônica com balanços multi-portáteis (em seguida, «carteira/conta») focada em serviços digitais e iGaming (em jurisdições permitidas). O usuário mantém os fundos na carteira, faz P2P, paga os merçantes, reequilibra os fundos com diferentes métodos e remete ao banco/cartão/canais locais (o acesso depende do país/CUS).

Por que o merchant se beneficia disso

Conversão superior graças a Hosted/App2App-UX e reconhecimento nos segmentos de destino.
Frota baixa (SCA, device binding, risco-mapeamento).
Economia flexível (muitas vezes abaixo dos cartões CNP), rápido partial refunds na carteira.

2) Produtos e papéis

Carteira/contas: balanços do usuário (top-up/consumo/saída).
Mapas (virtuais/plásticos em roteiros de caretas) - não estão disponíveis em todos os países.
Fontes de voucher (ecoVoucher e similares através de parceiros) - onde é permitido.
PSP/Equeyer: permuta, tarifas/MDR, Hosted/Widget/API, cálculos e relatórios.
Esquema/emissor de carteira: AUP, KYC/AML, limites, antifrode, livro de carteira.

3) Canais e cenários personalizados

3. 1 Pay-in (pagamento de merchant)

Hosted/Redirect (recomendado): Redirect em ecoPayz/Payz → login/SCA → confirmação → retorno com status.
App2App/Deplink: O mobile abre o aplicativo da carteira, depois o retorno para a bilheteria.
Embedded/Widget: Respeitando os requisitos de segurança do provedor.

3. 2 Top-up na carteira (do usuário)

Cartões (3DS2), A2A/Open Banking/traduções locais, eCash/vales, P2P. O conjunto de fontes depende do país e do nível KYC.

3. 3 Payouts/Withdraw

Pagamento de merchant por carteira de utilizador; a seguir, a entrada do usuário no banco/cartão/métodos locais (disponibilidade por país/CUS).

3. 4 P2P / Request-to-Pay

Transferências e pedidos de pagamento entre carteiras (onde suportado).

3. 5 Cartão da carteira

Cartão virtual/plástico (se disponível): cancelamento do balanço da carteira; online - SCA/3DS, POS - PIN/NFC.

4) Estados e cálculos

Estatais típicas: 'created → pending → success | failed | canceled | expired' (+ se necessário 'autorized → captured').
Senslement: Inscrições nos registros PSP/provedor normalmente T + 1/T + 2 (escravo. dias).
Na lógica, compartilhe o sucesso online e o crédito real.

5) Limites, KYC e políticas de risco

Limites per-txn/24h/7d/monthly; liminares individuais para novos beneficiários/merchantes e para conclusões.
Níveis KYC (básico/avançado/VIP): Definem os níveis de top up/saída e conjunto de métodos suportados.
Velocity/device/geo-regras, sanções e restrições de idade (especialmente para iGaming).
Limite/regras mantenha em configs com capacidade de atualização quente.

6) Devoluções, displays, finalidade

Refund é uma operação separada de crédito (full/partial) de volta para a carteira/origem.
Chargeback: Normalmente não há nenhum charjback clássico para o cancelamento puro «carteira»; se o roteiro real for um cartão (COF/cartão dentro da carteira), pode haver procedimentos de cartão no emissor.
Planeje procedimentos ODR e armazene logs completos de serviços digitais.

7) Economia e comissões

O MDR para merchant normalmente é inferior ao cartão CNP, mas depende de geo/circulação/categoria.
Suporte: Hosted/SDK, suporte 'pending/expired', ODR/display, recon, possíveis reservas/hold sobre risco.
Gerencie o custo: estimule o A2A top-up e a multiversibilidade (menos FX), use o upsale em VIP.

8) Práticas UX

Mobile-first: App2App prioridade; O desctop é um Redirect claro.
Tempo de espera de confirmação ('pending'), repetição segura, sugestões de alternativas (cartões/A2A).
Erros transparentes: limite de carteira/método, falha SCA, tempo.
Recibo: valor/moeda, 'transactionId', canal (App2App/Hosted), registro financeiro/UTR.

9) Integração do merchant

Opções

1. Hosted/Redirect é um início rápido, PCI/PII mínimo.
2. Server-to-Server + App2App/Hosted - UX custômico e controle de estatais apertado.
3. Pay-by-Link/Invoice - para pagamentos atrasados/coleta.

O mínimo de Backend

API: `createPayment`, `authorize/capture` (если требуется), `refund`, `queryStatus`, `webhook`, `reconcile`.
Idempotidade ('orderId' + chave), repetições exponenciais, dedução dos ganchos da Web que entram.
Webhooks: assinatura/NMAS, timing, proteção contra replay.
Recon: daily auto-recon + full-recon, armazenamento UTR/links bancários, alertas por rashincrons.
Observabilidade: conversão, 'pending→success/expired', senslement-lag, erros SCA/limites.

10) Segurança e conformidade

SCA (autenticação na carteira), device binding, compilação comportamental.
PII-Minimização: Hosted/Widget para inserção de dados sensíveis, segredos em vault, IP-allowlist em webhook-endpoint, redict-URI rigoroso.
KYC/AML/GDPR, idade, sanções, geo-filtros, Responível Gaming.

11) Pagamentos e afiliações

Pagamentos de carteiras são frequentemente confortáveis (rápido e barato), mas segmentar por risco/geo/CUS.
Mantenha as alternativas SEPA/RTP/Push-to-Card/carteiras locais para regiões em disputa ou grandes quantias.

12) Características para iGaming

Verifique a validade legal do geo e da licença; ative o controle de idade e auto-exclusão.
Espere mais limites, possíveis hold/reservas, monitoramento avançado de transações e pagamentos.
Planeje um roteiro inteligente (carteira ↔ A2A ↔ vales ↔ cartões) por risco/geo/perfil do jogador.

13) KPI e métricas operacionais

Approval rate (separado por App2App/Hosted).
Pending dwell time и доля `pending→expired`.
Refund rate/ODR e tempo médio de solução.
Setlement lag (sucesso → registro → inscrição).
FX share e margem média FX.

Participação VIP/KYC avançado em circulação,

14) Folha de cheque de saída em proda

1. Contrato com PSP/Provedor: tarifas/MDR, regras FX, SLA sobre ganchos/registros, geo/vertical permitido.
2. Integração: 'createPayment' + App2App/Hosted, telas de erro/limite/repetição.
3. Segurança: assinatura/NMAS Hooks Web, vault segredos, redict-URI, IP-allowlist.
4. Recon: daily + full, armazenamento UTR/arquivos finos, alertas de rashincrons.
5. Refunds/ODR: partial/full, playbooks de safort, laço de refund↔order.
6. Configs: limites/CUS/tarifas/geo - fora do código, com versionização e atualização rápida.
7. Dashboards SLA: conversão, 'pending', masslement-lag, devoluções; alertas para anomalias/geo.
8. Testes E2E: móvel App2App, desctop-rerect, temporizadores/repetições, retornos parciais, degradação do provedor.

Cartão de referência

Estados: 'created/pending/sucess/failed/canceled/expired' (+ 'autorize/capture', onde é aplicável).
Senslement: normalmente T + 1/T + 2 nos registros PSP/provedor.
Chargeback: Falta para o débito puro «carteira»; É possível para o caminho de cartas.
Limites/CUS: dependem do país/nível; armazenar no configh e atualizar regularmente.
Recurrent: «primeiro pagamento → mandato» (SEPA/Open-Banking/carteira-mandato) - se o cenário suporta isso.

Currículo

ecoPayz/Payz é uma carteira madura com balanços multi-portáteis, um UX móvel forte e uma operação compreensível. Integre-se através do Hosted/App2App, construa-se em torno de webhooks + idempotação + recon, mantenha os limites/CUS/tarifas/geo na configuração e, para iGaming, cumpra os marcos legais, segmenta o risco e mantenha roteiros alternativos (A2A/vales/cartões) com smart-routing de perfil e carga.