წყალქვეშა ნავები და კასკადები

1) კონცეპტუალური ბაზა

წყალქვეშა ნავი არის იურიდიული პირი, რომელიც იღებს გადახდებს მთავარი მიმწოდებლის/პროვაიდერის მეშვეობით (PayFac/პლატფორმა/ოპერატორი). ფულადი ნაკადები მიდის მასტერ MID/პლატფორმის ანგარიშზე, შემდეგ პლატფორმა იხდის წყალქვეშა ნავს (split/sweep).

კასკადი (კასკადი) არის გარიგების თანმიმდევრული ან პარალელური როუტინგის სტრატეგია რამდენიმე PSP/შეძენის/MID- ის მეშვეობით წესების მიხედვით (GEO, BIN, ტარიფი, რისკი, დატვირთვა) ავტორიზაციის გაზრდისა და ღირებულების შემცირების მიზნით.

PayFac მოდელი - პლატფორმა, როგორც „მინი შემქმნელი“: წყალქვეშა ონბორდის (KYB/PCI), ქვე-MID- ის მინიჭება, KYC/AML- ის ერთიანი წესები და დავები, ცენტრალიზებული settlement და გადახდები.

2) სად და როდის არის საჭირო iGaming

მულტიბრენდი/თეთრი-ლაბელი: ერთი ოპერატორი, ათობით ქვე-ბრენდი/სტუდია უფრო ადვილია MIDs/აღწერისა და ანგარიშგების ჩატარება.
შინაარსის ბაზარი: პლატფორმა - MoR/PayFac, სტუდიები - წყალქვეშა ნავები (revshare, სპლიტები).
მაღალი რისკი/გეო მიქსი: PSP- ის კასკადები ამცირებს უარის თქმას, ინციდენტებზე შოკს და გადახდის ღირებულებას.
ადგილობრივი გადახდის მეთოდები/დერეფნები: თქვენ გჭირდებათ პროვაიდერის არჩევანი ფრენისთვის და fallback.

3) პასუხისმგებლობა და როლები

4) MID- ის იერარქია და აღწერილობები

MID ოსტატი (პლატფორმა)

Sub-MID (s) ბრენდის/გეო/მეთოდების გამოყენებით

└─ Routing Profiles (PSP1→PSP2… კასკადი)

• ცალკეული აღწერილობა ქვე-MID: ნაკლები დავა.
• გააზიარეთ ბარათები/A2A/ადგილობრივი ქვე-MID მეთოდები სუფთა ანალიტიკისა და სარეზერვო კონტროლისთვის.
• ვერსია routing პროფილები (v1/v2) A/B.

5) კასკადები: როგორ ავაშენოთ

5. 1. გადაწყვეტილება „ფრენაზე“

ავტორიზაციის დროს: შეარჩიეთ მარშრუტი წესების შესაბამისად (GEO, BIN/IIN, ბრენდი, debit/credit ბარათი, რისკის კლასი, PSP ლიმიტი, მიმდინარე AR/DR, ტარიფი/FX, SLA ინციდენტები).

5. 2. კასკადის ტიპები

თანმიმდევრული: PSP _ A (რბილი decline), PSP _ B, PSP _ C.
პარალელური (split-traffic): სხვადასხვა PSP- ზე ტრეფიკის% ბენჩმარკინგისა და დეკორაციისთვის.
Sticky BIN: წარმატებული BIN აუზის კონსოლიდაცია საუკეთესო PSP- სთვის.

5. 3. შეზღუდვები

განიხილეთ idempotence (ისე, რომ არ შეავსოთ capture).
განმეორებითი მცდელობების კოორდინაცია PSP- სთან (retry window, რბილი კოდები).
თითოეულ მარშრუტზე გაითვალისწინეთ 3DS პოლიტიკა და შეზღუდვა.

6) Settlement, T + N, რეზერვები და დანაყოფები

თითოეულ PSP/შემქმნელს აქვს საკუთარი cut-off/T + N და საკუთარი rolling reserve.
პლატფორმა აერთიანებს შემოსავალს ქვე-MID დონეზე და ახორციელებს სარეზერვო-ლედგერს რელეაზის კალენდრით.
სუბმერსანტებისთვის გადახდა: net of fees & reserve + მათი წილი (revshare/CPA) საანგარიშო პერიოდის მიხედვით.
შეინარჩუნეთ დანაყოფები გარიგების მიხედვით (პლატფორმა/სტუდია/affiliate/tax) ან პოსტატეინო პერიოდის მიხედვით.

7) ანტიფროდი, 3DS და ლიმიტები წყალქვეშა დონეზე

სხვადასხვა მორიელი ბარიერი A/B/C ბაზრების კლასებისთვის.
3DS წესები BIN/geo/check- ის მიხედვით (./რბილი/step-up).
Velocity limites (დანართები/დასკვნები, ბარათების მცდელობები) და caps წყალქვეშა.
„ნაცრისფერი“ წყალქვეშა ნავები: უფრო მკაცრი ლიმიტები, მხოლოდ თეთრი მეთოდები და გადავადებული გადახდები.

