آشتی پرداخت PSP و گزارش

TL ؛ دکتر متخصص

آشتی دوختن خودکار روزانه دفتر و رویدادهای شما (auth/capture/refund/payout) با گزارش PSP/acquirer/bank است. کلید موفقیت: یک مدل داده واحد، کلید تطبیق قطعی، idempotency دقیق، تحمل مجموع/FX/زمان، صف DLQ برای موارد بحث برانگیز و playbooks تصحیح خودکار. KPI: Rate↓ ناسازگاری Recon، پیری Unreconciled↓، خودکار match%↑.

1) چرا و چه چیزی را بررسی می کنیم

اهداف: تایید درآمد و کمیسیون، تشخیص تکراری/از دست دادن، حل و فصل صحیح روزها و ارزها، کنترل بازپرداخت به منبع، انطباق با حسابرسی/تنظیم کننده.

• سپرده ها: «auth → capture → settle»
• بازپرداخت: کامل/جزئی، وضعیت و مبلغ
• پرداخت/برداشت: پرداخت روش خروجی
• هزینه ها و تنظیمات: هزینه های PSP، طرح های تبادل، اصلاحات
• بازپرداخت/اختلافات: فراتر از ابتکار عمل شما
• FX/تبدیل: نرخ، گسترش، نقطه ثابت

2) منابع داده

رویدادهای داخلی: اتوبوس رویداد/کافکا، «پرداخت _ تخت»، «بازپرداخت»، «پرداخت»، لجر خود را.

• معاملات (بیانیه های عملیاتی)
• شهرک ها/دسته ها
• هزینه ها/اظهارات
• بازپرداخت/اختلافات
• پرداخت/OCT/RTP/SEPA ثبت نام
• بیانیه های بانکی: MT940/CSV/ISO20022 CAMT، آسانسور اعتباری.

3) کلید های تطبیق

1. provider_txid ↔ provider_txid (شناسه PSP منحصر به فرد)

2. idempotency_key/ merchant_reference (اگر در PSP پایدار باشد)

3. (مقدار، ارز، timestamp_bucket، last4/بن، auth_code)

4. لایه فازی: تحمل ± توسط مجموع/زمان، BIN/صادر کننده کشور، خانواده وضعیت

• هر دو «payment _ id» و «provider _ txid» را نگه دارید.
• برای بازپرداخت جزئی، «sequence _ index» یا «refund _ line _ id» را اضافه کنید.
• پرداخت های Для - 'پرداخت _ batch _ id + line_id'.
• برای FX - 'exec _ id' (تبدیل) و منبع نرخ.

4) مدل داده (لایه نرمال)

json
{
"source": "INTERNAL    PSP_TX    PSP_SETTLEMENT    BANK",
"provider": "Acquirer_A",
"payment_id": "pay_123",
"provider_txid": "psp_tx_789",
"kind": "AUTH    CAPTURE    REFUND    PAYOUT    FEE    SETTLEMENT    CHARGEBACK",
"sequence": 0,
"amount": 100. 00,
"currency": "EUR",
"fee_amount": 1. 20,
"fx_rate": 1. 0000,
"fx_src": "PSP    ECB    BANK",
"status": "APPROVED    CAPTURED    SUCCESS    FAILED    SETTLED",
"event_ts": "2025-11-03T12:00:00Z",
"settlement_date": "2025-11-05",
"account": "PSP_MERCHANT_CARD_A",
"matching_keys": {
"provider_txid": "psp_tx_789",
"merchant_ref": "mr_456",
"idem_key": "idem_abc"
},
"hash_row": "sha256(...)"
}

5) فرآیند آشتی (ETL/ارکستراسیون)

1. وارد کردن: ما گزارش های PSP (SFTP/API) را می گیریم، طرح/امضا را تأیید می کنیم، به «خام» ذخیره می کنیم.
2. Normalize: نگاشت فیلد به فرمت واحد (ارز ISO، اعشار، منطقه زمانی UTC).
3. Match: الگوریتمی برای تطبیق درخت کلید با تلرانس.
4. پس از مسابقه: فرم diff (اختلاف) و نوشته های مجله برای دفتر/اصلاحات.
5. حل و فصل: کوک 'PSP _ SETTLEMENT ↔ BANK' (اعتبار به حساب)، پراکنده توسط روز/دسته ای.
6. گزارش: داشبورد، هشدارها ؛ بحث برانگیز در DLQ برای تجزیه دستی/پخش خودکار.

