Catalogues per currency

Le catalogue per currency est une variante du catalogue de contenu et de prix où les prix affichés, les limites, les bonus, les taux minimaux, les jackpots et les textes promotionnels sont adaptés à la monnaie du joueur/tenant/région. L'objectif est de donner les bons prix et règles sans logique et sans risques à cause des conversions à la volée.

• UX : pas de paris naturels et prix « beaux » (₺9. 99, R$5, €0. 20).
• Revenus : limites précises et boosts sans marge de « passage » en raison des cours.
• Conformité : conformité aux réglementations locales (licences, taxes, age/geo).

1) Modèle de données : nous partageons « nominal » et « représentation »

Prix de base (nominal) : monnaie intérieure unique 'PLN'/' EUR '/' USD'pour les paiements.
Prix d'affichage (représentation) : calculé à partir de la valeur nominale + FX + arrondi + majoration/remise (spread/fees).
Politique : règles d'arrondi, étapes de mise, limites min/max, jackpots, montants de bonus et wager - personnalisable par 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) Source des cours (FX) et « fraîcheur »

• Fournisseur de cours : principal et de réserve ; taux de rafraîchissement (par exemple, toutes les minutes pour les volatiles, toutes les 15 minutes pour les stables).
• Bounded staleness : SLA "cours de moins de Δ t' (p. ex. p95 ≤ 5 min).
• Spread et commissions : sont configurés per tenant/region/currency.
• Freeze windows : « geler » les cours pour le match/tournoi/fenêtres promotionnelles afin que le prix ne « saute » pas.
• Audit : journal des versions FX avec 'valid _ from/valid _ to' pour lire les chèques.

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) Arrondir et « beau » prix points

• Prix/forfaits : '99', '9. 99`, `4. 90 '(points psychologiques).
• Taux et étapes : « ceil_to_step » à l'étape de change (₺1, CLP $50).
• Bonus : arrondir vers le bas à l'étape du bon (R $1/ ₺5).
• Ordre des opérations : 'raw = base fx (1 + spread) (1 + fee)' → 'rounded = round_policy (raw)' → 'min/max clamp'.

Anti-exemple : un « arrondi bancaire » pour les paris peut donner des étapes « laides » - utilisez des politiques explicites.

4) Limites, min/max et jackpots

Min/Max per currency : prennent en compte les lois locales et les restrictions RGS.
Jackpots : si le fournisseur détient un jackpot dans sa monnaie (par exemple, EUR), montrez soit un équivalent localisé (informateur), soit stockez des pools de devises.
Étapes de la monnaie : CLP/JPY sans centimes - toutes les limites sont entières.

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) Bonus et bons per currency

Prime nominale : configurable per currency (pas « recalculer » sur le front).
Wager : stocker comme multiplicateur (x30) ou comme montant dans la monnaie ; éviter le mélange.
Cape de gain/cache-out : aussi per currency.
Texte marketing : localisation des nombres et monnaie dans les modèles sans hardcode.

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) Restrictions des fournisseurs (RGS/PSP)

RGS : certains jeux ne sont pas disponibles pour les monnaies 'crypto '/locales ; certains fournisseurs exigent des minima fixes (par exemple 0 €). 20).
PSP : les méthodes de paiement dépendent de la monnaie (PIX ↔ BRL, PayID ↔ AUD, Papara ↔ TRY) ; les limites de dépôt/retrait sont également différentes.
Règle : le catalogue/vitrine filtre les jeux et les modes de paiement par devise et juridiction avant l'affichage.

7) Contour architectural

Currency Policy Store (CP) : tables de règles per currency (étapes, limites, points de prix, arrondis).
Service FX : cache de cours, versions et SLA de fraîcheur.
Catalogue-builder : produit des modèles de lecture per currency (projections).
API couche de lecture : tire les projections prêtes ; pas de conversion on-the-fly dans la voie chaude UI.
Outbox → Projections : modifications FX/stratégies → événements 'CurrencyPolicyUpdated/FXUpdated' → apdates incrémentielles de vitrines.

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

Le lot par devise accélère le refresh et la collecte des métriques.

8) Projections per currency (exemple)

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)
);

Mises à jour - idempotent 'UPSERT' des événements du catalogue + événements FX/stratégies.

9) Formatage et local

