چرخه حل و فصل و قطع

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

حل و فصل - حل و فصل بین PSP/Acquirer و بازرگان (اپراتور)، که در آن پول برای معاملات موفقیت آمیز گرفته شده به حساب بازرگان منتقل می شود.
برش - یک «برش» روزانه از عملیات که به یک چرخه صدور صورت حساب خاص قرار می گیرند (معمولا یک زمان ثابت در منطقه زمان ارائه دهنده).
T + N - نماد معمولی برای تاخیر در ارسال بودجه: T - تاریخ قطع، N - تعداد روزهای کاری قبل از ثبت نام واقعی.

• کارت (ویزا/مسترکارت): اغلب T + 2/T + 3 روز بانکی، قطع 23:00 UTC (تقریبا).
• بانکداری A2A/Open: T + 0 به T + 1.
• انتقال اعتبار SEPA: T + 1/T + 2 (فوری - T + 0).
• ACH (ایالات متحده): T + 2/T + 3 ؛ همان روز ACH - T + 0/T + 1.
• RTP (US): T + 0، اما قطع گزارش ها امکان پذیر است.
• Crypto: در واقع T + 0 بر روی شبکه، اما PSP می تواند پنجره های مالی خود را (T + 0/1) اعمال کند.

2) چگونه برش کار می کند و چه چیزی به آن می رسد

1. ارائه دهنده تعمیر پنجره مجموعه (به عنوان مثال، 00: 00-23: 00 UTC).
2. تمام معاملات حل و فصل شده/گرفته شده در این پنجره در یک دسته قرار می گیرند.
3. بازده، بازپرداخت، اصلاحات به بسته برای محاسبه بودجه ناخالص و خالص جمع می شود.
4. پس از قطع، یک فایل حل و فصل تولید می شود و تایمر T + N قبل از ثبت نام شروع می شود.

مهم: مجوز بدون ضبط در بسته گنجانده نشده است. نتیجه گیری های لغو شده - همچنین نه.

3) انواع حل و فصل: ناخالص در مقابل خالص، ذخایر و کمیسیون

تسویه ناخالص - مبلغ ضبط ناخالص منتقل می شود (منهای هزینه کمیسیون جداگانه).
تسویه خالص - ارائه دهنده هزینه ها، بازپرداخت، بازپرداخت، ذخیره نورد و لیست مبلغ خالص را نگه می دارد.
ذخیره نورد - خودداری از٪ از گردش مالی برای N روز (به عنوان مثال، 10٪ برای 180 روز) برای پوشش ریسک.
حمل و نقل منفی - اگر «خالص» به منفی در روز برسد، کسری در چرخه های بعدی منتقل می شود.

توصیه: رمزگشایی هر دو هواپیما - ناخالص عملیاتی (توسط معاملات) و خالص بودجه (توسط فایل های ارائه دهنده).

4) منطقه زمانی، خروجی محلی و DST

Cut-off توسط منطقه زمانی ارائه دهنده تعیین می شود، که ممکن است از شما متفاوت باشد.
DST (زمان صرفه جویی در نور روز) را در نظر بگیرید - برش ها می توانند ± 1 ساعت نسبت به زمان محلی تغییر کنند.
تعطیلات/تعطیلات آخر هفته در حوزه قضایی بانک دریافت کننده N در T + N را تحت تاثیر قرار می دهد (به عنوان مثال، روزهای بانکی T + 2 T + 4 در اطراف تعطیلات).
تمرین: عادی کردن تمام زمان های فنی در UTC، به طور همزمان فروشگاه 'provider _ tz _ cutoff _ at' و 'local _ tz _ posted _ at'.

5) تقویم حل و فصل (تقویم بودجه) و SLA

• زمان برش و tz برای هر روش/PSP،
• استاندارد T + N و استثنائات (تعطیلات)،
• مقادیر مورد انتظار (پیش بینی)،
• رسید SLA: به عنوان مثال، «نه بعد از 12:00 اروپا/کیف در روز T + 2».

هر گونه انحراف SLA → هشدار و بلیط به عملیات/امور مالی.

6) ارتباط با خالص سپرده ها و خروجی ها

