PSP ödemelerinin ve raporlarının uzlaştırılması

TL; DR

Mutabakat, defter ve etkinliklerinizin (auth/capture/refund/payout) PSP/acquirer/bank raporları ile günlük otomatik olarak birleştirilmesidir. Başarının anahtarı: tek bir veri modeli, deterministik eşleştirme anahtarları, sıkı idempotency, toplam/FX/zaman toleransları, tartışmalı durumlar için DLQ kuyruğu ve otomatik düzeltme oyun kitapları. KPI: Recon Uyumsuzluk Rate↓, Unreconciled↓ Yaşlanma, Otomatik match%↑.

1) Neden ve neyi kontrol ediyoruz

Hedefler: gelir ve komisyonların onaylanması, yinelenen/zarar tespiti, günlere ve para birimlerine göre doğru yerleşim, kaynağa geri ödeme kontrolü, denetim/düzenleyiciye uygunluk.

• Para yatırma: 'auth> capture - settle'
• Geri ödemeler: tam/kısmi, durumlar ve tutarlar
• Ödemeler/Para Çekme: Giden Yöntem Ödemeleri
• Ücretler ve Ayarlamalar: PSP ücretleri, değişim planları, düzeltmeler
• Ters ibrazlar/Anlaşmazlıklar: Girişiminizin Ötesinde
• FX/Dönüşümler: oranlar, spreadler, sabitleme noktası

2) Veri kaynakları

Dahili Etkinlikler: etkinlik otobüsü/Kafka, 'payments _ flat', 'return', 'payments', sizin Defteriniz.

• İşlemler (operasyonel tablolar)
• Yerleşimler/Partiler
• Ücretler/Beyanlar
• Ters ibrazlar/Anlaşmazlıklar
• Ödemeler/OCT/RTP/SEPA kayıtları
• Banka Dekontları: CAMT MT940/CSV/ISO20022, credit lift.

3) Eşleşen anahtarlar

1. provider_txid ↔ provider_txid (benzersiz PSP Kimliği)

2. idempotency_key/ merchant_reference (PSP'de kararlıysa)

3. (miktar, para birimi, timestamp_bucket, last4/bin, auth_code)

4. Bulanık katman: Toplam/zamana göre ± toleranslar, BIN/veren ülke, durum ailesi

• Hem 'payment _ id'hem de' provider _ txid 'tutun.
• Kısmi/geri ödeme için, 'sequence _ index' veya 'refund _ line _ id' ekleyin.
• Для ödemeler - 'payout _ batch _ id + line_id'.
• FX için - 'exec _ id' (dönüşüm) ve oranın kaynağı.

4) Veri modeli (normalize edilmiş katman)

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) Uzlaşma süreci (ETL/orkestrasyon)

1. Ingest: PSP raporlarını (SFTP/API) alıyoruz, şemayı/imzaları doğruluyoruz, 'ham'olarak kaydediyoruz.
2. Normalize: alanın birleşik biçime mappim (para birimi ISO, ondalık, UTC saat dilimi).
3. Eşleşme: Anahtar ağacı toleranslarla eşleştirmek için algoritma.
4. Maç sonrası: defter/düzeltmeler için form diff (tutarsızlıklar) ve günlük girişleri.
5. Yerleşme: dikiş 'PSP _ SETTLEMENT ↔ BANK' (hesaba kredi), gün/toplu olarak dağılım.
6. Rapor: pano, uyarılar; Manuel ayrıştırma/otomatik yeniden oynatma için DLQ'da tartışmalı.

Idempotence: her dosya/sayfa için - 'ingest _ id'. Yeniden yükleme sonucu değiştirmez.

6) Toleranslar ve kurallar

Süre: İşlemler için '± 15 dakika', uzlaşma için '± 1 gün'.
Miktar: '≤ 0. FX/ücret farkları için 01 'temel para birimi veya' ≤ 10 bps '.
FX: Döviz kurunun kaynağı farklıysa bankayla tutarsızlığa izin veriyoruz; fix 'fx _ src'.
Kısmi/Çoklu: Kısmi/geri ödeme hatlarının toplamı iç bakiyeye eşit olmalıdır.

7) Diff taksonomisi

8) Defter ve Muhasebe

Yakalama: 'DR Hesapları Alacak/CR Geliri' и 'DR Nakit (anlaşma üzerine )/CR Hesapları Alacak'

Ücret: 'DR Ücretleri/CR Nakit veya Ödeme'

Geri ödeme: ters ilanlar pro rata kısmi

Ters ibraz: ayrı hesaplar ve anlaşmazlıklar için rezerv

FX reval: AR/önbellek bakiyesinin günlük yeniden değerlemesi 'fx _ src _ policy'

9) KPI'lar ve hedefler

Otomatik eşleşme % = otomatik eşleşme çizgileri/tüm çizgiler (hedef ≥ %95)

Keşif Uyumsuzluk Oranı = diff çizgileri/tüm çizgiler (≤ %1-2)

Kaplanmamış Yaşlanma: DLQ'da p50/p95 gün (p95 ≤ 3 gün)

Yerleşim Süresi: D-day bank ile dikilen partilerin oranı (≥ %99)

