GH GambleHub

زیر آب و آبشار

1) پایه مفهومی

یک شخص حقوقی است که پرداخت ها را از طریق بازرگان/ارائه دهنده اصلی (PayFac/platform/operator) می پذیرد. جریان های نقدی به حساب استاد MID/پلت فرم می رود، سپس پلت فرم به خرده فروش (تقسیم/رفت و برگشت) پرداخت می کند.

Cascading یک استراتژی مسیریابی معامله متوالی یا موازی از طریق چندین PSP/acquirers/MID با توجه به قوانین (GEO، BIN، تعرفه، خطر، بار) برای افزایش مجوز و کاهش هزینه است.

مدل PayFac - پلت فرم به عنوان «مینی خریدار»: در اختیار داشتن یک خرده بازرگان (KYB/PCI)، تخصیص زیر MID، قوانین یکنواخت KYC/AML و اختلافات، حل و فصل متمرکز و پرداخت.

2) کجا و چه زمانی به iGaming نیاز دارید

چند نام تجاری/برچسب سفید: یک اپراتور، ده ها تن از مارک های زیر/استودیو → آسان تر برای حفظ MIDs/descriptors و گزارش.
بازار محتوا: پلت فرم - MoR/PayFac، استودیو - زیردریایی (revshare، تقسیم).
ریسک بالا/مخلوط جغرافیایی: آبشارهای PSP باعث کاهش خرابی، شوک حادثه و هزینه های پرداخت می شوند.
روش های محلی/راهروهای پرداخت: شما باید یک ارائه دهنده را در پرواز و عقب نشینی انتخاب کنید.

3) مسئولیت ها و نقش ها

منطقه مورد نظرپلت فرم (استاد)زیر دریایی
KYB/KYC/AMLOnboarding، محدودیت ها، نظارتتحویل داده ها، انطباق
اطلاعات PCI/کارتمعمولا بر روی پلت فرم/PSP آنخارج از محدوده برای نشانه گذاری
بازپرداخت/بازپرداختمدیریت پرونده، زمان بندی، شواهدمواد مورد، سیاست بازگشت
Fraud/3DSقوانین، مدل ها، تست های آبمحرک ها و محدودیت های ترافیک شما
حل و فصل/ذخایرEncasement، رزرو حسابداری/هزینه/تقسیمدریافت پرداخت، موافقت با کسر
مالیات (مالیات بر ارزش افزوده/GST/GGR/WHT)مدل MoR/قراردادبا صلاحیت/قرارداد (حق امتیاز/میلگرد)
💡 مهم: اگر پلت فرم MoR/PayFac باشد، مسئولیت مصرف کننده و خطرات طرح/خریدار را بر عهده دارد. اگر بازرگان فرعی بازرگان مستقیم باشد، مسئولیت بین قراردادها و MID ها تقسیم می شود.

4) سلسله مراتب MID ها و توصیف کنندگان

استاد MID (پلت فرم)

زیر MID (ها) └─ با نام تجاری/جغرافیایی/روش

پروفیل مسیریابی └─ (PSP1 → PSP2... آبشار)

توصیه ها:
  • توصیفگرهای جداگانه در زیر MID: اختلافات کمتر.
  • جدا کردن روش های cards/A2A/local توسط زیر MID برای تجزیه و تحلیل خالص و کنترل ذخیره.
  • پروفایل های مسیریابی نسخه (v1/v2) برای A/B.

5) آبشار: چگونه برای ساخت

5. 1. راه حل در پرواز

هنگام مجوز: یک مسیر را با توجه به قوانین (GEO، BIN/IIN، نام تجاری، کارت اعتباری/اعتباری، کلاس ریسک، محدودیت PSP، AR/DR فعلی، تعرفه/FX، حوادث SLA) انتخاب کنید.

5. 2. انواع آبشار

متوالی: PSP_A → (کاهش نرم) → PSP_B → PSP_C.
تقسیم ترافیک:٪ از ترافیک به PSP های مختلف برای معیار و decorrelation.
مهم BIN: تامین امنیت یک استخر BIN موفق برای بهترین PSP.

5. 3. محدودیت ها

خواندن idempotency (به طوری که برای ضبط دو برابر نیست).
موافقت با PSP در تلاش های مکرر (پنجره دوباره امتحان کنید، کدهای نرم).
سیاست 3DS و تغییر مسئولیت در هر مسیر را در نظر بگیرید.

6) حل و فصل، T + N، ذخایر و انشعابات

هر PSP/خریدار دارای برش خود را/T + N و ذخیره نورد خود را دارد.
این پلتفرم رسیدها را در سطح sub-MID جمع می کند و یک دفتر کل ذخیره با یک تقویم انتشار را حفظ می کند.
پرداخت به خرده بازرگانان: خالص هزینه ها و ذخیره + سهم خود (revshare/CPA) برای دوره گزارش.
تقسیم پشتیبانی توسط معامله (پلت فرم/استودیو/وابسته/مالیات) و یا مقاله به دوره.

7) Antifraud، 3DS و محدودیت در سطح خرده فروشی

آستانه های مختلف امتیاز دهی برای کلاس های A/B/C بازارها.
قوانین 3DS برای BIN/geo/check (اجباری/نرم/گام به گام).
محدودیت سرعت (ورودی/خروجی، تلاش کارت) و کلاه توسط submerschant.
استانداردهای فرعی «خاکستری»: محدودیت های سخت تر، تنها روش های سفید و پرداخت های معوق.