ND (مشارکت خالص) در معاملات حل و فصل محاسبه می شود (نگاه کنید به مقاله مرتبط).
نتیجه گیری (برداشت) در بودجه از PSP در سپرده شرکت نمی کنند، اما میز نقدی تاجر تاثیر می گذارد.
برنامه ریزی نقدینگی: ورود با حل و فصل منهای خروج توسط پرداخت/مالیات/هزینه های عملیاتی.

7) مصنوعات آشتی و ارائه دهنده

• 'batch _ id/ settlement_id'، تاریخ قطع در ارائه دهنده tz،
• суммы по типам: «سپرده های گرفته شده»، «بازپرداخت»، «بازپرداخت _ بدهی»، «بازپرداخت _ اعتبار»، «هزینه ها»، «ذخیره _ دلتا»، «net _ funding»،
• رمزگشایی توسط روش ها/حساب های تجاری ('MID'، 'descriptor'، 'MCC')،
• مراجع معامله ('provider _ tx _ id', 'rrn', 'arn' - if cards),
• فایل (ها): CSV/XML/JSON + دستور قابل خواندن انسان (PDF/HTML).

1. از معاملات به فایل ها (همه چیز ما فکر می کردیم در فایل بود ؟)

2. از فایل ها به معاملات (همه چیز در فایل در فروشگاه ما است ؟ آیا وضعیت ها مطابقت دارند ؟)

8) مشخصات ریل پرداخت (به طور کلی)

نقشه ها: سناریوهای تاخیر ارائه مکرر ؛ «بازپرداخت» در اواخر امکان پذیر است (تا 120-540 روز برای مورد) ؛ هزینه های مبادله و طرح در فایل ها ظاهر می شود، در ND کسر نمی شود.
SEPA/ACH: دسته ها به پنجره های بانکی بستگی دارد. لغو/بازگشت دارند کدهای خود را دارند گزینه های همان روز قطع آف جداگانه هستند.
Banking/A2A باز: T + 0/1، اما فایل ها می توانند پس از واقعیت ؛ نیاز به RPP سخت/ID منحصر به فرد برای مسابقات.
RTP/Instant: پول به سرعت می آید، اما فایل گزارش در برنامه است.
رمزنگاری: حل و فصل onchain فوری, اما ارائه دهنده باعث می شود 'پنجره پرداخت'; فروشگاه 'fx _ at _ settle'.

9) حسابداری (FI/حسابداری)

9. 1. روش تعهدی در مقابل کش

برای گزارش مدیریت، تعهدی است که اغلب استفاده می شود: ما درآمد/حرکت در زمان تشخیص «تثبیت _ در».
برای خزانه داری/DDS - روش کش: ما این واقعیت از رسید 'funded _ at' را تشخیص دهد.

9. 2. سیم کشی معمولی (ساده شده)

• JT: نقدی در حل و فصل با PSP (AR: PSP)
• KT: تعهد بازیکن (تعادل کیف پول/بازیکن)

• Dt: بانک (دفتر صندوقدار)
• KT: پول نقد در شهرک با PSP
• JT: هزینه ها (هزینه های PSP)، JT: مقررات (در صورت تغییر)

شما sheaf 'transaction _ id → batch_id → funding_id' را برای ردیابی ذخیره می کنید.

10) مدیریت ریسک و هشدارها

فایل از دست رفته: هیچ فایل حل و فصل قبل از X: YY - P1.
تاخیر بودجه: T + N منقضی شده، بدون پول - P1.
آستانه دلتا: واریانس 'our _ gross' در مقابل 'file _ gross'> 0. 5٪ - P2 ؛ «fees» خارج از محدوده - P2.
منفی حمل بیش از: یک سری از بسته های خالص منفی - تحقیقات.
تاثیر تعطیلات: پیش بینی خودکار با توجه به تقویم ؛ اگر این واقعیت <80٪ از پیش بینی - بلیط.

11) مدل داده (ساده شده)

finance. payment_transactions (
id, user_id, method, provider, mid, mcc,
type, status, amount_original, currency_original,
amount_reporting, reporting_currency, fx_rate_at_settle,
authorized_at, captured_at, settled_at,
provider_tx_id, arn, rrn, meta
)

