Beyond the Buy Button: What It Takes to Run a Digital Payment and PPOB Ecosystem

Buying mobile credit takes a few seconds. You open an app, pick an amount, confirm, and a message arrives saying the credit has been added. Nothing about it feels complicated. In Indonesia, this kind of purchase belongs to a category called PPOB, short for Payment Point Online Bank: the everyday digital products people use to top up phones, pay electricity and internet bills, load e-wallets and send money. Millions of these small transactions happen every day, and almost nobody thinks about what it takes for one of them to work.

I have spent my career on the other side of that screen. I started in customer service at Metro Reload in 2019, moved into business development, and then into product, where I now lead product for Metro Reload and Cashplus. What I have learned is that the Buy button is the least interesting part of the product. Everything that decides whether the experience is reliable happens where the user cannot see it.

This article is about that hidden part. It comes from my own experience, and where I describe general industry practice, I say so.

A PPOB product usually passes through several hands before it reaches the person who pays for it. It starts with the provider that owns the product, such as a telecommunications operator, a utility or an issuer. It then passes through switching and aggregator companies (which I call Lv.1), a second-tier distributor (Lv.2), distributors at the third tier and beyond (Lv.3+), and merchants, before it reaches the end user.

Metro Reload and Cashplus sit at different points in that chain. Metro Reload works as a business-to-business distributor at the second tier (Lv.2): its customers are other businesses, not consumers. Cashplus works at the third tier and beyond (Lv.3+), serving consumers directly (B2C) as well as businesses that in turn serve consumers (B2B2C). It buys from Metro Reload and from other suppliers, which keeps product availability and pricing competitive, and gives it somewhere to turn when one source has a problem.

Not every process below is implemented in exactly the same way in both companies. Much of it is how this industry generally works, filtered through what I have seen.

It is tempting to think of a PPOB platform as one pipeline with different labels on it. In practice, each product behaves differently, and a platform has to support all of those behaviours at once.

Prepaid mobile credit and data are the high-frequency products. They generate the most traffic, carry the tightest service expectations and the thinnest margins, and in my experience they also attract more fraud attempts. Prepaid electricity tokens and postpaid bills such as utilities and internet work differently. Volumes are lower, and in normal conditions I have seen lower fraud exposure and fewer failures. But they need accurate billing inquiries, careful validation and payment confirmation, because the amount a customer owes has to be correct before they pay it.

The product that outsiders misunderstand most, in my experience, is the top-up. People tend to treat e-wallet top-ups and electronic money top-ups as the same thing. An e-wallet such as GoPay is an account balance held with a provider. Electronic money cards such as Mandiri e-Money, BNI TapCash, BRI BRIZZI or BCA Flazz are stored-value products, and depending on the issuer they can involve extra steps such as updating the balance on the card itself. They look alike to the user. They are not alike to the people building the flow, the integration, the support procedure or the error handling.

There is no universal transaction workflow, only several, and treating them as one is how platforms accumulate problems.

Margins in this business are thin, and pricing is a constant conversation. A distributor can buy at a discounted wholesale price and resell at a higher one, charge a fixed fee, add a markup over cost, or work under an agreed commercial margin or revenue share. Which of these applies depends on the product, the supplier agreement and the market.

Prices are not fixed for the day. A supplier's purchase price can change within the same day, though not necessarily often, and some days it does not change at all. Promotions, availability and commercial policy all play a part. Competition is real too: companies offer the lowest selling prices they can, and large buyers may get special arrangements for volume.

To make the economics concrete, here is a hypothetical example. It is illustrative only and is not real company pricing. Imagine a prepaid credit product with a face value of IDR 10,000, bought at IDR 9,700 and sold at IDR 9,850. The gross spread is IDR 150. That is not profit. Transaction costs, operations, support, failed transactions and everything else the business has to carry come out of it. When margins are this thin, a platform cannot win on price alone. A supplier who is slightly cheaper but fails more often is not really cheaper. Every failed or delayed transaction means a lost sale, a support case and a customer who may not come back, and those costs can quickly outweigh a small discount. So the question is never only "who has the lowest price?" but "who gives me the lowest price at a success rate I can rely on?" Balancing the two is a product decision as much as a commercial one.