8) ტარიფები და ტარიფები

ჩაითვალეთ effective take-rate წყალქვეშა ნავზე: PSP fees (intersheme/scheme/barkup/fixed) + FX slippage + პლატფორმის წილი + სარეზერვო ეფექტი.
გამოიყენეთ IC++ და BIN-routing კასკადში ბლენდედის ღირებულების შესამცირებლად.

9) მონაცემები და მინიმალური მოდელი

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) SQL შაბლონები

10. 1. წყალქვეშა ეფექტური ღირებულება

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. კასკადის ეფექტურობა (AR/DR) წესების შესაბამისად

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. წყალქვეშა რეზერვი

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. Net payable წყალქვეშა გაანგარიშება

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) დაშბორდი და KPI

AR/DR კასკადში: GEO/BIN/მეთოდით/PSP, წილი 3DS, რბილი-decline წრე.
Take-Rate% და კომპონენტის წყალქვეშა ნაკადი.
CB Ratio/Refund Rate ქვე-MID.
Reserve Balance & Release ETA წყალქვეშა/PSP.
Settlement SLA: T+N hit-rate, funding delays.
Payout Health: წყალქვეშა ნავებზე გადახდების სიხშირე და ოდენობა, შეფერხებები.
FX Slippage კასკადებში.

12) ალერტები და ბარიერები

Routing Degradation: დაცემა AR> Y bps საათის საათში.
CB Spike: carjbacks- ის ზრდა წყალქვეშა ნავში> X bps w/w.
Reserve Imbalance: სარეზერვო ლეგენდა - P1.
Settlement Delay: T + N დარღვევა PSP- ზე კასკადში.
Take-Rate Spike: ფასის ზრდა> ბარიერი (Fees ან FX).
Policy Drift: გარიგებები პროფილის/rule/idempotency მითითების გარეშე - P1.
Payout Delay: დაგვიანებული გადახდა წყალქვეშა ნავზე> SLA.

13) Onboarding და Commerchants

KUV/სანქციები/REP: დოკუმენტების პაკეტები, ბენეფიციარები, სახსრების წყაროები.
PCI/უსაფრთხოება: ტოკენიზაცია, წყალქვეშა ნავში PAN- ის შენახვის აკრძალვა.
დაბრუნების/პრემიების პოლიტიკოსები: ერთიანი სტანდარტები, SLA ტიკეტები.
საერთო ანგარიში: ცალკეული ბრენდები, გეო, მეთოდები.
ლიმიტები/კაპები: დღის/ყოველკვირეული ბრუნვა, payout-caps, გადავადებული გადახდები მაღალი რანგისთვის.

14) საუკეთესო პრემიები (მოკლედ)

1. შეცვალეთ routing პროფილები და შეინახეთ გადაწყვეტილებების დაფიქსირებული ლოგოები.
2. გამართეთ sticky BIN და A/B PSP ტესტები AR და ფასების სტაბილურობისთვის.
3. Mappit fees/FX/რეზერვი წყალქვეშა დონეზე; გადაიხადეთ net-of-fees SLA- სთვის.
4. Idempotency + retry-policy მხოლოდ რბილი-decline; დაიცავით PSP ლიმიტები.
5. აღწერილობა და ქვე-MIDs უნიკალურია ბრენდის/გეოსთვის: ნაკლები დავა.
6. სარეზერვო ლეჯერი release კალენდრით და ალერტებით missed-release.
7. გამჭვირვალე ცნობები წყალქვეშა ნავზე: fees, reserve, FX, დებატების გაშიფვრა.
8. Failover playbuks: PSP/დერეფნის ვარდნა - მყისიერი reroute.

15) განხორციელების სია

• სახელმძღვანელოები 'suberchants', 'routing _ profiles', 'routing _ rules'.
• KYB/KYC/AML პროტოკოლები და სტატუსის შენახვა.
• როუტერი idempotence და რბილი-decline ლოგიკით.
• settlement ფაილების იმპორტი PSP 'settlement _ fees' + reserve-ledger.
• payouts წყალქვეშა მექანიზმი + აქტები/სტეიტმენტები.
• დაშბორდები AR/DR/CB/fees/reserve + ალერტები.
• დოკუმენტები: დავის პოლიტიკა, 3DS წესები, შეზღუდვები და SLA.

რეზიუმე

წყალქვეშა ნავები იძლევა მასშტაბს და მოქნილობას, ხოლო კასკადები - სტაბილურობას, კონვერტაციას და კონტროლირებად ღირებულებას. MIDs იერარქიის არქიტექტურა, ვერსირებული routing პროფილები, გამჭვირვალე fees/რეზერვების აღრიცხვა და მკაცრი შესაბამისობა რთულ multi-GEO გადახდის წრეს პროგნოზირებულ სისტემად აქცევს: მაღალი საავტორო უფლებები, დაბალი გადასახადი, სწრაფი გადახდები და რისკების მინიმალური სიურპრიზები.