finance. settlement_batches (
batch_id, provider, mid, method,
provider_cutoff_at, provider_tz,
period_start_at, period_end_at,
gross_captured, refunds, cb_debits, cb_credits,
fees, reserve_delta, net_funding_expected,
file_name, file_hash, file_type, meta
)

finance. funding_receipts (
funding_id, provider, bank_account,
received_at, value_date,
currency, amount_received,
batch_id, statement_ref, meta
)

-- Binding showcase:
finance. recon_links (
id, transaction_id, batch_id, funding_id, link_type, created_at
)

12) نمونه هایی از قالب های SQL

12. 1. ضبط برش

sql
INSERT INTO finance. settlement_batches (
batch_id, provider, mid, method,
provider_cutoff_at, provider_tz,
period_start_at, period_end_at,
gross_captured, refunds, cb_debits, cb_credits,
fees, reserve_delta, net_funding_expected,
file_name, file_hash, file_type, meta
)
VALUES (:batch_id,:provider,:mid,:method,
:cutoff_at,:tz,
:start_at,:end_at,
:gross,:refunds,:cb_deb,:cb_cr,
:fees,:reserve_delta,:net_expected,
:file_name,:file_hash,:file_type,:meta::jsonb);

12. 2. آشتی تراکنش به فایل

sql
WITH tx AS (
SELECT provider, mid, method,
SUM(CASE WHEN type='DEPOSIT' AND status IN ('CAPTURED','SETTLED') THEN amount_reporting ELSE 0 END) AS gross,
SUM(CASE WHEN type='REFUND' AND status='SETTLED' THEN amount_reporting ELSE 0 END) AS refunds,
SUM(CASE WHEN type='CHARGEBACK_DEBIT' AND status='SETTLED' THEN amount_reporting ELSE 0 END) AS cb_deb,
SUM(CASE WHEN type='CHARGEBACK_CREDIT' AND status='SETTLED' THEN amount_reporting ELSE 0 END) AS cb_cr
FROM finance. payment_transactions
WHERE settled_at >=:start_at AND settled_at <:end_at
GROUP BY 1,2,3
)
SELECT b. batch_id, b. provider, b. mid, b. method,
tx. gross AS our_gross, b. gross_captured AS file_gross,
tx. refunds AS our_refunds, b. refunds AS file_refunds,
tx. cb_deb AS our_cb_deb, b. cb_debits AS file_cb_deb,
tx. cb_cr AS our_cb_cr, b. cb_credits AS file_cb_cr
FROM finance. settlement_batches b
LEFT JOIN tx
ON tx. provider=b. provider AND tx. mid=b. mid AND tx. method=b. method
WHERE b. provider_cutoff_at BETWEEN:cutoff_from AND:cutoff_to;

12. 3. پیش بینی درآمد (جریان نقدی T + N)

sql
SELECT provider, mid, method,
DATE(provider_cutoff_at) AS t_date,
net_funding_expected,
CASE
WHEN EXTRACT (DOW FROM provider_cutoff_at)::int IN (5,6) THEN provider_cutoff_at + INTERVAL '3day' -- conditional example
ELSE provider_cutoff_at + INTERVAL '2 day'
END AS expected_funding_at
FROM finance. settlement_batches
WHERE provider_cutoff_at BETWEEN:from AND:to;

13) فرآیندها و SLO ها

SLO 1: فایل های حل و فصل واردات - T + 0، تا 08:00 اروپا/کیف.
SLO 2: آشتی اولیه - تا 09:00، واریانس> 0. 5%.

SLO 3: به روز رسانی پیش بینی جریان نقدی - تا 10 صبح

SLO 4: بسته شدن روز - تمام مسابقات مالی به DWH منجر می شود.

14) موارد لبه و نحوه رسیدگی به آنها