One of the least visible parts of the system is the funding. Much of the PPOB ecosystem runs on prepaid deposits, or prefunded balances. In the chain I know, resellers keep a deposit with Metro Reload, Metro Reload keeps deposits with its upstream suppliers, and Cashplus holds prefunded arrangements with its own suppliers under their commercial agreements. Each time a transaction is processed, the relevant balance is deducted. The exact settlement and reconciliation arrangements depend on the relationship and the integration.

This makes liquidity an operational discipline. If the balance needed for a transaction is not there, the system returns an insufficient balance response and the transaction is not processed through that source until the balance is topped up. From the customer's side this can look like an unexplained failure. From the operator's side, watching balances and funding them in time is part of the job, and it is a good example of a responsibility that never appears in a feature list.

At a conceptual level, the journey from tap to result looks like this. The customer chooses a product. Where it is needed, the app does an inquiry or validation to confirm the details, which is common for bills and less so for some prepaid products. The customer reviews and confirms, and authenticates, for example with a transaction PIN. The platform validates the request and processes it through its internal services and the supplier integration, usually through an API or a host-to-host connection. The supplier returns a status, sometimes immediately and sometimes through a later update. The system records the outcome and shows the customer a result or a report.

Behind those steps sit practical concerns that product people have to care about: how a transaction reference is managed, when a balance is deducted, how callbacks and status updates are handled, and how the whole thing is reconciled afterwards. When a platform is connected to more than one supplier, there is also provider routing, which is the mechanism for directing a transaction to a suitable supplier. The choice can reflect price, reliability, availability and the commercial relationship, and the goal is to balance reliability, availability and commercial performance. The specific rules behind those decisions are internal, and I will not describe them here.

If I could change one thing about how outsiders see this industry, it would be to make "pending" less mysterious. A pending transaction is one that has been submitted, where the balance has been deducted or reserved, but where final delivery to the customer has not been confirmed. The supplier may not have returned a definitive status, and the reseller downstream may still be waiting.

Pending does not mean failed. A pending transaction can still succeed, or it can fail, and the answer comes from the supplier's final status and from reconciliation between the parties. In my experience this is typically resolved within a day, often on an H+1 basis, but that is a common practice rather than a universal rule or a guaranteed service level for every provider.

Most of the difficulty comes from not knowing. One of the most frustrating situations I know is a transaction that fails with a generic error message and nothing else. A general error does not tell the operator whether the cause was in the application, in network communication, in the integration layer or at the supplier. The team has to investigate before it can decide what to do, and meanwhile a customer is waiting. I think this is why transaction status visibility and clear error handling are product responsibilities, not just engineering details.

Who ends up bearing the cost of a failed or unresolved transaction is also less simple than it sounds. A reseller, an aggregator, a supplier or a platform can each feel an operational or financial impact. Final responsibility is settled through investigation, reconciliation and the contractual terms between the parties. The party that feels the impact and the party that is finally liable are often not the same.

A reliable transaction is usually the result of many small improvements rather than one clever fix. Better internal systems, closer coordination with suppliers, and clearer messaging between systems all contribute, and they work only if someone is watching the whole picture continuously and coordinating changes across both the platform and its external partners.

I do not think reliability belongs to engineering alone. Supplier management, product listings, pricing, support procedures and monitoring all shape whether a customer's money arrives as expected. The product leader's job is to see those pieces as one system and to make sure the trade-offs between them are made deliberately.

Moving money creates obligations. Fraud exposure varies by product, so prevention has to be designed with each product in mind. I will not describe detection methods or thresholds, because those are exactly the details that should stay private. Anti-money-laundering responsibilities, taxation rules and the regulations of the relevant authorities and ministries all affect how a platform operates.

Regulation also differs by activity. Services such as domestic and international money transfer fall within Bank Indonesia's payment-system framework, and the permitted scope of any company depends on its own valid authorisation. It would be wrong to assume that every PPOB product needs the same licensing, or that a licence for one activity covers another. Compliance, financial crime prevention, relationships with billers and suppliers, and tax rules are connected, and a platform that treats them separately tends to find out the hard way.

The biggest lesson is that the app is the small part. The real complexity sits behind the interface: high volumes, thin margins, strict service expectations, supplier dependencies, financial exposure and operational risk. A simple purchase experience depends on several systems and several organisations all doing their part.

As a product leader, I find the work is largely about holding competing needs together: competitive pricing against reliable delivery, speed against control, customer experience against compliance. A payment product that works lets people complete a transaction and keeps doing so consistently while the business behind it stays sustainable.