Belyfted - Global Fintech & Remittance Platform

Moving Money Between Three Continents

Belyfted is a cross-border remittance platform. Someone working in London, Berlin or New York opens the app, sends money home, and a recipient collects it as cash, receives it into a bank account, or takes it straight onto a mobile money wallet. The send side spans the UK, the EU and the United States. The receive side reaches thirty-three African nations along with Indonesia, the Philippines, Thailand and Vietnam.

THESOFTKING was brought in for technology consultancy and built the money-moving core, the web platform and the mobile apps for both iOS and Android. Five people over ten months, for a business regulated as a payment institution, where a transfer that goes wrong is not a bug report but somebody's rent.

The Challenge: Every Country Is a Different Product

From the sender's side a remittance app looks like one screen: an amount, a recipient, a button. Behind it, almost nothing is shared between one destination and the next. Payout in Nigeria works differently from payout in Kenya, which works differently again from payout in the Philippines. Different partners, different interfaces, different settlement behaviour, different failure modes, different ideas about what a completed transaction even means. Every market added is a new integration, and none of the previous ones make it easier.

Underneath that sits the constraint that makes payments different from ordinary software: money must not be created or destroyed. A payout that silently fails is a customer whose family did not receive their money. A payout that succeeds twice is money the business will not get back. And because the platform sits behind partners it does not control, the interesting cases are never the clean ones. They are the timeout with no response, the callback that arrives twice, and the confirmation that comes hours after everyone assumed the transfer had failed.

All of this is delivered to people for whom the stakes are entirely personal, on the two or three days a month when they have money to send, often from a phone on a mobile connection. The product has to feel simple to somebody who does not care how any of it works and cannot afford for it to go wrong.

Payout Rails: Many Partners, One Interface

The bulk of the engineering on a remittance platform is not the app. It is the long tail of payout integrations behind it, and there is no shortcut through them. A direct bank integration such as Zenith Bank in Nigeria arrives with its own protocol, its own authentication, its own field requirements and its own opinion about how and when it will tell you a payment completed. A mobile money operator in another market shares none of that. Multiply by dozens of partners across thirty-three African nations and four Southeast Asian markets, and integration work is the product.

The design answer is a single internal representation of a transfer that every partner is adapted onto, rather than letting each integration leak its own vocabulary into the platform. A transfer moves through the same defined states regardless of destination, and each partner integration is responsible for translating between those states and whatever that particular institution does. It costs more upfront than wiring each partner straight into the flow. It is the only version that survives the twentieth integration, because the alternative is a codebase where adding a market means touching everything.

That structure is also what makes partner failure survivable. Payout partners go down, time out, and answer late. Because every one of them is adapted onto the same set of states, a transfer always has a defined position and a defined next action, whatever the partner on the other end happens to be doing. Nothing gets to sit in an undefined condition simply because an institution abroad did not reply.

One Rate, Set by the Business

Belyfted advertises a stable, universal rate, and that is a deliberate commercial decision rather than a technical shortcut. Rates and corridor pricing are set by the business through an admin console instead of being passed straight through from a live market feed. The sender sees one rate, and it is still that rate a minute later.

The trade is straightforward. Passing the market through directly protects the business from every intraday movement and pushes that uncertainty onto the customer, who then sees a number that shifts while deciding. Setting rates deliberately means the business carries the movement between updates and the customer gets certainty. For remittance, that is the right way round. Someone sending money home is not trading currency, they are trying to make a specific amount arrive, and a rate that moves while they are thinking about it is a reason to close the app.

Identity, Before the Money Moves

Belyfted Limited operates as a regulated payment institution, and identity verification and screening are not features it can choose to add later. They are conditions of doing business at all. The engineering question was never whether to verify a sender, but where verification sits in a flow that also has to feel effortless to someone sending money for the first time from a phone.

Verification and screening run through established third-party providers, integrated into the transfer flow rather than parked alongside it. That boundary was chosen deliberately. Identity verification and sanctions screening are specialist, continuously maintained disciplines, and a payments platform is better served by connecting to providers whose entire business is keeping those checks current than by reimplementing them. Belyfted's own team owns the monitoring and the decisions that follow; the platform's job is to make sure a transfer cannot progress until the checks it depends on have returned.

The user-facing consequence is a flow where verification happens once, at the right moment, with a clear explanation of what is needed and why. Getting that sequencing right is most of the difference between a compliant product people complete and a compliant product they abandon.

One Product, Three Surfaces

The apps are built in Flutter and ship to both iOS and Android from one codebase, with the web platform in React on a Laravel backend. For a product whose value is the same on every surface, this was a straightforward call: the difficulty in remittance is the corridors and the partners, not the interface chrome, and a team of five was better spent on payout integrations than on maintaining two native apps that do the same thing.

The mobile side deserved the emphasis it got, because that is where the money is actually sent. Senders are frequently on mobile data, often abroad, and typically doing this at the end of a working day. The send flow is short, the rate and the exact amount the recipient will receive are visible before anything is confirmed, and the status of a transfer in progress is always answerable without contacting anyone. Most trust in a remittance product is built in the minutes after the send button, not before it.