ارائه دیرهنگام: معامله وارد دسته بعدی شد - «واقعیت منبع» («presented _ in _ batch _ id») را حفظ کنید.
ضبط جزئی: ضبط چندگانه در هر مجوز - جمع به درستی در دسته.
چند MID: یک ارائه دهنده، MID های مختلف توسط جغرافیایی/نام تجاری - در یک دسته مخلوط نیست.
پردازش مجدد: هنگامی که یک فایل مسدود شده است - نسخه 'batch _ revision' و تأیید مجدد کامل.
مسابقات FX: دوره ها - در 'حل و فصل _ در' ؛ بودجه در یک ارز متفاوت - شروع 'fx _ at _ funding' و دلتا.

15) داشبورد و KPI ها

ETA بودجه: انتظار می رود تاریخ/زمان دریافت در مقابل واقعی.
Hit-rate SLA: درصد فایلهایی که به موقع میرسند.
دلتا ناخالص/خالص توسط ارائه دهنده، روش، MIDs.
کارمزدهای% حجم، تراز ذخیره، خط انتقال منفی.
تاثیر تعطیلات: پیش بینی در مقابل واقعی در هفته با تعطیلات.

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

1. زمان را به UTC عادی کنید، اما provider_tz قطع را نگه دارید.
2. ناخالص عملیاتی جداگانه و خالص بودجه ؛ ND و بودجه را اشتباه نگیرید.
3. پیاده سازی یک تقویم بودجه با تعطیلات بانکی از قبل وارد شده است.
4. خودکار واردات و آشتی از فایل های حل و فصل + هشدار به SLAs/دلتاها.
5. اجرای batch _ revision و پردازش مجدد قطعی.
6. منبع واحد حقیقت را تایپ کنید: پیوندهای «معامله ↔ دسته ای ↔ تأمین مالی».
7. صرفه جویی در ARN/RRN و زمینه های کسب کارت - مهم برای اختلافات.
8. پیش بینی جریان نقدی با توجه به تعطیلات آخر هفته/تعطیلات، ذخایر و کمیسیون.

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

داده ها و نمودارها

• Таблицы 'پرداخت _ معاملات'، 'حل و فصل _ دسته'، 'بودجه _ رسید'، 'recon _ links'.
• زمینه های منطقه زمانی UTC + provider_tz هستند.
• Поля FX: 'fx _ rate _ at _ settle', 'fx _ at _ funding'.

واردات و اعتبار سنجی

• CSV/XML/JSON تجزیه کننده + هش فایل.
• اعتبار مقادیر/ارزها/تاریخ ؛ مطابقت по 'provider _ tx _ id/ARN'.
• گردانندگان «ارائه دیر»، «ضبط جزئی»، «معکوس».

عملیات و هشدارها

• SLA قطع مانیتور، فایل های از دست رفته، تاخیر بودجه.
• هشدار آستانه دلتا (ناخالص، هزینه، خالص).
• تاثیر تعطیلات و گزارش منفی حمل و نقل.

18) سوالات متداول

س: چرا T + 2 به T + 4 تبدیل شد ؟

A: تعطیلات آخر هفته/تعطیلات در بانک خبرنگار یا در بانک دریافت وجود دارد ؛ см. تقویم بودجه

س: در فایل خالص کمتر از محاسبه خالص ما وجود دارد. چه چیزی را تماشا کنم ؟

A: هزینه ها، reserve_delta، بازپرداخت/بازپرداخت دیرکرد و صحت دوره ها را بررسی کنید.

س: چگونه برای رمزنگاری حساب می کنید ؟

A: با فیات معادل 'حل و فصل _ در' ؛ بودجه می تواند به USDT/فیات آمده - نگه داشتن جداگانه 'fx _ at _ funding'.

س: آیا ممکن است یک برش مشترک برای همه ارائه دهندگان داشته باشد ؟

A: نه، هر PSP دارای tz/hour است. یک صفحه نمایش جمع کننده روی برش های خود ایجاد کنید.

خلاصه

• بررسی دقیق ارائه دهندگان،
• پیش بینی نقدینگی و پوشش پرداخت،
• مطابق با SLA ها و کاهش خطرات عملیاتی،
• همان زبان مالی و انطباق صحبت می کنند.

با اجرای یک تقویم مالی واحد، یک مدل داده دقیق و آشتی خودکار، جریان نقدی را قابل پیش بینی و قابل کنترل می کنید.