정산주기 및 차단

1) 개념적 기반

합의-PSP/Acquirer와 판매자 (운영자) 간의 합의로 성공적으로 캡처 된 거래를위한 자금이 판매자 계정으로 이전됩니다.
컷오프 - 특정 청구주기 (일반적으로 공급자 시간대의 고정 시간) 에 해당하는 일일 "슬라이스" 작업.
T + N-자금 게시 지연에 대한 일반적인 표기법: T-컷오프 날짜, N-실제 등록 전 근무일 수.

• 카드 (비자/마스터 카드): 종종 T + 2/T + 3 뱅킹 일, UTC 23:00 (대략) 차단.
• A2A/오픈 뱅킹: T + 0 ~ T + 1.
• SEPA 크레딧 전송: T + 1/T + 2 (Instant - T + 0).
• ACH (미국): T + 2/T + 3; 같은 날 ACH-T + 0/T + 1.
• RTP (미국): T + 0이지만 보고서 차단이 가능합니다.
• 암호화: 실제로 네트워크를 통해 T + 0이지만 PSP는 자체 자금 조달 창 (T + 0/1) 을 적용 할 수 있습니다.

2) 컷오프 작동 방식과 작동 방식

1. 공급자는 수집 창을 수정합니다 (예: 00: 00-23: 00 UTC).
2. 이 창의 모든 정산/캡처 트랜잭션은 배치에 속합니다.
3. 총 자금 및 순 자금을 계산하기 위해 패키지에 반환, 청구 백, 수정이 집계됩니다.
4. 컷오프시 결제 파일이 생성되고 등록 전에 T + N 타이머가 시작됩니다.

중요: 캡처없는 승인은 패키지에 포함되지 않습니다. 취소 된 결론-또한 아닙니다.

3) 정산 유형: 총 대 순, 준비금 및 수수료

총 결제 - 총 캡처 금액이 이전됩니다 (별도의 수수료 빼기).
순 결제-공급자는 수수료, 청구 거절, 환불, 롤링 리저브 및 순액을 보유합니다.
롤링 리저브-위험을 충당하기 위해 N 일 동안 이직률의% (예: 180 일 동안 10%) 를 원천 징수합니다.
음의 이월-" 순 "이 하루에 마이너스로 들어가면 다음주기에 적자가 이전되고 상환됩니다.

권장 사항: 운영 총 (거래 별) 및 자금 조달 순 (공급자 파일 별) 두 비행기의 암호 해독.

4) 시간대, 로컬 출력 및 DST

컷오프는 공급자의 시간대에 따라 결정되며 귀하와 다를 수 있습니다.
DST (일광 절약 시간) 를 고려하십시오-슬라이스는 현지 시간에 비해 8 시간 씩 이동할 수 있습니다.
수령 은행 관할권의 공휴일/주말은 T + N의 N에 영향을 미칩니다 (예: T + 2 은행 일은 공휴일에 T + 4가됩니다).
실습: UTC의 모든 기술 시간을 정규화하고 동시에 'provider _ tz _ cutoff _ at' 및 'local _ tz _ posted _ at' 를 저장합니다.

5) 정산 일정 (자금 일정) 및 SLA

해당 분기의 합의 일정을 작성하십시오

각 방법/PSP에 대한 차단 시간 및 tz,

표준 T + N 및 예외 (휴일),

예상 금액 (예측),

SLA 영수증: 예를 들어 "T + 2의 12:00 유럽/키예프"

SLA 편차 → Ops/Finance 경고 및 티켓.

6) 순 예금 및 출력과의 관계

ND (순 기부금) 는 결제 된 거래에 포함됩니다 (관련 기사 참조).
결론 (인출) 은 예금에 대한 PSP의 자금에 참여하지 않지만 판매자의 현금 데스크에 영향을 미칩니다.
유동성 계획: 결제/유출/지불/세금/운영 비용으로 유입됩니다.

7) 조정 및 공급자 아티팩트

• 'batch _ id/relation _ id', tz 제공자의 컷오프 날짜,
• 님보다 더 많은 정보를 얻을 수 있습니다
• 메소드/판매자 계정 ('MID', '디스크립터', 'MCC') 별 암호 해독,
• 트랜잭션 참조 ('provider _ tx _ id', 'rrn', 'arn' -if cards),
• 파일

조정은 두 가지 방향으로 진행됩니다

1. 트랜잭션에서 파일까지 (파일에 있다고 생각한 모든 것?)

2. 파일에서 트랜잭션까지 (파일의 모든 것이 상점에 있습니까? 상태가 일치합니까?)

8) 지불 레일의 세부 사항 (일반적으로)

지도: 빈번한 프리젠 테이션 지연 시나 늦은 '차지 백' 이 가능합니다 (사건의 경우 최대 120-540 일). 교환 및 체계 수수료는 파일에 표시되며 ND에서 공제되지 않습니다.
SEPA/ACH: 배치는 은행 창에 따라 다릅니다. 취소/반품에는 자체 코드가 있습니다. 당일 옵션은 별도의 컷오프입니다.
오픈 뱅킹/A2A: T + 0/1이지만 파일은 사후 기능을 수행 할 수 있습니다. 일치하는 경우 엄격한 RPP/Unique ID가 필요합니다.
RTP/Instant: 돈이 빨리오고 있지만 보고서 파일이 예정되어 있습니다.
Crypto: 온 체인 결제 순간이지만 공급자는 '지불 창' 을 만듭니다. 'fx _ at _ settle' 을 저장하십시오.