Ücret Doğruluğu: sağlayıcı ücreti tutarsızlıkları (≤ 0. Cironun %1'i)

Yinelenen/Yetim Olayları: Hedef 0

10) SQL dilimleri

10. 1 Temel provider_txid eşleştirme

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. 2 Banka ↔ ödeme

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 Yaşlanma 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) Raylar/kılıflar üzerindeki özellikler

Haritalar: 'auth've' capture 'arasındaki farklar, geç' yerleşim 'ayarlamaları, değişim/devre ücreti - ayrı hatlar.
A2A/Open Bankacılık/RTP: Anlık onaylar, ancak 'tersine' mümkün; 'ödeme've iadeleri kontrol edin.
Cüzdanlar: genellikle mükemmel 'provider _ txid', hızlı 'geri ödeme'; Ücret hatlarına dikkat et.
Kuponlar: simetrik geri ödeme yok - politika ve raporlarda doğru şekilde yansıtın.
Kripto: zincirleme hash ↔ provider_txid; Onaylar N; Ağ komisyonlarının ve olası indirimlerin muhasebeleştirilmesi; Döviz kuru - dönüşüm sırasında.

12) Operasyonel oyun kitapları

Surge in MISSING_INTERNAL: webhook/retray kayıplarını kontrol edin, yenilerini alın, API yoklamasını etkinleştirin.
bir PSP'den AMOUNT_MISMATCH: yuvarlama/KDV/ücret modelini karşılaştırın, bir düzeltme bildirimi isteyin.
Uzlaşma bankaya bağlanmaz: çek değeri tarihi, banka ücretleri, T + N gecikmeleri; Geçici olarak "Suspense Hesabı'na koyun.
Kütle REFUND_OVER: anında stop otomatik refandlar, idempotency denetimi, manuel düzeltme.
FX_DRIFT: döviz kuru kaynağının (ECB/PSP/BANK) politikasını düzeltin, P&L farklarını yeniden hesaplayın.

13) Kontrol ve güvenlik

Yutmanın idempotansı: 'file _ id + checksum've indirme geçmişi.
Erişim (RBAC) ve 4-göz kontrolü: manuel düzeltmeler/günlük girişleri için.
Denetim izi: tüm eşleşmeler/differs/düzeltmeler - değiştirilemez bir günlükte.
Veri kalitesi: şemalar, zorunlu alanlar, para birimi/ölçek doğrulaması.

14) Gösterge tablosu ve uyarılar

Widget'lar: Otomatik eşleşme %, Uyumsuzluk Oranı, Yaşlanma DLQ, Yerleşim Zamanlaması, Ücret Doğruluğu, diff tarafından üst PSP, diff tipi harita.

• 'Otomatik eşleşme % <%90' sağlayıcıya/güne göre> P1
• 'Yaşlanma p95> 3 gün' P2
• 'TUTAR _ UYUŞMAZLIK ani' - P1
• Miktar/para birimi ile 'Bank≠Settlement' - P0

15) Test Durumları (UAT/Prod)

1. Aynı dosyanın yeniden yüklenmesi - 0 yan etki (idempotency).
2. Kısmi refandlar (3 satır) - miktar eşleşir, sıraya göre eşleşir.
3. FX dönüşümü: tolerans içinde döviz kuru tutarsızlığı - doğru eşleşme.
4. Rapordaki yinelenen provider_txid - dedup ve uyarı.
5. Eksik webhook yakalama - oylama boşluğu kapattı, durum hizalandı.
6. Ücret çizgisine sahip yerleşim partisi - Gelir/Ücret/Net'te doğru arıza.

16) Sık yapılan hatalar ve nasıl önleneceği

'Girişim' vs 'yakalama' karşılaştırın - aynı granülerliği tutun.
^ günlüğünde 'provider _ txid' olmaması maçın doğruluğunu kaybeder.
Zaman dilimini yoksaymak - yerleşim tarihleriyle dengelemek.
DLQ/retras - "ebedi" tutarsızlıklar yoktur.
Günlük olmadan manuel düzenlemeler - denetimde tutarsızlık.
Bulanık toleranslar - ya bir yeniden eşleşme ya da "hepsi DLQ'da".

17) Uygulama kontrol listesi

• Birleşik normalleştirme şeması ve PSP/yöntem/hesap dizinleri
• Mapping Key Tree (txid merchant_ref bulanık)
• Miktar/Zaman Toleransları/FX, Ders Kaynak Politikası
• Idempotent yutma, DLQ, retrai, uyarılar
• Settlement↔Bank Uzlaşma, Suspense Hesap Politikası
• Gösterge tablosu KPI, finansal/denetim raporlama
• Playbooks ve SLA ayrıştırma diff durumları

Özet

Uzlaşma bir mühendislik disiplinidir: normalleştirme, güvenilir anahtarlar, toleranslar, otomatik eşleşmeler ve şeffaf düzeltmeler. Böyle bir konturla, gelir ve komisyonları stabilize eder,'kara delikleri "en aza indirir, periyot kapanmasını hızlandırır ve acı çekmeden denetlenir: Otomatik match%↑, Mismatch↓, Aging↓.