← PRODUCT
PRODUCT · DECIDE

GateReconcile: settlement reconciliation

Ledger, processor and on-chain amounts compared per deposit; a mismatch opens a case and fires a webhook.

Ledger credit5,000.00Processor settlement4,998.50On-chain transfer5,000.00 USDTtolerance 0.5%MATCHEDmax Δ 1.50 = 0.03%, within 0.5%Ledger credit5,000.00Processor settlement4,998.50On-chain transfernot observedtolerance 0.5%INCOMPLETEon-chain leg not observed, so never assumed

Start free sandboxTalk to us50 screenings a month free, no card.

On this page

GateReconcile in simple terms

For each deposit, GateReconcile compares three numbers: what your books credited, what your payment processor says it settled, and what really moved on the blockchain.

If they disagree by more than half a percent, or the money went to the wrong address, a case opens the same day.

IN EVERYDAY TERMSThink of checking the till receipt, the card terminal slip and the cash in the drawer against each other at closing time.

What it does

GateReconcile compares three legs of one deposit: what your ledger credited, what your processor says it settled, and the canonical USDT/USDC transfer amount read from the on-chain receipt. Any pair further apart than the tolerance (0.5%) or a wrong on-chain recipient is a MISMATCH.

A mismatch annotates or opens the case on that deposit's screening and emits a reconciliation.mismatch webhook. Legs you did not give, or that could not be observed, make the result INCOMPLETE, never a silent match.

Why a broker needs it

The three numbers should agree, and often do not. Typical causes are a fee taken silently, a wrong recipient, a double credit, or a transaction hash reused for two deposits. Reconciling each transaction turns a monthly accounting surprise into a same-day case with the evidence attached.

How it works

POST /api/v1/reconcile with any of ledgerEventRef (your credited deposit event), processor + processorTxId (a processor signal whose payload carries a settlement block) and chain + txHash (plus an optional expectedRecipient). KYTGate reads the transfer from the chain, matches the legs, applies the tolerance and stores the outcome with the deposit. Outcomes also appear in the monthly compliance report.

What it does not do

GateReconcile checks amounts and recipients; it does not move funds, reverse credits or contact the processor. It can only compare legs it was given. Without a processor settlement block the processor leg is INCOMPLETE, and non-stablecoin transfers are not amount-verified.

API

POST /api/v1/reconcile
{
  "ledgerEventRef": "dep-10293",
  "processor": "acme-pay", "processorTxId": "abc-123",
  "chain": "ethereum", "txHash": "0x…", "expectedRecipient": "0x…"
}
→ { "status": "MISMATCH" | "MATCHED" | "INCOMPLETE",
    "legs": { "ledgerUsd": 25000, "processorUsd": 24750, "onchain": { "amount": "…", "token": "USDT", "recipient": "0x…" } },
    "findings": [ … ], "caseId": "…", "tolerance": 0.005 }

Full reference: /docs#reconcile · OpenAPI 3.1

Start free sandboxRead the API docs Talk to us