9) 회계 (FI/회계)

9. 1. Accrual vs 캐시 방법

경영진보고의 경우 발생이 자주 사용됩니다. '정착 된 _ at' 시점의 수익/이동을 인식합니다.
재무부/DDS-캐시 방법의 경우: 'funded _ at' 영수증의 사실을 인식합니다.

9. 2. 일반적인 배선 (단순화)

• JT: PSP와 합의 된 현금 (AR: PSP)
• KT: 플레이어 약속 (지갑/플레이어 잔액)

• Dt: 은행 (출납원 사무실)
• Kt: PSP와의 합의에 따른 현금
• JT: 비용 (PSP 수수료), JT: 조항 (변경된 경우)

추적을 위해 뭉치 'trange _ id → batch _ id → funding _ id' 를 저장합니다.

10) 위험 관리 및 경고

누락 된 파일: X: YY-P1 이전의 결제 파일이 없습니다.
자금 지원 지연: T + N이 만료되었으며 돈이 없습니다-P1.
델타 임계 값: 분산 'our _ gross' vs 'File _ gross'> 0. 5% - P2; 범위를 벗어난 '수수료' - 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) 가장자리 케이스 및 처리 방법

늦은 프레젠테이션: 트랜잭션이 다음 배치에 들어갔습니다. "소스의 사실" ('발표 된 _ in _ batch _ id') 을 유지하십시오.
부분 캡처: 인증 당 다중 캡처-배치에서 올바르게 집계됩니다.
다중 MID: 하나의 공급자, 지리/브랜드별로 다른 MID-하나의 배치로 혼합되지 않습니다.
재 처리: 파일이 막히면 'batch _ revtion' 버전 지정 및 전체 재정의됩니다.
FX 레이스: 코스 - '정착 _ at'; 다른 통화로 자금 조달-' fx _ at _ funding '및 델타 시작.

15) 대시 보드 및 KPI

자금 지원 ETA: 예상 수령 날짜/시간 대 실제.
적중 SLA: 정시에 도착하는 파일의 백분율.
공급자 별 델타 총/순, 방법, MID.
볼륨, 예비 잔액, 네거티브 캐리 오버 행진의 수수료.
휴일 영향: 휴일과 함께 예측 대 실제 예측.

16) 모범 사례 (짧은)

1. 시간을 UTC로 정규화하지만 차단 공급자 _ tz를 유지하십시오.
2. 별도의 운영 총 및 자금 조달 순; ND와 자금을 혼동하지 마십시오.
3. 사전 입력 된 공휴일로 자금 일정을 구현하십시오.
4. SLA/델타에 결제 파일 + 경고의 가져 오기 및 조정을 자동화하십시오.
5. 구현 배치 _ 개정 및 결정 론적 재 프로세스.
6. 단일 진실의 원천을 입력하십시오: '거래 배치 자금 조달' 링크.
7. 분쟁에 중요한 ARN/RRN 및 카드 획득 필드를 저장하십시오.
8. 주말/공휴일, 준비금 및 수수료를 고려한 현금 흐름을 예측하십시오.

17) 구현 점검표

데이터 및 다이어그램

• 지불 _ travelings '지불', '결제 _ batches', '자금 지원 영수증', 'recon _ links'.
• 시간대는 UTC + 공급자 _ tz입니다.
• 자격증 FX: 'fx _ rate _ at _ settle', 'fx _ at _ funding'.

수입 및 검증

• CS/XML/JSON 파서 + 파일 해시.
• 금액/통화/날짜의 검증; 공급자 _ tx _ id/ARN '과 일치합니다.
• 핸들러 "늦은 프레젠테이션", "부분 캡처", "반전".

운영 및 경고

• SLA 모니터 차단, 누락 된 파일, 자금 지원 지연.
• 델타 임계 값 경고 (총, 수수료, 순).
• 휴일 영향 및 부정적인 이월 보고서.

18) FAQ

Q: T + 2가 왜 T + 4가 되었습니까?
A: 특파원 은행 또는 수령 은행에서 주말/공휴일이있었습니다. см. 자금 조달 일정.

Q: 순 계산보다 순 파일이 적습니다. 무엇을 볼까요?
A: 수수료, 예약 _ delta, 늦은 환불/요금 환급 및 과정의 정확성을 확인하십시오.

Q: 크립트를 어떻게 설명합니까?
A: 'setted _ at' 에 해당하는 fiat; 자금은 USDT/fiat에 올 수 있습니다-별도의 'fx _ at _ funding' 을 유지하십시오.

Q: 모든 공급자에게 하나의 공통 차단이 가능합니까?
A: 아니요, 각 PSP에는 tz/hour가 있습니다. 슬라이스 위에 집계 디스플레이를 만드십시오.

요약

정산주기와 컷오프는 통화 물류의 "골격" 입니다. T + N에 대한 올바른 회계, 시간대, 공휴일, 준비금 및 수수료는 다음을 허용합니다

공급자를 정확하게 확인하십

유동성 및 보상 지불 예측,

SLA를 준수하고 운영 위험을 줄이십시오

재무 및 규정 준수와 동일한 언어를 사용하십시오

단일 자금 조달 일정, 엄격한 데이터 모델 및 자동화 된 조정을 구현함으로써 현금 흐름을 예측 가능하고 관리 할 수 있습니다.