Card and local gateways
Checkout that fits the market: the methods people there actually use, not the ones easiest to integrate.
Payments, including crypto
Card checkout, Telegram Pay and Stars, and on-chain settlement across five networks. The part that matters is never the button.
What we build
Telegram Pay and Stars
Payment inside the chat, where the customer already is, with the receipt delivered to the same place.
On-chain settlement
USDT on TRC20 and BEP20, TON, BTC, ETH. Unique amounts or memos so two payments can never be confused for each other, a background monitor that confirms on chain, and a manual hash entry for when it does not.
Payouts and reconciliation
Money going out as carefully as money coming in: a queue, an approval, a record, and a nightly check that the ledger and the provider agree.
The part that is actually hard
Idempotent webhooks. A provider will deliver the same event twice — not might, will. If your handler credits an account each time it is called, you will discover this from a customer, not a log. Every payment path we build treats the provider's event ID as a unique key and makes the second delivery a no-op. The same discipline covers a user double-clicking Pay and a worker crashing between charge and record.
What you get
- Webhook handlers that survive redelivery
- Reconciliation between your ledger and the provider
- A payout queue with approval and an audit trail
- Sandbox and production paths that differ only by keys
Stack Python · FastAPI · PostgreSQL · Telegram Payments · TRON · TON · EVM
Start here
Describe it in a paragraph.
You will get a real answer from an engineer — what we would build, roughly what it costs, and honestly whether it is worth building at all.