Podłogi i kaskady

1) Podstawa koncepcyjna

Podsprzedawca jest podmiotem prawnym, który akceptuje płatności za pośrednictwem głównego handlowca/dostawcy (platforma/platforma/operator). Przepływy pieniężne trafiają do głównego konta MID/platformy, a następnie platforma płaci subskrybentowi (split/sweep).

Cascading jest strategią sekwencyjnego lub równoległego trasowania transakcji przez kilka PSP/nabywców/MID zgodnie z zasadami (GEO, BIN, taryfa, ryzyko, ładunek) w celu zwiększenia autoryzacji i zmniejszenia kosztów.

Platforma Payل-model jako „mini-acquirer”: wejście na pokład subskrybenta (KYB/PCI), przypisanie subMID, jednolite zasady KYC/AML i spory, scentralizowane rozliczenia i płatności.

2) Gdzie i kiedy potrzebujesz go w iGaming

Multi-brand/white-label: jeden operator, dziesiątki sub-marek/studios → łatwiejsze do utrzymania MIDs/deskryptorów i raportowania.
Rynek treści: platforma - MoR/Payا, studios - submersibles (revshare, splits).
Wysokie ryzyko/geo-mix: kaskady PSP zmniejszają awarie, wstrząsy wypadkowe i koszty płatności.
Metody lokalne/korytarze płatnicze: musisz wybrać dostawcę w locie i awaryjnym.

3) Obowiązki i role

4) Hierarchia MID i deskryptorów

Master MID (platforma)

Sub-MID └─ przez markę/Geo/metodę

Profile routingu └─ (PSP1 → PSP2... kaskada)

• Oddzielne deskryptory na sub-MID: mniej sporów.
• Oddzielne metody cards/A2A/local według sub-MID dla czystej analizy i kontroli rezerw.
• Profile routingu wersji (v1/v2) dla A/B.

5) Kaskady: Jak budować

5. 1. Roztwór on-the-fly

Przy autoryzacji: wybierz trasę zgodnie z zasadami (GEO, BIN/IIN, marka, karta debetowa/kredytowa, klasa ryzyka, limit PSP, aktualny AR/DR, taryfa/FX, incydenty SLA).

5. 2. Rodzaje kaskad

Kolejne: PSP_A → (miękki spadek) → PSP_B → PSP_C.
Split-traffic:% ruchu do różnych dostawców usług płatniczych do porównania i dekoracji.
Sticky BIN: zabezpieczenie udanej puli BIN dla najlepszego PSP.

5. 3. Ograniczenia

Przeczytaj idempotencję (aby nie podwójnie uchwycić).
Zgadzam się z PSP w sprawie wielokrotnych prób (powtórne okno, miękkie kody).
Rozważenie zmiany polityki 3DS i odpowiedzialności na każdej trasie.

6) Rozliczenia, T + N, rezerwy i podziały

Każdy PSP/nabywca posiada własną rezerwę odcięcia/T + N oraz własną rezerwę kroczącą.
Platforma agreguje wpływy na poziomie podśrodkowym i utrzymuje księgę rezerwową z kalendarzem uwolnienia.
Płatności na rzecz subkontyngentów: bez opłat i rezerwy + ich udział (revshare/CPA) za okres sprawozdawczy.
Podział wsparcia według transakcji (platforma/studio/affiliate/tax) lub według artykułu według okresu.

7) Antyfraud, 3DS i limity na poziomie podskarbiego handlowca

Różne progi punktowe dla klas A/B/C rynków.
Zasady 3DS dla BIN/geo/check (obowiązkowe/miękkie/stopniowe).
Limity prędkości (wejście/wyjście, próby kart) i czapki przez zanurzenie.
„Szary” substandard: bardziej rygorystyczne limity, tylko białe metody i odroczone płatności.

8) Taryfy i stawka odbioru

Zastanów się nad skuteczną szybkością odbioru przez submerchant: opłaty PSP (interchange/scheme/markup/fixed) + FX slippage + share platform + reserve-effect.
Użyj IC++ i BIN-routing w celu zmniejszenia mieszanych kosztów w kaskadzie.

9) Dane i minimalny model

sql
-- Directories
CREATE TABLE ref. submerchants (
sub_id    BIGSERIAL PRIMARY KEY,
legal_name  TEXT, brand TEXT, country TEXT, risk_class TEXT, status TEXT,
created_at TIMESTAMP, meta JSONB
);

