BFC Pay Portal
BFC Pay is the online portal of a Bahrain-based money transfer and currency exchange business, where customers check live rates and send remittances. I worked across the stack: React modules on the front, Node.js and Rust services behind them, and the API contracts in between.
- React
- Node.js
- Rust
- REST APIs
Particulars
- Client
- BFC, Bahrain
- Domain
- Remittance, currency exchange and bill payments
- Role
- Full stack engineer
- Scope
- Portal UI modules, API integration, Node.js and Rust services
Note: Some implementation details are omitted for confidentiality. This case study covers my role, public product behaviour and general architecture only.
Record summary
7+
Currencies on the rate board
2
Backend runtimes
3
Product lines
01The mandate
Remittance customers want two things: a good rate, and certainty that their money arrives. The portal has to show live per-currency rates for account credit and cash pickup, and carry a transfer from quote to confirmation without ambiguity.
Behind that sits a mix of services, and much of the work was keeping the experience coherent as features moved across them.
02What I owned
I developed and enhanced React UI modules and application workflows, integrated them with REST APIs and connected frontend features to backend services. When behaviour broke across that boundary, I traced it end to end.
On the backend I supported Node.js development and API-level improvements, and contributed to building and integrating Rust-based services. Alongside feature work I refactored existing code for readability, maintainability and reuse, so each change was cheaper than the last.
03Two runtimes, one contract
The portal talks REST to a backend split between Node.js and Rust services. Keeping that workable meant treating API contracts as the stable surface: the UI depends on response shapes and status codes, not on which runtime serves them, so services can evolve without the screens noticing.
Fig. 01
04Working flow
How a transfer moves through the system, from the live rate board to a confirmed outcome. The portal only ever depends on the API contract.
Fig. 02
01 Opens the rate board
02 Requests live rates
03 Fetches rates per currency
04 Account credit and cash pickup rates
05 Chooses payout, enters beneficiary and amount
- 06 Validates inputs before submission
07 Submits the transfer
08 Processes it in the Node.js and Rust services
09 Transfer status
10 Confirmation or an explicit error
11 Shows a clear outcome
05Hard parts
- Money leaves no room for ambiguous UI: every loading, failure and success state had to be explicit.
- Debugging issues that crossed React, REST and two backend runtimes.
- Refactoring code in a payments product without changing behaviour customers relied on.
- Contributing to Rust services alongside Node.js while keeping their APIs consistent for the frontend.
06Outcomes
- Portal workflows stabilised through cross-layer troubleshooting.
- A more readable, reusable frontend codebase after targeted refactors.
- New backend APIs, including Rust-based services, integrated with the portal.
07How I approached it
- 01
Contracts over coupling
The UI should depend on what an API returns, not on how it's built.
- 02
Be explicit about money
Every state a payment can be in deserves its own screen state.
- 03
Follow the bug across the boundary
Full-stack ownership means not stopping at the network tab.
- 04
Leave it better than you found it
Small refactors with every feature kept the codebase moving.
Related work
More projectsKurlClub
SaaS platform, React, Next.js, TypeScript
HR Platform
Enterprise HR, React, Node.js, JWT
HI5 Overseas
Client application, Next.js, TypeScript, Node.js
Subscriptions
SaaS platform, React, Node.js, Express
