Reference build: a stablecoin payment gateway
A stablecoin PSP collects USDT and USDC, screens the funds it receives, and settles to merchants. This build combines the payment, compliance and settlement primitives so acceptance and AML share one backend and one key.
The challenge
Accepting stablecoins compliantly usually splits across a payment processor, a screening vendor and a settlement rail. The goal is to collect, screen and settle from one balance, with signed events that reconcile without double-counting.
- Invoices / checkoutC2
- Transaction screening / KYTC3
- Sanctions check + feedC2
- Mass payout / settlementC2
Collect with invoices
Create an invoice per order and present the hosted checkout. Underpayment, overpayment and confirmations are tracked for you, so the merchant integration stays thin.
Screen incoming funds
Route each settled payment through KYT and run a sanctions check against a maintained feed before releasing it. Store the allow/review/block decision with the payment so acceptance is auditable.
Settle to merchants
Disburse cleared balances to merchants with mass payout from the same balance, broadcasting transfers and tracking each to confirmation.
What the build delivers
- USDT/USDC collection and merchant settlement on one balance
- Incoming funds screened by KYT and sanctions before release
- No separate processor, screening and settlement contracts to maintain
Frequently asked
Is screening applied before settlement?
Yes — KYT and the sanctions check run on incoming funds, and only cleared payments are settled to the merchant.
How is reconciliation kept consistent?
Collection, screening and payout run on one balance with signed, idempotent events, so a duplicate delivery can't double-credit an order.
Top up, get a key, ship.
Self-serve. Pay in crypto or card. Metered by credits — heavy primitives cost more, simple ones are cheap.
Get API key