Idempotence: برای هر فایل/صفحه - 'ingest _ id'. بارگذاری مجدد نتیجه را تغییر نمی دهد.

6) تحمل و قوانین

زمان: «± 15 دقیقه» برای معاملات، «± 1 روز» برای حل و فصل.
مقدار: ≤ 0 01 "ارز پایه یا" ≤ 10 bps "برای تفاوت FX/هزینه.
FX: ما اجازه می دهیم اختلاف با بانک اگر منبع نرخ ارز متفاوت باشد ؛ تعمیر 'fx _ src'.
جزئی/چندگانه: مجموع خطوط جزئی/بازپرداخت باید با تعادل داخلی برابر باشد.

7) طبقه بندی تفاوت

8) دفتر و حسابداری

ضبط: «حسابهای DR دریافتنی/CR درآمد» и «DR نقدی (پس از تسویه )/CR حسابهای دریافتنی»

هزینه: «هزینه DR/CR نقدی یا قابل پرداخت»

بازپرداخت: پست های معکوس طرفدار راتا جزئی

بازپرداخت: حساب های جداگانه و رزرو برای اختلافات

بازنگری FX: ارزیابی روزانه تعادل AR/cache در 'fx _ src _ policy'

9) KPI ها و اهداف

تطابق خودکار% = تطابق خودکار خطوط/تمام خطوط (95% ≥ هدف)

نرخ عدم تطابق Recon = خطوط تفاوت/تمام خطوط (≤ 1-2٪)

P50/p95 روز در DLQ (p95 ≤ 3 روز)

زمان حل و فصل: نسبت دسته های دوخته شده با بانک D-day (≥ 99٪)

دقت هزینه: اختلاف هزینه ارائه دهنده (≤ 0. 1٪ از گردش مالی)

تکراری/حوادث یتیم: هدف برای 0

10) برش های SQL

10. 1 تطبیق provider_txid پایه

sql
WITH i AS (
SELECT provider, provider_txid, kind, amount, currency, event_ts
FROM internal_norm
),
p AS (
SELECT provider, provider_txid, kind, amount, currency, event_ts
FROM psp_norm
)
SELECT
COALESCE(i. provider_txid, p. provider_txid) AS txid,
COALESCE(i. provider, p. provider) AS provider,
i.kind AS kind_internal, p. kind AS kind_psp,
i.amount AS amount_internal, p. amount AS amount_psp,
i.currency, p. currency,
CASE
WHEN i.provider_txid IS NULL THEN 'MISSING_INTERNAL'
WHEN p. provider_txid IS NULL THEN 'MISSING_PSP'
WHEN ABS(i. amount - p. amount) > 0. 01 THEN 'AMOUNT_MISMATCH'
ELSE 'MATCHED'
END AS recon_status
FROM i
FULL OUTER JOIN p USING (provider, provider_txid);

10. ۲ تسویه حساب ↔ بانک

sql
SELECT s. settlement_date, s. batch_id, s. currency,
s. amount_settled, b. amount_bank,
(b. amount_bank - s. amount_settled) AS diff
FROM psp_settlements s
LEFT JOIN bank_statements b
ON b. value_date = s. settlement_date
AND b. currency = s. currency
AND ABS(b. amount_bank - s. amount_settled) <= 0. 5;

10. 3 پیری DLQ

sql
SELECT diff_type,
COUNT() AS cnt,
PERCENTILE_CONT(0. 5) WITHIN GROUP (ORDER BY AGE(NOW(), created_at)) AS p50_age,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY AGE(NOW(), created_at)) AS p95_age
FROM recon_dlq
GROUP BY diff_type
ORDER BY cnt DESC;

11) ویژگی های ریل/موارد

نقشه ها: تفاوت بین «auth» و «capture»، تنظیمات «حل و فصل»، هزینه مبادله/مدار - خطوط جداگانه.
بانکداری A2A/Open/RTP: تأییدهای فوری، اما «برگشت» ممکن است ؛ بررسی «پرداخت» و بازگشت.
کیف پول: اغلب کامل 'provider _ txid'، سریع 'بازپرداخت' ؛ مراقب خطوط دستمزد باش.
کوپن: بدون بازپرداخت متقارن - به درستی در سیاست و گزارش ها منعکس می شود.
رمزنگاری: هش زنجیره ای ↔ provider_txid ؛ تأییدیه های N ؛ حسابداری کمیسیون های شبکه و تخفیف های احتمالی ؛ نرخ ارز - در زمان تبدیل.

