Diretórios per currency

O catálogo per currency é uma opção de catálogo de conteúdo e pricking, onde os preços exibidos, limites, bônus, taxas mínimas, jackpots e textos promocionais são adaptados à moeda do jogador/tenante/região. O objetivo é dar os pontos de price certos e as regras sem a lógica de copipaço e sem riscos devido às conversões de voo.

• UX: Passos naturais de apostas e preços «bonitos» (₺9. 99, R$5, €0. 20).
• Rendimentos: limites exatos e bustos sem «correria» de margem devido aos cursos.
• Complaens: conformidade com as regras locais (licenças, impostos, age/geo).

1) Modelo de dados: partilhamos «nominal» e «representação»

Base Prece (nominal): moeda interna única 'PLN '/' EUR '/' USD' para cálculos.
Display Price (apresentação): é calculado a partir de + FX + arredondamento + descontos (spread/fees).
Policy: regras de arredondamento, etapas de apostas, limites min/max, jackpots, bónus e wager - personalizado per currency.

yaml price_model:
base_currency: "EUR"
items:
game_spin_min:
base: 0. 10 policy: "stake_min"
game_spin_step:
base: 0. 10 policy: "stake_step"
jackpot_seed:
base: 10000 policy: "jackpot_amount"
policies:
stake_min:
per_currency:
EUR: {round: "ceil_to_step", step: 0. 10}
TRY: {round: "ceil_to_step", step: 1. 00}
BRL: {round: "ceil_to_step", step: 0. 50}
stake_step:
per_currency:
EUR: {step: 0. 10}
USD: {step: 0. 10}
CLP: {step: 50}
jackpot_amount:
per_currency:
EUR: {round: "nearest_100"}
MXN: {round: "nearest_1000"}

2) Fonte de cursos (FX) e «frescor»

• Provedor de cursos: principal e reserva; taxa de atualização (por exemplo, cada minuto para voláteis, a cada 15 minutos para estáveis).
• Bounded staleness: SLA «cursos com menos de 1 min» (por exemplo, p95 ≤ 5 min).
• Spread e comissões: configure per tenant/region/currency.
• Freeze windows: «congelar» cursos para jogo/torneio/janelas de promoção para que a price não «salte».
• Auditoria: logs de versão de FX com 'valid _ from/valid _ to' para reproduzir cheques.

json
{
"as_of":"2025-10-31T12:00:00Z",
"base":"EUR",
"rates": { "TRY":34. 10, "BRL":5. 42, "MXN":19. 1, "UAH":43. 6, "USDT":1. 00 },
"spread_bps": { "TRY":120, "BRL":60 },
"fees_pct": { "default":0. 15 }
}

3) Arredondar e «belos» pontos de price

• Preços/pacotes: '99', '9. 99`, `4. 90 '(pontos psicológicos).
• Apostas e passos: «ceil _ to _ step» para a etapa de câmbio (₺1, CLP $50).
• Bónus: arredondar para baixo na etapa de voucher (R $1/ ₺5).
• Ordem de operações: 'raw = base fx (1 + spread) (1 + fee)' n' rounded = round _ policy (raw) ' ' min/max clamp '.

Anti-exemplo: «arredondamento bancário» para apostas pode dar passos «feios» - use políticas explícitas.

4) Limites, min/max e jackpots

Min/Max per currency: leva em conta as leis locais e as restrições RGS.
Jackpots: Se o provedor mantiver o jackpot na sua moeda (EUR, por exemplo), mostre o equivalente localizado (informador) ou guarde as pulas para-moeda.
Passos da moeda: CLP/JPY sem centavos - todos os limites são inteiros.

sql
CREATE TABLE currency_limits (
tenant_id text,
currency  text,
feature  text,  -- spin_min, spin_max, deposit_min, payout_max, jackpot_min value   numeric,
step    numeric,
PRIMARY KEY (tenant_id, currency, feature)
);

5) Bônus e vales per currency

Valor do bónus: configura per currency (não «recontagem» na testa).
Wager: guarde como um multiplicador (x30) ou como um montante na moeda; Evite misturar.
Campo de ganho/dinheiro, também per currency.
Texto de marketing: localização de números e moeda em modelos sem hardcod.

yaml bonus:
welcome_pack:
EUR: {amount: 100, wager_x: 35, cap: 500}
BRL: {amount: 500, wager_x: 40, cap: 2500}
TRY: {amount: 2500, wager_x: 40, cap: 12500}

6) Restrições de provedores (RGS/PSP)

RGS: alguns jogos não estão disponíveis para moedas 'crypto '/locais; alguns provedores exigem mínimos fixos (por exemplo, €0. 20).
PSP: Os métodos de pagamento dependem da moeda (PIX ↔ BRL, PayID ↔ AUD, Papara ↔ TRY); os limites de depósito/saída também são diferentes.
Regra: diretório/vitrine filtram jogos e formas de pagamento em moeda e jurisdição antes da exibição.

7) Circuito arquitetônico

Currency Policy Store (COP): tabelas de regras per currency (passos, limites, pontos de price, arredondados).
Serviço FX: dinheiro de cursos, versões e SLA frescura.
Catálogo-bilder: produz Read Models per currency (projeções).
API da camada de leitura: puxa projeções finas; nada de conversões on-the-fly no caminho quente UI.
Outbox → Projeções: alterações de FX/políticas → eventos 'CurrencyPolicyUpdated/FXUpdated' → updates de vitrines incorporados.

read_catalog_{tenant}_{region}_{currency}

A partilha por moeda acelera o refresh e a coleta de métricas.

8) Projeções per currency (exemplo)