CREATE TABLE ref. routing_profiles (
profile_id BIGSERIAL PRIMARY KEY,
name TEXT, version TEXT, enabled BOOLEAN, meta JSONB
);

CREATE TABLE ref. routing_rules (
rule_id BIGSERIAL PRIMARY KEY,
profile_id BIGINT REFERENCES ref. routing_profiles,
method TEXT, geo TEXT, bin_from TEXT, bin_to TEXT,
psp TEXT, mid TEXT, require_3ds BOOLEAN,
priority INT, soft_codes JSONB, enabled BOOLEAN, meta JSONB
);

-- Transactions linked to a sub-merchant and a route
CREATE TABLE payments. transactions (
id BIGSERIAL PRIMARY KEY,
sub_id BIGINT REFERENCES ref. submerchants,
profile_id BIGINT, rule_id BIGINT,
provider TEXT, mid TEXT, method TEXT, brand TEXT,
status TEXT, decline_code TEXT,
amount_original NUMERIC(18,6), currency_original TEXT,
amount_reporting NUMERIC(18,6), reporting_currency TEXT,
fx_reference_rate NUMERIC(18,10), fx_effective_rate NUMERIC(18,10),
authorized_at TIMESTAMP, captured_at TIMESTAMP, settled_at TIMESTAMP, funded_at TIMESTAMP,
user_id BIGINT, country_player TEXT, bin TEXT, three_ds_used BOOLEAN,
idempotency_key TEXT UNIQUE, meta JSONB
);

-- Phi and reserves for sub-merchant/provider/period
CREATE TABLE finance. settlement_fees (
sub_id BIGINT, provider TEXT, mid TEXT,
period_start TIMESTAMP, period_end TIMESTAMP,
interchange_amt NUMERIC, scheme_amt NUMERIC, markup_amt NUMERIC,
auth_amt NUMERIC, refund_amt NUMERIC, cb_amt NUMERIC, gateway_amt NUMERIC,
fx_spread_amt NUMERIC, reserve_delta NUMERIC, total_fees NUMERIC, currency TEXT
);

CREATE TABLE finance. reserve_ledger (
id BIGSERIAL PRIMARY KEY,
sub_id BIGINT, provider TEXT, mid TEXT,
hold_date DATE, release_due_date DATE,
hold_amount NUMERIC, released_amount NUMERIC,
cb_consumed NUMERIC, fines_consumed NUMERIC,
status TEXT, meta JSONB
);

-- Submerchant payments
CREATE TABLE payouts. submerchant_settlements (
sub_id BIGINT, period_start TIMESTAMP, period_end TIMESTAMP,
gross_sales NUMERIC, refunds NUMERIC, chargebacks NUMERIC,
fees_total NUMERIC, reserve_delta NUMERIC, revshare NUMERIC,
net_payable NUMERIC, currency TEXT, paid_at TIMESTAMP, statement_ref TEXT
);

10) szablony SQL

10. 1. Efektywny koszt za zanurzenie

sql
SELECT t. sub_id,
SUM(t. amount_reporting) AS volume_rep,
SUM(f. total_fees)    AS fees_rep,
100. 0 SUM(f. total_fees) / NULLIF(SUM(t. amount_reporting),0) AS take_rate_pct
FROM payments. transactions t
JOIN finance. settlement_fees f
ON f. sub_id=t. sub_id
AND t. settled_at BETWEEN f. period_start AND f. period_end
WHERE t. settled_at BETWEEN:from AND:to
GROUP BY 1
ORDER BY take_rate_pct DESC;

10. 2. Wydajność kaskadowa (AR/DR) z reguły

sql
SELECT r. profile_id, r. psp, r. mid,
COUNT() FILTER (WHERE t. status='APPROVED') AS approvals,
COUNT() FILTER (WHERE t. status='DECLINED') AS declines,
ROUND(100. 0 COUNT() FILTER (WHERE t. status='APPROVED') / NULLIF(COUNT(),0), 2) AS ar_pct
FROM payments. transactions t
JOIN ref. routing_rules r ON r. rule_id=t. rule_id
WHERE t. authorized_at BETWEEN:from AND:to
GROUP BY 1,2,3
ORDER BY ar_pct DESC;

10. 3. Saldo rezerwowe według submerchant