12) کتاب های عملیاتی

افزایش MISSING_INTERNAL: بررسی از دست دادن webhooks/retrays، مصرف مجدد، فعال کردن نظرسنجی API.
AMOUNT_MISMATCH از یک PSP: مقایسه گرد/مالیات بر ارزش افزوده/مدل هزینه، درخواست بیانیه اصلاح.
حل و فصل به بانک پیوند ندارد: تاریخ ارزش چک، هزینه های بانکی، تاخیر T + N ؛ به طور موقت در «حساب تعلیق» قرار دهید.
REFUND_OVER توده: توقف خودکار توقف خودکار، حسابرسی idemotency، اصلاح دستی.
FX_DRIFT: اصلاح سیاست منبع نرخ ارز (ECB/PSP/BANK)، محاسبه مجدد P&L تفاوت.

13) کنترل و ایمنی

Idempotence مصرف: 'file _ id + checksum' و تاریخچه دانلود.
دسترسی (RBAC) و کنترل 4 چشم: برای اصلاحات دستی/نوشته های مجله.
دنباله حسابرسی: تمام مسابقات/diffs/اصلاحات - در یک ورود به سیستم غیر قابل تغییر.
کیفیت داده ها: طرح ها، زمینه های اجباری، اعتبار سنجی ارز/مقیاس.

14) داشبورد و هشدارها

ویدجت: خودکار مطابقت%, نرخ عدم تطابق, پیری DLQ, حل و فصل زمان, دقت هزینه, PSP بالا توسط تفاوت, تفاوت از نوع نقشه.

• 'خودکار مسابقه٪ <90٪' توسط ارائه دهنده/روز → P1
• 'پیری p95> 3 روز → P2
• 'مقدار _ سنبله عدم تطابق → P1
• «Bank≠Settlement» با مقدار/ارز → P0

15) موارد تست (UAT/Prod)

1. بارگذاری مجدد همان فایل → 0 عوارض جانبی (idempotency).
2. refands جزئی (3 خط) → مقدار مسابقات، مطابقت با دنباله.
3. تبدیل FX: اختلاف نرخ ارز در تحمل → بازی صحیح.
4. provider_txid تکراری در گزارش → dedup و هشدار.
5. گرفتن webhook گم شده → رای گیری شکاف بسته، وضعیت تراز وسط قرار دارد.
6. دسته حل و فصل با خط هزینه → شکست صحیح در درآمد/هزینه/خالص.

16) اشتباهات مکرر و چگونه برای جلوگیری از

مقایسه «تلاش» در مقابل «ضبط» → حفظ همان دانه دانه بودن.
عدم وجود «provider _ txid» در → log صحت مسابقه را از دست می دهد.
نادیده گرفتن منطقه زمانی → جبران شده توسط تاریخ حل و فصل.
هیچ اختلاف DLQ/retras → «ابدی» وجود ندارد.
ویرایش دستی بدون ورود به سیستم → ناسازگاری با حسابرسی.
تحمل فازی → یا یک مسابقه مجدد یا «همه در DLQ».

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

• طرح عادی سازی یکپارچه و دایرکتوری PSP/روش/حساب
• نقشه برداری درخت کلید (txid → merchant_ref → فازی)
• مقدار/زمان تحمل/FX، سیاست منبع دوره
• مصرف ایده آل، DLQ، retrai، هشدار
• آشتی Settlement↔Bank, سیاست حساب تعلیق
• داشبورد KPI، گزارش مالی/حسابرسی
• Playbooks و SLA تجزیه موارد تفاوت

خلاصه

آشتی یک رشته مهندسی است: عادی سازی، کلیدهای قابل اعتماد، تحمل، مسابقات خودکار و اصلاحات شفاف. با چنین کانتوری، درآمد و کمیسیون را تثبیت می کنید، «سیاه چاله ها» را به حداقل می رسانید، سرعت بسته شدن دوره را تسریع می کنید و بدون درد حسابرسی می شوید: خودکار match%↑، Mismatch↓، Aging↓.