Financial services · Crypto exchange
Payment automation for a crypto exchange
Manual deposit tracking replaced with a payment gateway that cannot double-count a transaction.
The problem
The exchange tracked blockchain deposits by hand. Every deposit was a person checking a node, then typing the result into a CRM — which meant every deposit was also a chance to lose money to a typo or a missed confirmation. On top of that, they were paying a monthly subscription for third-party courier software that didn't match how their couriers actually worked.
What we built
A connected system linking their Odoo ERP, their Telegram bots, and the blockchain nodes they trade on (Binance, Bybit, Tron). Deposits are detected, validated, and recorded automatically. Courier tasks are generated and routed from the same system, which let them drop the outside delivery service entirely. Lead follow-up runs on rules instead of on someone remembering.
What it changed
No duplicated or lost transactions
The payment gateway is idempotent by design: the same deposit processed twice produces one record, not two. For a business moving client funds, this is the difference between a reconciliation and an incident.
One SaaS subscription removed
The courier logistics module is in-house and shaped around their actual routes, so the recurring third-party fee went away.
Lead follow-up runs without a human
Notifications, stage moves, and scheduled activities fire on their own, including outside working hours.
How it worksthe engineering detail
Written for the person your CTO forwards this to.
Exactly-once processing
The webhook orchestrator uses dual-layer idempotency — Redis atomic locks (SET NX EX, 12h TTL) plus a UNIQUE constraint in a WAL-mode SQLite local queue. A duplicate webhook cannot produce a duplicate financial record.
Failure handling
A worker queue with exponential backoff (1 / 5 / 15 / 60 min) and a dead letter queue. Transient network errors retry; business-logic validation failures go to a separate delayed schedule instead of burning retry attempts.
CRM rule engine inside Odoo
A stage-automation engine built natively on Odoo's Python ORM. Race conditions between parallel Odoo workers are resolved with epoch counters (entry_seq); duplicate client notifications are prevented by SHA-256 hashing of message payloads.
Polyglot concurrency
Python asyncio handles high-throughput I/O in the Telegram bots; Java 21 virtual threads (Spring Boot 3) handle concurrent third-party API calls.
Patterns — Idempotent Receiver · Worker Queue · Service Layer · Strategy · Distributed Locking
Stack