Merchant Platform
A payments platform for merchants: accepting payments, merchant dashboards, roles, integrations with payment providers in different countries.
The problem
The business needs to accept payments in several countries through different providers, and still give merchants one clear dashboard: balance, transactions, payouts, staff roles. Every new country means a new provider with its own API, its own statuses and its own rules, and all of it has to look the same to the merchant.
My role
I design the platform and write a large part of the code. The team also has one more engineer, a product owner and an operations team that works with merchants.
- Architecture: how payments, dashboards and integrations are built, and where the boundaries between them are.
- Specs: I describe APIs and scenarios before development starts, so the team and partners work from the same document.
- Development: backend, provider integrations, part of the dashboards.
The solution
The payment flow is separated from the providers: inside there is one model of a transaction and its statuses, and each provider plugs in through an adapter. So a new country means a new adapter, not a rework of the platform.
- One API for merchants and internal dashboards.
- Roles and permissions: the owner, the finance person and the operator each see different things.
- Events for every transaction, so any disputed payment can be traced.
The result
The platform is live with two countries connected and four more in the near-term plan. The adapter approach has already paid off: connecting the next provider follows a well-worn path, with no changes to the core.
Stack
- Python, FastAPI, SQLAlchemy — API and business logic.
- PostgreSQL — transactions, balances, events.
- React — dashboards for merchants and the operations team.
- Docker Compose, pytest — deployment and tests.
Materials
[Dashboard screenshots and a payment flow diagram — once it is agreed what can be shown publicly.]