sql
SELECT sub_id,
SUM(hold_amount - released_amount - cb_consumed - fines_consumed) AS reserve_balance
FROM finance. reserve_ledger
WHERE hold_date <=:as_of
GROUP BY 1;

10. 4. Rozliczenie płatne netto

sql
SELECT s. sub_id,
SUM(s. gross_sales - s. refunds - s. chargebacks
- s. fees_total + s. reserve_delta - s. revshare) AS net_payable
FROM payouts. submerchant_settlements s
WHERE s. period_start >=:from AND s. period_end <:to
GROUP BY 1;

11) Deski rozdzielcze i KPI

AR/DR według kaskady: według GEO/BIN/metoda/PSP, udział 3DS, udział miękkiego spadku.
Bierz% i składnik opłaty stosu przez submerchant.
Współczynnik CB/stawka zwrotu za submid.
Saldo rezerwy & Uwolnienie ETA przez Submerchant/PSP.
Rozliczenie SLA: T + N hit-rate, opóźnienia finansowania.
Payout Health: częstotliwość i kwoty płatności na rzecz podchorążych, opóźnienia.
FX Slippage w kaskadach (skuteczny vs reference).

12) Wpisy i progi

Routing Degradacja: Fall AR> Y bps godzina-godzina z reguły.
CB Spike: Wzrost obciążenia zwrotnego subskrybenta> X bps w/w.
Brak równowagi rezerwowej: Rezerwowy Ledger Fails - P1.
Opóźnienie rozliczenia: naruszenie PSP T + N → automatyczny przełącznik w kaskadzie.
Spike Take-Rate: wzrost kosztów> próg (opłaty lub FX).
Drift polityki: transakcje bez wiązania z profilem/regułą/idempotencją - P1.
Opóźnienie wypłaty: opóźnienie płatności na rzecz subskrybenta> SLA.

13) Zgodność na pokładzie i podwykonawca

ESC/sankcje/REP: pakiety dokumentów, beneficjenci, źródła funduszy.
PCI/bezpieczeństwo: tokenizacja, zakaz przechowywania PAN u subskrybenta.
Zasady zwrotu/premii: jednolite standardy, bilety SLA.
Raportowanie zagregowane: oddzielnie według marki, geo, metod.
Limity/pułapy: dzienne/tygodniowe obroty, pułapy wypłat, odroczone spłaty z tytułu wysokiego ryzyka.

14) Najlepsze praktyki (krótkie)

1. Profile routingu wersji i przechowywanie wyjaśniają dzienniki decyzji.
2. Trzymaj lepki BIN i A/B PSP testy na stabilność i cenę AR.
3. Opłaty za mapowanie/FX/rezerwacja na poziomie subskrybenta; uiszczenie opłat netto od SLA.
4. Idempotence + retry-policy tylko przez miękki spadek; są zgodne z limitami PSP.
5. Deskryptory i subMID są unikalne dla marki/geo: mniej sporów.
6. Księga rezerwowa z kalendarzem wydania i powiadomieniami o nieuwolnieniu.
7. Przejrzyste raporty dla subskrybenta: opłaty dekodujące, rezerwy, FX, spory.
8. Playbooks failover: PSP/corridor drop - instant reroute.

15) Lista kontrolna wdrażania

• Katalogi 'submerchants', 'routing _ profiles', 'routing _ rules'.
• Protokoły KYB/KYC/AML i przechowywanie stanu.
• Router z idempotencją i logiką miękkiego spadku.
• Importuj pliki rozrachunku PSP → „rozliczenie _ opłaty” + księga rezerwowa.
• Mechanizm wypłat dla podwykonawców + akty prawne/statuty.
• Deski rozdzielcze AR/DR/CB/opłaty/rezerwy + wpisy.
• Dokumenty: Zasady sporu, Zasady 3DS, Limity i SLA.

Podsumowanie

Zanurzenie zapewnia skalę i elastyczność, a kaskady zapewniają stabilność, konwersję i możliwy do opanowania koszt. Architektura z hierarchii MIDs, wersjonowane profile routingu, przejrzyste rachunkowość opłat/rezerw i ścisła zgodność przekształca złożoną pętlę płatniczą multi-GEO w przewidywalny system: wysoką autoryzację, niski wskaźnik odbioru, szybkie płatności i minimalne zaskoczenie ryzykiem.