Architecting the mobile POS app and white-label plug-in behind BankBox for Partners
Architecting the Android POS app and the white-label mobile plug-in for BankBox for Partners, the platform that lets banks and payment aggregators assign terminals to their merchants, set fees and track performance, while contributing to the overall product direction.
- Role
- Mobile Architect contributing to product direction
- Company
- RavenPay
- Stage
- Launched
- Team
- 2 product designers, 2 web engineers, 3 backend engineers, 3 mobile engineers, with Finance, Compliance and Partnerships
- Platform
- Web console, Android POS terminal app, mobile plug-in
- Pillars proven
- Mobile architecture · Delivery automation · Product direction
TL;DR
- Problem
- Partners distributing BankBox terminals went through Raven Operations by email and spreadsheet to assign devices and change fees. It was slow and error-prone, and it capped how fast partners could grow.
- What I did
- Architected the white-label plug-in and the POS app release pipeline, led the mobile engineers, and contributed to product direction, including the console scope and the fee model with Finance.
- Result
- Terminal assignment went from 3 days to under 10 minutes, 9 partners onboarded in 6 months, and Operations tickets from partners fell 70%.
Context
BankBox is Raven’s POS terminal for merchants. Growth depended on partners (banks, aggregators and agent networks) who bring merchants and terminals to market under their own relationships.
The problem
For partners
- Assigning or reassigning a terminal took 2 to 3 days of back-and-forth.
- Partners couldn’t set their own merchant fees or device prices, so they couldn’t build a business on top of BankBox.
- They had no live view of merchant performance or transaction volume.
For Raven
- Operations headcount grew with every partner, which didn’t scale.
- Manual fee changes caused billing errors and disputes.
Evidence6 partner discovery sessions; 300 Operations tickets per month from partners; 3 partners delayed signing because of manual onboarding.
The insight that changed the direction: Partners wanted control and a revenue line, while Raven needed oversight of devices, pricing and compliance. The product had to give both.
My role
I owned the mobile architecture of the POS app and the plug-in from design to launch and led the mobile engineers who built them. I also contributed to product direction alongside Partnerships, Finance and the design team.
- 1
Architected the white-label plug-in
Partner name, logo, welcome message and brand colour load at runtime, so a new partner needs no app rebuild.
- 2
Set up the POS app release pipeline
Staged over-the-air rollouts by partner group, with automatic halt on error spikes.
- 3
Shaped the multi-tenant model with backend
Partner → merchants → terminals, with role-based access and tenant isolation that both the POS app and plug-in rely on.
- 4
Contributed to product discovery
Took part in sessions with 6 partner organisations and helped map three users: the partner’s executive, their operations staff and their merchants.
- 5
Helped define the console scope
Overview, merchants, terminals, fee details, bank-switch requests, settlement, audit trails and compliance.
- 6
Worked with Finance on the fee model
Partners set merchant fees and device prices within a Raven floor and ceiling.
- 7
Specified audit trails and role access
With Compliance from day one.
Key decisions and trade-offs
| Decision | Why | What we gave up |
|---|---|---|
| Self-serve terminal assignment, with approval for new device requests | Partners wanted speed; Raven needed oversight of device stock | One approval step for new devices |
| Fee and price guardrails (floor and ceiling) | Partners earn a margin; Raven protects pricing and compliance | Full pricing freedom for partners |
| Runtime white-label config instead of a build per partner | One codebase; new partner branding in minutes | Deep custom layouts per partner |
| Console on web first, partner mobile app later | Partner operations teams work at desks | No mobile console at launch |
| Audit trail in v1, not later | Regulated payments and fee disputes need a full history | About 2 weeks of extra build time |
How it was built
- Plug-in
- A lightweight SDK that partners embed; branding and feature toggles are fetched from the console at runtime.
- POS delivery
- The terminal app ships through a CI pipeline with staged rollouts by partner cohort and automatic rollback.
- Quality
- Automated tenant-isolation tests, contract tests on fee calculations, and regression tests on the POS app before every rollout.
- Architecture
- A multi-tenant model (partner → merchants → terminals) with role-based access and strict tenant isolation, so one partner can never see another’s data.
Raven: oversight
Device stock · fee floor and ceiling · audit trail · compliance
Partner A
Roles · merchant fees and device prices within bounds · branding
Partner B
Strict tenant isolation: never sees Partner A’s data
White-label plug-in. The partner’s app embeds a lightweight SDK. Branding (name, logo, welcome message, colour) and feature toggles are fetched from the console at runtime, so a new partner needs no rebuild.
Terminals
Assign terminalMerchant fee
Raven floor 0.50%Your fee 0.75%Raven ceiling 1.00%
Results
-
3 days → under 10 min
Time to assign a terminal
-
9
Partners onboarded
-
−70%
Operations tickets from partners
-
2 weeks → under 1 hour
Time to brand the plug-in for a new partner
Blue: my team’s work. Black: feature- or product-level, shared with others.
Reflection
What I’d do differently
Ship reporting and exports earlier. Partners asked for downloadable merchant performance reports in their first week.
What it taught me
A partner product has three customers. The executive signs the deal, but the partner’s operations person decides if it gets used, so design for them.