Verzeichnisse pro Währung

Der Per-Currency-Katalog ist eine Variante des Content- und Pricing-Katalogs, bei dem die angezeigten Preise, Limits, Boni, Mindesteinsätze, Jackpots und Promo-Texte an die Währung des Spielers/Tenants/der Region angepasst werden. Ziel ist es, die richtigen Preispunkte und Regeln ohne Copypass der Logik und ohne Risiken durch On-the-fly-Conversions zu geben.

• UX: Natürliche Wettschritte und „schöne“ Preise (₺9. 99, R$5, €0. 20).
• Einnahmen: Genaue Grenzen und Boosts ohne „Fressen“ der Marge aufgrund der Kurse.
• Compliance: Einhaltung lokaler Vorschriften (Lizenzen, Steuern, Alter/Geo).

1) Datenmodell: Wir teilen „Bezeichnung“ und „Darstellung“

Basispreis (Nennwert): Einheitliche Landeswährung „PLN “/„ EUR “/„ USD“ für Abrechnungen.
Anzeige Preis (Darstellung): berechnet aus Stückelung + FX + Rundung + Aufschläge/Rabatte (Spread/Fees).
Richtlinien: Rundungsregeln, Wettschritte, Min/Max-Limits, Jackpots, Bonusbeträge und Wager - per Währung konfigurierbar.

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) Kursquelle (FX) und „Frische“

• Anbieter von Kursen: Haupt- und Standby; Aktualisierungsrate (z. B. jede Minute für volatil, alle 15 Minuten für stabil).
• Bounded staleness: SLA „Kurse nicht älter als Δ t“ (z.B. p95 ≤ 5 min).
• Spread und Gebühren: konfigurierbar per tenant/region/currency.
• Freeze-Fenster: „Einfrieren“ von Kursen für Match/Turnier/Promo-Fenster, damit der Preis nicht „springt“.
• Audit: Logversionen von FX mit 'valid _ from/valid _ to', um Schecks wiederzugeben.

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) Rundung und „schöne“ Preispunkte

• Preise/Pakete: '99', '9. 99`, `4. 90'(psychologische Punkte).
• Wetten und Schritte: „ceil_to_step“ zum Währungsschritt (₺1 CLP $50).
• Boni: Rundung nach unten zum Gutschein-Schritt (R $1/ ₺5).
• Die Reihenfolge der Operationen: 'raw = base fx (1 + spread) (1 + fee)' → 'rounded = round_policy (raw)' → 'min/max clamp'.

Anti-Beispiel: „Bank-Rundung“ für Wetten kann „hässliche“ Schritte geben - verwenden Sie explizite Richtlinien.

4) Limits, Min/Max und Jackpots

Min/Max per currency: Berücksichtigen Sie lokale Gesetze und RGS-Beschränkungen.
Jackpots: Wenn der Anbieter den Jackpot in seiner Währung (z. B. EUR) hält, zeigen Sie entweder ein lokalisiertes Äquivalent (Informer) oder speichern Sie Per-Währungspools.
Währungsschritte: CLP/JPY ohne Kopeken - alle Limits sind ganzzahlig.

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) Boni und Gutscheine pro Währung

Bonuswert: Pro Währung konfigurierbar (keine „Neuberechnung“ per Kopf).
Wager: als Multiplikator (x30) oder als Betrag in einer Währung speichern; Vermeiden Sie Verwechslungen.
Gewinn Cap/Cash Out: auch per Währung.
Marketing-Texte: Lokalisierung von Zahlen und Währung in Vorlagen ohne 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) Einschränkungen der Anbieter (RGS/PSP)

RGS: Einige Spiele sind nicht für 'crypto '/lokale Währungen verfügbar; Einige Anbieter verlangen feste Mindestbeträge (z.B. 0 €. 20).
PSP: Zahlungsmethoden hängen von der Währung ab (PIX ↔ BRL, PayID ↔ AUD, Papara ↔ TRY); Einzahlungs-/Auszahlungslimits sind ebenfalls unterschiedlich.
Regel: Katalog/Schaufenster filtern Spiele und Zahlungsmethoden nach Währung und Gerichtsbarkeit vor der Show.

7) Architektonischer Umriss

Currency Policy Store (CP): Regeltabellen pro Währung (Schritte, Limits, Preispunkte, Rundungen).
FX-Service: Kurs-Cache, Versionen und Frische SLA.
Katalogbildner: erzeugt Lesemodelle pro Währung (Projektionen).
Lese-Layer-API: zieht fertige Projektionen; keine On-the-fly-Konvertierungen im Hot-Way-UI.
Outbox → Projektionen: FX/Policy-Änderungen → Ereignisse' CurrencyPolicyUpdated/FXUpdated '→ inkrementelle Schaufensterupdates.

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

Die Partitionierung nach Währung beschleunigt das Refresh und das Sammeln von Metriken.

8) Projektionen pro Währung (Beispiel)

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

Updates - idempotente' UPSERTs' aus Verzeichnisereignissen + FX-Ereignissen/Richtlinien.

9) Formatierung und Locals