sql
CREATE TABLE read_catalog_currency (
tenant_id  text,
region   text,
currency  text,
game_id   text,
price_min numeric, -- displayed min-rate price_step numeric,
jackpot   numeric,
bonus_badge text,
as_of    timestamptz,
PRIMARY KEY (tenant_id, region, currency, game_id)
);

Atualizações - Idempotentes 'UPSERT' de eventos de diretório + eventos FX/políticas.

9) Formatação e localização

O símbolo/código é «₺/TRY», «R $/BRL», «€», «USDT» (para cripto - sem cêntimos ou com 2 caracteres, de acordo com a política UX).
Agrupamento e separador decimal: dependem de 'local' (BR _ BR, tr _ TR, pt _ BR).
Os Locais Árabes, para verificar se o sinal da moeda é correto.

10) Em dinheiro e desempenho

Respostas catalinas per currency cante 30-120 c; Dê o indicador FX 'as _ of' na resposta.
Deficiência: eventos 'FXUpdated '/' PolicyUpdated '/' GameUpserted' → limpar a chave de armazenamento.
Paginação com cursores para que a ordem dos cartões não seja «saltada» em pequenos updates price.

11) Observabilidade e SLO

• `catalog_p95_ms` по валютам, `fx_freshness_ms` (p50/p95/p99), `policy_refresh_latency_ms`.
• A proporção de preços «indevidos» (não estão no passo), a proporção de transações rejeitadas devido aos limites.
• A variação de «vitrine vs cálculo» em cheque-out (onde ocorre o débito real).

• FX maior que SLA, aumento de erros de arredondamento, aumento de falhas PSP em limites.
• Inadequação entre o mínimo RGS e o mínimo vitral.

12) Complaens, impostos e residency

Per currency ≠ per country: Acompanhe a combinação 'currency + geo + license'.
Regras fiscais/fee - na política da moeda e no cheque.
Residency: dados e cálculos para moedas locais - na região apropriada.

13) Testes

Property-based: invariante «após converter e arredondar o preço está no passo»; «min ≤ value ≤ max».
Golden-cases: conjunto de moedas de referência/price para regressão.
Chaos FX: cursos «salteadores», freeze windows, mudar de provedor FX.
E2E: O valor da fatura na vitrine e o valor final descontado; tolerance ≤ 0. 01 unidades de moeda (ou 1 etapa).

14) Erros típicos

Contar para voar na API leitura → X instável e p99 alto.
Ignorar etapas de moedas (CLP/JPY) → «meia cópia» e rejeições RGS/PSP.
Arredondar «por hábito» (bankers rounding) em vez de regras claras per policy.
Não fixar a versão FX no cheque → não é possível analisar as disputas.
Um único bónus por FX → números «estranhos» para os mercados locais.
Esconder comissões em FX sem transparência - risco de reclamações e multas.

15) Receitas rápidas

Apostas em TRY/BRL: passo ₺1/R $0. 50, min. aposta em arredondar para cima para o passo, «belos» pontos de price para pacotes.
Crypto (USDT/USDC): passo $0. 10, arredondar para o passo mais próximo, falta de comissão na exibição (mas visível no cheque).
High-volativity FX: freeze para jogo/promoção; alertas de desvio> X% do price básico.
Multi Tenant: Diferentes passos em marcas; fairness em cálculos de projeções per tenant.

16) Exemplo de configuração (origem única da verdade)

yaml catalog_currency:
base_currency: EUR fx_sla_ms: 300000 # 5 minutes rules:
- currency: "TRY"
stake_step: 1. 00 stake_min: 5. 00 display_round: "ceil_to_step"
psychological_points: [9, 19, 29, 49, 99]
psp_methods: ["Mefete","Papara","Crypto"]
- currency: "BRL"
stake_step: 0. 50 stake_min: 1. 00 display_round: "ceil_to_step"
psychological_points: [4. 90, 9. 90, 19. 90, 49. 90]
psp_methods: ["PIX","Boleto","Cards"]
- currency: "CLP"
stake_step: 50 stake_min: 200 display_round: "ceil_to_step"
psp_methods: ["WebPay","Cards"]
jackpot:
display_policy:
EUR: "nearest_100"
MXN: "nearest_1000"
bonuses:
welcome:
EUR: {amount: 100, wager_x: 35}
BRL: {amount: 500, wager_x: 40}
TRY: {amount: 2500, wager_x: 40}

17) Folha de cheque antes de vender

• Moeda de base única e versão FX em cada cheque/evento.
• As políticas de arredondamento/passos/limites são definidas per currency e são cobertas por testes.
• As projeções do catálogo per currency estão prontas; o caminho quente não faz conversões.
• Jackpots e bónus são corretamente exibidos/gota per currency.
• Os métodos PSP são filtrados por moeda; os limites correspondem à vitrine.
• SLA frescura FX e alertas estão configurados; freeze windows para eventos voláteis.
• Localização de números e caracteres de moedas; modelos de promo sem hardcod.
• Auditoria de alterações de políticas/FX; Reprodução do cheque.
• Multi-tenante/região: isolamento de dados, variação de spraads e limites.
• Playbooks de incidentes: salto FX, inadequação do mínimo RGS, falha nos limites PSP.

Conclusão

Os catálogos per currency são uma disciplina de engenharia, não «multiplicar por curso». Divida o valor e a representação, centralize o FX e as políticas de arredondamento, materialize as projeções per currency e mede o frescor. Então a vitrine será rápida, previsível e honesta, e os negócios estão protegidos contra perdas ocultas de margens e surpresas regulatórias nos mercados locais.