A global second-number platform: app, backend and operations console
A client engaged Paymentery to build a product that lets a person obtain a virtual phone number in another country and call and text from it, in Arabic and English. The client is not named at their request. The development scope described here was completed and handed over; what remains before launch is listed in the closing section.
The requirement
The product had to stay simple for the person using it: get a number, call, text, manage. Behind that sit a carrier API for real telephony, subscriptions and payments, regulatory requirements that differ from country to country, and an operations team that needs to see numbers, calls, money and abuse without touching the database.
Both languages had to be first-class from the first screen, on iOS and Android, and the telecom complexity had to remain in the backend and the console rather than leak into the app.
What was built?
Mobile app
A Flutter application for iOS and Android: a number catalogue by country, purchase and activation, calls over the internet with the native incoming-call screen, messages, voicemail, number settings, notifications and billing. Arabic and English are switchable from the first screen.
Backend
A modular NestJS service on PostgreSQL and Redis: accounts, catalogue, orders, subscriptions, calls, messages, compliance, fraud controls, ledger, webhooks and background queues, all published under one documented API contract that the app and the console are tested against.
Operations console
A web dashboard for the operations team: users, numbers, calls, messages, orders, payments, refunds, compliance review, a fraud queue, an audit log and system health. Access requires a second factor and is limited by role.
Design system
A Figma file with variables, components and the full set of English and Arabic screens. Design tokens are generated from one source into both the app and the console, and the build fails if either drifts from it.
Engineering decisions
One carrier interface
Business logic never talks to the carrier directly. Every number operation goes through a single adapter interface, so the carrier can be exercised in tests with a mock and replaced without rewriting the product. The carrier remains the source of truth for what a number can do.
Capabilities as data
Every number and offer stores what it actually supports: inbound and outbound voice, SMS, MMS, voicemail, forwarding, and whether identity documents or an address are required. The app shows only what is proven, never an assumed feature.
Compliance as data
Regulatory requirements are fetched from the provider per country and stored as data, with required fields and documents modelled explicitly. Nothing about a country’s rules is hard-coded, so a change at the provider does not require a release.
Explicit states
Calls, messages and subscriptions follow defined state machines, and an incoming webhook can never move a finished record backwards. Calls are modelled as a call with legs, so a forwarded or conferenced call is described accurately.
Money that cannot be edited
Balance is an append-only ledger, never a field that is overwritten. Each order snapshots the provider cost, retail price, exchange rate and tax at the moment of purchase, and every purchase, payment, refund and message send carries an idempotency key.
Webhooks and queues
Provider events are signature-verified on the raw body, de-duplicated by event ID, protected against replay and processed asynchronously. Critical internal events go through a transactional outbox, and queues have retry, back-off and a dead-letter path visible in the console.
Arabic as a first language
The Arabic interface was designed natively in Figma rather than mirrored afterwards. Phone numbers, country codes, durations and technical identifiers stay left-to-right inside Arabic text through explicit bidi isolation, and every reusable component is catalogued in Arabic and English, with long text and a large text scale.
The operations console
The console is where telecom complexity is allowed to show. Operators can inspect a number’s lifecycle and release it with confirmation and an audit entry, review compliance submissions, work the fraud queue, follow a payment to its ledger entries, and see provider latency, webhook failures and queue depth on one screen.
Quality and security
- Automated unit and integration tests for the backend, including integration tests against real PostgreSQL and Redis instances, and provider contract tests covering success, rate limits, timeouts, duplicate webhooks, invalid signatures and provider errors.
- Contract tests that bind both the app and the console to the published API description, so a change in one side fails the build of the other.
- End-to-end flows on an Android emulator in both languages, including the full purchase path and an Arabic call screen, plus Playwright tests for the console against the live API.
- Load tests against the API for search, sign-in, webhook ingestion and message sends, which surfaced and fixed a rate limiter that would have throttled everyone behind one shared IP together.
- Secret, dependency and vulnerability scanners run as mandatory gates, with no bypass. Passwords use Argon2id, refresh tokens rotate, console access needs a second factor, and identity documents are encrypted at rest and served only through short-lived links.
- Carrier and payment secrets never reach the app; the app receives only short-lived client tokens.
What the product tells its users
The app carries the disclosures a product like this needs rather than hiding them: it is not a replacement for a primary phone line and does not support emergency calls; whether a verification code from a bank or messaging service arrives is decided by that service, not by the app; and demo data is marked as such wherever it appears.
It is a personal communication product, so bulk messaging is not offered and rate and velocity limits with abuse detection are built in.
Result
Delivered and handed over: the source of the app, backend and console; the Figma file; the API contract; infrastructure definitions with monitoring and a rehearsed backup and restore; continuous-integration pipelines with the test and security gates above; and technical documentation covering architecture, the number lifecycle, calling, messaging, compliance, fraud, payments and billing.
Going live depends on accounts only the client can hold: the carrier’s production account and resale approval, the payment provider, the app-store accounts and an Apple build environment. Those steps are documented as a launch checklist and were outside the development scope. Screens on this page use demo data; no real numbers or payments are shown.
Building a communication or subscription product?
Describe the requirement and the countries involved. The provider, compliance and store constraints are assessed before the scope is defined.