Symbole/code : '₺/TRY', 'R $/BRL', '€', 'USDT' (pour la crypto - pas de centimes ou avec 2 signes, selon la politique UX).
Groupe et séparateur décimal : dépendent de 'locale' (ru_RU, tr_TR, pt_BR).
RTL/Arabe Locals : vérification séparée de l'exactitude de la marque de monnaie.

10) Mise en cache et performances

Les réponses de catalogue per currency mettre en cache 30-120 s ; Donnez l'indicateur FX 'as _ of' dans la réponse.
Invalidation : événements 'FXUpdated '/' PolicyUpdated '/' GameUpserted' → un nettoyage ciblé des clés de cache.
Pagination par les curseurs pour que l'ordre des cartes ne « saute » pas à de petites apdaces de prix.

11) Observabilité et SLO

• `catalog_p95_ms` по валютам, `fx_freshness_ms` (p50/p95/p99), `policy_refresh_latency_ms`.
• La part des prix « méchants » (ne sont pas à l'étape), la part des transactions rejetées en raison des limites.
• Divergence « vitrine vs calcul » sur le chèque-out (où se produit le débit réel).

• FX est plus vieux que SLA, augmentation des erreurs d'arrondi, augmentation des pannes PSP selon les limites.
• Incohérence du minimum RGS et du minimum vitrine.

12) Conformité, taxes et résidence

Per currency ≠ per country : suivez la combinaison 'currency + geo + license'.
Règles fiscales/fee - dans la politique de la monnaie et dans le chèque.
Résidence : données et calculs pour les monnaies locales - dans la région concernée.

13) Tests

Property-based : invariant « après conversion et arrondi, le prix est à l'étape » ; «min ≤ value ≤ max».
Golden-cases : jeu de devises/prix de référence pour la régression.
Chaos FX : cours « sauter », freeze windows, changement de fournisseur FX.
E2E : matchabilité du montant sur la vitrine et du montant total débité ; tolerance ≤ 0. 01 unités de monnaie (ou 1 étape).

14) Erreurs typiques

Recalculer à la volée dans l'API de lecture → UX instable et p99 élevé.
Ignorer les étapes des monnaies (CLP/JPY) → les « demi-centimes » et les pannes RGS/PSP.
Arrondir « par habitude » (bankers rounding) au lieu de règles per policy claires.
Ne pas enregistrer la version FX dans le chèque → impossible de résoudre les différends.
Des nombres de bonus uniques via FX → des nombres « étranges » pour les marchés locaux.
Cacher les commissions dans FX sans transparence est un risque de réclamations et d'amendes.

15) Recettes rapides

Paris en TRY/BRL : Étape ₺1/R $0. 50, mise min arrondir vers le haut de l'étape, « beau » prix points pour les paquets.
Crypto (USDT/USDC) : étape 0 $. 10, arrondi à l'étape la plus proche, pas de commissions dans l'affichage (mais visible dans le chèque).
Haute volatilité FX : freeze pour le match/promo ; alerte à l'écart> X % du prix de base.
Multi-tenant : différents sprades/étapes chez les marques ; fairness dans les calculs des projections per tenant.

16) Exemple de configuration (source unique de vérité)

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) Chèque-liste avant la vente

• La monnaie unique de base et la version FX de chaque chèque/événement.
• Les politiques d'arrondi/étape/limite sont définies par per currency et sont couvertes par des tests.
• Les projections du catalogue per currency sont prêtes ; le chemin chaud ne fait pas de conversions.
• Jackpots et bonus sont correctement affichés/captés per currency.
• Les méthodes PSP sont filtrées par monnaie ; les limites correspondent à une vitrine.
• SLA de la fraîcheur FX et alerta personnalisés ; freeze windows pour les événements volatils.
• Localisation des chiffres et symboles des monnaies ; les modèles sont promotionnels sans hardcode.
• Vérification des changements de politiques/FX ; reproductibilité du chèque.
• Multi-tenant/région : isolation des données, sprades et limites différentes.
• Pleybooks incidents : saut FX, incohérence du minimum RGS, échec des limites PSP.

Conclusion

Les catalogues per currency sont une discipline d'ingénierie, pas de « multiplier par un cours ». Diviser la valeur nominale et la représentation, centraliser les politiques de FX et d'arrondi, matérialiser les projections per currency et mesurer la fraîcheur. La vitrine sera alors rapide, prévisible et honnête, et les entreprises seront protégées contre les pertes de marge cachées et les surprises réglementaires sur les marchés locaux.