Symbol/Code: „₺/TRY“, „R $/BRL“, „€“, „USDT“ (für Krypto - ohne Kopeken oder mit 2 Zeichen, gemäß der UX-Politik).
Gruppierung und Dezimaltrennzeichen: abhängig von 'locale' (ru_RU, tr_TR, pt_BR).
RTL/arab locales: separate Prüfung auf Richtigkeit des Währungszeichens.

10) Caching und Leistung

Katalogantworten pro Währung zwischenspeichern 30-120 s; FX-Indikator 'as _ of' geben in der Antwort.
Behinderung: 'FXUpdated '/' PolicyUpdated '/' GameUpserted' -Ereignisse → gezielte Cache-Schlüsselbereinigung.
Paginierung mit Cursors, damit die Reihenfolge der Karten bei kleinen Updates des Preises nicht „springt“.

11) Beobachtbarkeit und SLO

• `catalog_p95_ms` по валютам, `fx_freshness_ms` (p50/p95/p99), `policy_refresh_latency_ms`.
• Anteil der „hässlichen“ Preise (liegen nicht im Schritt), Anteil der abgelehnten Transaktionen aufgrund von Limits.
• Die Diskrepanz „Schaufenster vs Berechnung“ auf dem Check-out (wo die tatsächliche Belastung stattfindet).

• FX ist älter als SLA, ein Anstieg der Rundungsfehler, ein Anstieg der PSP-Bounces bei den Limits.
• Diskrepanz zwischen RGS-Minimum und Display-Minimum.

12) Compliance, Steuern und Residency

Per currency ≠ per country: Achten Sie auf die Kombination 'currency + geo + license'.
Steuerregeln/Gebühr - in der Währungspolitik und im Scheck.
Residency: Daten und Berechnungen für lokale Währungen - in der jeweiligen Region.

13) Testen

Property-based: Invariante „nach Umrechnung und Rundung liegt der Preis im Schritt“; «min ≤ value ≤ max».
Golden-cases: eine Reihe von Referenzwährungen/Preisen für die Regression.
Chaos FX: „Jumping“ -Kurse, Freeze-Fenster, FX-Anbieterumschaltung.
E2E: Matchfähigkeit der Summe auf der Vitrine und der abgeschriebenen Summe; Tolerance ≤ 0. 01 Währungseinheiten (oder 1 Schritt).

14) Typische Fehler

Im laufenden Betrieb in der Lese-API neu berechnen → instabile UX und hohe p99.
Ignorieren Sie die Schritte der Währungen (CLP/JPY) → „halbe Pfeile“ und RGS/PSP-Ausfälle.
Abrundung „aus Gewohnheit“ (bankers rounding) statt klarer Regeln per Richtlinie.
Es ist nicht möglich, die FX-Version im Scheck zu fixieren → Streitigkeiten zu zerlegen.
Einheitliche Bonuswerte über FX → „seltsame“ Zahlen für lokale Märkte.
Provisionen in FX ohne Transparenz zu verstecken, ist das Risiko von Ansprüchen und Strafen.

15) Schnelle Rezepte

Wetten in TRY/BRL: Schritt ₺1/R $0. 50, min-Wette nach oben zum Schritt gerundet, „schöne“ Preispunkte für Pakete.
Crypto (USDT/USDC): Schritt $0. 10, Rundung zum nächsten Schritt, keine Provisionen im Display (aber sichtbar im Check).
Hohe Volatilität FX: Freeze pro Spiel/Promo; Alerts bei einer Abweichung von> X% vom Basispreis.
Multi-Tenant: unterschiedliche Spreads/Schritte bei Marken; fairness in Projektionsberechnungen per tenant.

16) Beispielkonfiguration (Single Source of Truth)

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) Checkliste vor dem Verkauf

• Einheitliche Basiswährung und FX-Version in jedem Scheck/Ereignis.
• Rundungs-/Schritt-/Grenzrichtlinien werden per Währung festgelegt und durch Tests abgedeckt.
• Die Projektionen des Katalogs pro Währung sind fertig; der heiße Weg macht keine Konvertierungen.
• Jackpots und Boni werden korrekt angezeigt/per currency geträufelt.
• PSP-Methoden werden nach Währungen gefiltert; Die Limits stimmen mit dem Schaufenster überein.
• Frische FX SLA und Alerts angepasst; Freeze-Fenster für volatile Ereignisse.
• Lokalisierung von Zahlen und Symbolen von Währungen; Promo-Vorlagen ohne Hardcode.
• Überprüfung von Richtlinienänderungen/FX; Reproduzierbarkeit des Schecks.
• Multi-Tenant/Region: Datenisolation, unterschiedliche Spreads und Limits.
• Incident Playbooks: FX-Sprung, RGS-Minimum inkonsistent, PSP-Limits fehlgeschlagen.

Schlussfolgerung

Kataloge pro Währung sind eine Ingenieurdisziplin und nicht „multiplizieren mit Kurs“. Trennen Sie Nennwert und Darstellung, zentralisieren Sie FX- und Rundungsrichtlinien, materialisieren Sie Projektionen pro Währung und messen Sie die Frische. Dann wird das Schaufenster schnell, vorhersehbar und ehrlich sein, und das Geschäft ist vor versteckten Margenverlusten und regulatorischen Überraschungen in lokalen Märkten geschützt.