Biller Aggregation & Value Added Services

Sanitised and conceptual. This describes the shape of the problem and the engineering approach in generalised terms. It is not a representation of any employer’s proprietary architecture, source code, data or internal metrics.

Context#

A value-added-services platform lets a customer pay for the things that keep ordinary life running (phone credit, electricity, a betting wallet) through one agent, one app, one interface. Behind that single interface sits a scatter of unrelated provider APIs, each built by a different company with different assumptions.

At Baxi by Onafriq I integrated 14+ VAS billers into the B2B middleware using Laravel and Node.js, and built and maintained the Biller Aggregation Platform (BAP) and its companion BAP Reporting Service (BRS) in Node.js and Java/Spring Boot.

The engineering problem#

Aggregation looks like plumbing until you look at the categories.

Airtime settles more or less instantly; the interesting failure is a partial success. Electricity returns a token that the customer physically needs, if the delivery path drops it, the money is gone and the value never arrived. Betting wallets are third-party balances with their own crediting rules and their own idea of when a top-up is final.

Three categories, three different definitions of "done". The aggregation layer's job is to give callers one contract across all of them without flattening away the differences that actually matter.

What I owned#

• Integrated 14+ VAS billers, airtime, electricity and betting among them, into the B2B middleware, using Laravel and Node.js.
• Built and maintained the Biller Aggregation Platform (BAP), the layer that turns many provider APIs into one interface the rest of the business builds on.
• Built and maintained the BAP Reporting Service (BRS) alongside it, in Node.js and Java/Spring Boot.
• Designed and implemented the Baxi Card Support Portal in Laravel, to improve agent issue-resolution workflows.

Conceptual architecture#

Biller aggregation, conceptual fan-out

Consumers

• Agent applicationsRetail channel
• B2B middlewarePartner callers
• Support portalLaravel

Biller Aggregation PlatformNode.js · Java

External providers

• Airtime & dataInstant settlement
• ElectricityToken delivery
• Betting walletsWallet top-up
• Reporting serviceBRS · audit trail

Engineering considerations in an aggregation layer#

One contract, honest about variance. The aggregation interface should be uniform in shape, same request envelope, same error taxonomy, while still carrying category-specific detail where it matters. Pretending a token delivery and an airtime top-up are the same event makes the reporting layer lie later.

Retries need to know what they are retrying. A retry against a provider that already accepted the request is a duplicate purchase. The aggregation layer is where request identity has to be established, because the individual providers will not do it for you.

The reporting service is not an afterthought. A separate reporting path exists for a reason: the operational question ("did this customer's payment arrive?") and the analytical question ("how did this biller behave last week?") have different access patterns and different latency tolerances. Putting them in the same query path means one of them degrades the other.

Support tooling is production tooling. The Card Support Portal existed because agents resolving customer issues are part of the system. If the only way to answer a customer question is for an engineer to run a query, the platform has an unowned failure mode.

Related#

The funds-transfer side of the same platform, 8+ partner banks and the MTN Mobile Money integration, is written up in Multi-Bank Funds Transfer Service.