按貨幣分類

按貨幣目錄是內容和價格目錄的一種變體，其中顯示的價格，限額，獎金，最低賭註，頭獎和促銷文本均適合玩家/tenant/地區貨幣。目的是提供正確的價格和規則，而無需邏輯共計，並且由於「即時」轉換而沒有風險。

• UX：自然投註步驟和「美麗」價格（₺9。99, R$5, €0.20).
• 收入：由於課程，沒有利潤率「滲透」的確切限制和助推器。
• 合規性：符合當地規則（許可證、稅收、年齡/地理）。

1）數據模型： 共享「面額」和「表示」

基本價格（面值）：用於結算的單一國內貨幣「PLN」/「EUR」/「USD」。
顯示價格（視圖）：根據+FX+四舍五入+加價/折扣（spread/fees）計算。
政策：四舍五入規則，投註步驟，地雷/最大限額，頭獎，獎金金額和wager-按貨幣調整。

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）課程來源（FX）和「新鮮」

• 課程提供者：主課程和備用課程；刷新率（例如，波動性每分鐘，穩定性每15分鐘）。
• Bounded staleness：SLA「課程不超過Δ t」（例如p95 ≤ 5分鐘）。
• 利差和傭金：可配置per tenant/region/currency。
• Freeze windows：「凍結」比賽/錦標賽/促銷窗口的課程，以便價格不會「跳躍」。
• 審計：帶有「valid_from/valid_to」的FX版本日誌以播放支票。

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）四舍五入和「美麗」的價格便宜

• 價格/套餐：'99'，'9.99`, `4.90'（心理點）。
• 利率和步驟：「ceil_to_step」到貨幣步驟（₺1，中電50美元）。
• 獎金：四舍五入到憑證步驟（R $1/ ₺5）。
• 操作順序：'raw=base fx（1+spread）（1+fee）'→ 'rounded=round_policy （raw）' → 'min/max clamp'。

反例子：利率的「銀行四舍五入」可以產生「醜陋」的步驟--使用明確的政策。

4）限值，min/max和頭獎

Min/Max per currency：考慮當地法律和RGS限制。
頭獎：如果提供商持有其貨幣（如EUR）的頭獎,則顯示本地化等價物（舉報人）或存儲紙幣池。
貨幣步驟：CLP/JPY不帶標記-所有限制都是整數。

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）按貨幣計算的獎金和憑證

獎金面額：按貨幣配置（額頭不是「重新計票」）。
Wager：以乘數（x 30）或貨幣形式存儲；避免混淆。
獲勝帽/緩存：也按貨幣計算。
市場營銷文本：數字本地化和沒有硬碼的模式貨幣。

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）提供商限制（RGS/PSP）

RGS： 某些遊戲不適用於「crypto」/本地貨幣；部分提供商需要固定最低限度（例如,0歐元。20).

PSP：支付方法取決於貨幣（PIX ↔ BRL，PayID ↔ AUD，Papara ↔ TRY）；存款/提款限額也不同。
規則：目錄/陳列櫃在展示前按貨幣和管轄範圍過濾遊戲和付款方式。

7）建築輪廓

貨幣政策商店（CP）：每個貨幣的規則表（步驟、限制、價格、四舍五入）。
FX服務：課程緩存，版本和SLA新鮮度。
制表符目錄：生成Read Models per currency（投影）。
閱讀層API：拉出現成的投影；在UI熱路上不進行飛行轉換。
Outbox →投影：FX/策略更改 → 「CurrencyPolicyUpdated/FXUpdated」事件→增量店面升級。

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

貨幣分期交易加快了refresh和指標收集。

8）按貨幣投影（示例）

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

更新-來自目錄+FX/Policy事件的等效的「UPSERT」。

9）格式和位置

符號/代碼：「₺/TRY」，「R $/BRL」，「USDT」（根據UX政策，對於加密免稅或2個標誌）。
分組和十進制分隔符：取決於「本地」（ru_RU，tr_TR，pt_BR)。
RTL/阿拉伯語地區：對貨幣符號正確性的單獨檢查。

10）緩存和性能

每個貨幣的目錄響應緩存30-120 c；在響應中給出「as_of」 FX指示符。
殘疾：「FXUpdated」/「PolicyUpdated」/「GameUpserted」事件→目標緩存密鑰清除。
分割光標，這樣卡片順序就不會在價格的小升級中「跳躍」。

11）可觀察性和SLO

• `catalog_p95_ms` по валютам, `fx_freshness_ms` (p50/p95/p99), `policy_refresh_latency_ms`.
• 「醜陋」價格的份額（不在步驟中），由於限制而被拒絕交易的份額。
• 支票外部（實際借記發生的地方）的「展示櫃與計算」差異。

• FX比SLA大，四舍五入錯誤增加，PSP故障激增。
• RGS最低限度和店面最低限度的不匹配。

12）合規性，稅收和住所

Per currency ≠ per country：關註「currency+geo+license」的組合。
稅收規則/票據是貨幣政策和支票。
Residency：當地貨幣的數據和結算-在相關區域。

13）測試

基於property： 「轉換和四舍五入後的不變」；«min ≤ value ≤ max».

金價：回歸的參考貨幣/價格集。
Chaos FX：「跳躍」課程，freeze windows，切換FX提供商。
E2E：店面數額和註銷總額之間的對比；tolerance ≤ 0。01個貨幣單位（或1個步驟）。

14）典型錯誤

在閱讀API中即時重新計算→不穩定的UX和高的p99。
忽略貨幣的步驟（CLP/JPY）→「半空白」和RGS/PSP故障。
「按習慣」四舍五入（銀行家回旋）而不是明確的政策規則。
不將FX版本記錄在支票中→無法解決爭議。
通過FX的單一獎勵面額→本地市場的「奇怪」數字。
在不透明的情況下將傭金隱藏在FX中是索賠和罰款的風險。

15）快速食譜

TRY/BRL： Step ₺1/R $0。50、min賭註向上四舍五入，包裹的「美麗」價格。
Crypto （USDT/USDC）： step $0。10、四舍五入到最近的步驟，顯示中沒有傭金（但在支票中可見）。
High-Volatility FX：比賽/促銷的凍結功能；偏差>基本價格的X%時的差異。
多重特南特：品牌的不同爭吵/步驟；fairness在per tenant投影計算中。

16）配置示例（單一真相來源）

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）售前支票清單

• 每個支票/事件中的單一基本貨幣和FX版本。
• 四舍五入/步驟/限制策略是按貨幣設置的，並覆蓋在測試中。
• 已準備好每個貨幣目錄的投影；熱路不進行轉換。
• 大獎和獎金按貨幣正確顯示/滴落。
• PSP方法按貨幣過濾；限值與店面相同。
• FX的新鮮度和Alerts的SLA定制；freeze windows用於波動事件。
• 貨幣數字和符號的本地化；沒有硬碼的促銷模式。
• 策略更改/FX審核；支票的可重復性。
• multi-tenant/Region：數據隔離,不同的傳播和限制。
• 事件花花公子：FX跳躍，RGS最低不匹配，PSP極限故障。

結論

按貨幣目錄是工程學科，而不是「乘以課程」。將面額和表示分開，集中FX和舍入策略，實現按貨幣投影，測量新鮮度。然後，店面將是快速，可預測和誠實的，業務可以防止利潤率的隱性損失和本地市場的監管驚喜。