Payments and crypto back office at a live broker
Wallet payment methods in production, crypto back-office APIs with field-level permissions, and cross-service debugging on an event-driven platform at CFI Financial.
- Role
- Senior Backend Engineer
- Type
- Built in my full-time job at CFI Financial
- Period
- Jul 2026 to Present
- Status
- In production · my current full-time role
CFI Financial is an online multi-asset broker (FX/CFD and crypto). I work on its crypto trading platform and its payment-provider integrations: Python services on PostgreSQL and MySQL, with RabbitMQ keeping a client portal and a back office in sync. Anything internal to CFI is left out on purpose.
The problem
A regulated broker keeps adding payment methods and crypto features to a platform that already serves clients. Every change touches money, permissions and two systems that must stay in step: the client portal and the back office.
Why it was hard
- Deposits and refunds run through a payment provider with sessions, webhooks and wallet-specific rules for Apple Pay and Google Pay.
- Crypto amounts need 8-decimal precision through every API, model and permission definition, not only in the database.
- Back-office actions follow maker-checker approval, with access control down to individual fields.
- State crosses services through RabbitMQ. A field dropped anywhere on the path fails silently.
Architecture
Python services (FastAPI, SQLAlchemy, Pydantic) on PostgreSQL and MySQL. A client portal and a back office each own their data and exchange changes as RabbitMQ messages. Payments go through Checkout.com. Access control is policy-based (Casbin) and reaches individual fields. Logs are searchable by correlation id in Grafana and Loki.
- Python
- FastAPI
- SQLAlchemy
- Pydantic
- PostgreSQL
- MySQL
- RabbitMQ
- Redis
- Docker
- Kubernetes
- Casbin
- Checkout.com
- Grafana / Loki
- SonarQube
What I built
Senior Backend Engineer
- 01Delivered Apple Pay, Google Pay and Benefit as separate Checkout.com deposit methods for the Bahrain entity. All three are live in production. Wrote the team's end-to-end local testing guide for deposits and refunds.
- 02Took on 26 backend tickets in my first two months on the crypto platform, across 7 services and shared libraries: back-office API, access-control API, two RabbitMQ consumer services, client-portal API and two shared Python libraries.
- 03Built paginated, filterable list and CSV/PDF export endpoints with field-level permissions (Casbin) for the maker-checker order-cancellation flow.
- 04Extended 8-decimal precision for crypto amounts across APIs, models and access-control definitions.
- 05Added Braze events for first deposits.
Decisions and challenges
One deposit method per wallet
Apple Pay, Google Pay and Benefit were delivered as separate deposit methods, not as variations of one card flow. Each has its own session rules and was tested end to end before release.
Write the local testing guide
Running a deposit and a refund end to end on a laptop was undocumented. I wrote the guide, traps included, so the next engineer does not start from zero.
Prove the cause before changing code
The trade failure was reproduced and traced to its data cause first. The fix then went into symbol resolution, the one place every order path shares, instead of patching the endpoint that happened to fail.
Fix both ends of a message, consumer first
The KYC field was lost twice, at the producer and at the consumer. Fixing one side would have passed review and still failed in production. The consumer ships first so it never rejects a message it does not yet understand.
Stories worth telling
An HTTP 500 on crypto trades: I traced it by correlation id in Grafana and Loki to duplicate asset-pair records, then made symbol resolution deterministic. That also closed the same failure on the market-order and limit-order paths.
A KYC edit in the back office never reached the client portal. The payload was being dropped at both the RabbitMQ producer and the consumer. I reproduced it on the exact pinned library versions and confirmed it in logs before designing the fix.
Verified outcomes
- Apple Pay, Google Pay and Benefit are live in production as deposit methods.
- 26 backend tickets delivered in the first two months, across 7 services and shared libraries.
- List and export endpoints with field-level permissions in use for the maker-checker order-cancellation flow.
- 8-decimal precision for crypto amounts across APIs, models and access-control definitions.
Numbers
- 3 wallet payment methods live
- 26 tickets in the first two months
- 7 services and shared libraries
- 8-decimal crypto precision
What this shows a client
I work inside a live brokerage every day: payments, permissions, precision and event-driven sync. When I design a back office or a payment flow for your product, it comes from systems that run with real client money.
Tell me what you are building.
A few lines are enough: what it is, where it stands today, and what you need from an engineer. The form is just below, or email me if you prefer. I reply within two working days.