8) تعرفه ها و نرخ

در نظر گرفتن نرخ موثر توسط submerschant: هزینه PSP (تبادل/طرح/نشانه گذاری/ثابت) + لغزش FX + سهم پلت فرم + ذخیره اثر.
از 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. تسویه حساب خالص قابل پرداخت

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، سهم نرم کاهش.
نرخ٪ و هزینه پشته جزء توسط submerschant.
نسبت CB/نرخ بازپرداخت در زیر MID.
رزرو تعادل و انتشار ETA توسط Submerchant/PSP.
حل و فصل SLA: T + N نرخ ضربه، تاخیر بودجه.
پرداخت سلامت: فرکانس و مقدار پرداخت به submerschants، تاخیر.
FX لغزش در آبشار (موثر در مقابل مرجع).

12) هشدار و آستانه

مسیریابی تخریب: سقوط AR> Y bps ساعت به ساعت در قانون.
CB Spike: رشد بازپرداخت خرده فروشی> X bps w/w.
عدم تعادل ذخیره: رزرو لجر شکست می خورد - P1.
تاخیر حل و فصل: نقض PSP T + N → خودکار سوئیچ در آبشار.
را-نرخ اسپایک: رشد هزینه> آستانه (هزینه و یا FX).
رانش سیاست: معاملات بدون اتصال به مشخصات/قانون/idempointency - P1.
تأخیر در پرداخت: تأخیر در پرداخت به خرده فروش> SLA.

13) انطباق Onboarding و زیر بازرگان

ESC/تحریم ها/REP: بسته های اسناد، ذینفعان، منابع مالی.
PCI/security: نشانه گذاری، ممنوعیت ذخیره سازی PAN در زیر فروشنده.
سیاست های بازده/پاداش: استانداردهای یکنواخت، بلیط SLA.
گزارش جمع آوری شده: به طور جداگانه بر اساس نام تجاری، جغرافیایی، روش ها.
محدودیت/کلاه: گردش روزانه/هفتگی، پرداخت کلاه، بازپرداخت معوق برای پر خطر.

14) بهترین شیوه (کوتاه)

1. پروفایل مسیریابی نسخه و فروشگاه توضیح سیاهههای مربوط به تصمیم گیری.
2. تست های چسبنده BIN و A/B PSP را برای ثبات و قیمت AR نگه دارید.
3. هزینه های Mappite/FX/ذخیره به سطح زیر بازرگان ؛ پرداخت خالص هزینه در SLA.
4. Idempotency + سیاست تلاش مجدد تنها با نرم کاهش ؛ مطابق با محدودیت های PSP.
5. توصیف کننده ها و زیر MID ها برای نام تجاری/جغرافیایی منحصر به فرد هستند: اختلافات کمتر.
6. دفتر کل رزرو با تقویم انتشار و هشدار انتشار از دست رفته.
7. گزارش های شفاف به خرده فروشان: هزینه های رمزگشایی، رزرو، FX، اختلافات.
8. کتابهای پخش Failover: افت PSP/راهرو - تغییر مسیر فوری.

15) چک لیست پیاده سازی

  • دایرکتوری ها «submerchants»، «routing _ profiles»، «routing _ rules».
  • پروتکل های KYB/KYC/AML و ذخیره سازی وضعیت.
  • روتر با idempotency و منطق نرم کاهش است.
  • واردات PSP فایل های حل و فصل → 'حل و فصل _ هزینه' + رزرو-دفتر کل.
  • مکانیسم پرداخت به تجار زیر + اعمال/اساسنامه.
  • داشبورد AR/DR/CB/هزینه/رزرو + هشدار.
  • اسناد: سیاست اختلاف، قوانین 3DS، محدودیت ها و SLA ها.

خلاصه

Submerschants مقیاس و انعطاف پذیری را فراهم می کنند و آبشارها ثبات، تبدیل و هزینه های قابل کنترل را فراهم می کنند. معماری از سلسله مراتب MID ها، پروفایل های مسیریابی نسخه، حسابداری شفاف هزینه ها/ذخایر و انطباق دقیق، یک حلقه پرداخت پیچیده چند GEO را به یک سیستم قابل پیش بینی تبدیل می کند: مجوز بالا، نرخ پایین، پرداخت سریع و حداقل شگفتی در خطرات.

Contact

با ما در تماس باشید

برای هرگونه سؤال یا نیاز به پشتیبانی با ما ارتباط بگیرید.ما همیشه آماده کمک هستیم!

Telegram
@Gamble_GC
شروع یکپارچه‌سازی

ایمیل — اجباری است. تلگرام یا واتساپ — اختیاری.

نام شما اختیاری
ایمیل اختیاری
موضوع اختیاری
پیام اختیاری
Telegram اختیاری
@
اگر تلگرام را وارد کنید — علاوه بر ایمیل، در تلگرام هم پاسخ می‌دهیم.
WhatsApp اختیاری
فرمت: کد کشور و شماره (برای مثال، +98XXXXXXXXXX).

با فشردن این دکمه، با پردازش داده‌های خود موافقت می‌کنید.