Digital goods for a superapp means four product lines through one catalogue integration: gift cards, game top-ups, airtime and data, and eSIM. They monetise traffic the app already has, with no logistics, because everything ships as a code or a direct account credit.
The four lines look alike from the outside and behave differently in operation. Here is what each brings, what they share, and a sensible order to launch them in.
The four product lines
Gift cards have the broadest appeal: gaming, streaming, shopping and app-store credit cover most of an audience, and cards double as gifts, which adds seasonal volume. Catalogues are regional, so the brand list must match each user’s country.
Game top-ups are the frequency play. A player tops up the same game every month, sometimes every week, and the audience skews young. Fulfilment goes straight to the player’s game account rather than through a code; the mechanics are covered in what direct top-up is.
Airtime and data are pure utility, and they carry a use case the other lines do not: people topping up phones for family in another country. Where a superapp has a diaspora audience, this line often outsells the glamorous ones.
eSIM is the travel product. Volume is spikier and support is heavier (device compatibility questions dominate), but the buyer is high-intent and the product has no local competition at the moment of need.
One set of plumbing underneath
The reason superapps bundle these lines is that they share an integration. One contract with a distributor or aggregator covers all four; one catalogue API handles products, prices and ordering; one settlement and one reconciliation process covers everything sold. Adding a second or third line to a live integration is a catalogue-mapping exercise, not a new project.
That shared plumbing is also the commercial argument: the work of onboarding a supplier amortises across every line you launch afterwards.
Where the lines differ in practice
| Product line | Typical buyer | Delivery mechanism | Operational note |
|---|---|---|---|
| Gift cards | Gifting plus monthly self-use | Code shown in app | Regional catalogues; match brands to the user’s country |
| Game top-ups | Young, high-frequency players | Direct credit to game account | Wrong account IDs are the main support load; validate before payment |
| Airtime and data | Utility buyers, remittance senders | Direct credit to phone number | Operator coverage varies by country; test the long tail |
| eSIM | Travellers | Activation code or QR | Device compatibility drives support; publish a checker upfront |
The differences that bite are in delivery. Codes are reversible up to the moment of display and radioactive afterwards; direct fulfilment has no code to leak but fails loudly when the user mistypes an account ID or phone number. Build the confirmation step for direct lines with more care than feels necessary.
Which line to launch first
Start with the line your audience already asks for, because the first launch carries all the fixed work and needs demand behind it. A payments-centred app usually starts with gift cards, the same logic as gift cards in banking apps. An app with a young or gaming-heavy audience starts with top-ups and adds gift cards second. Airtime leads wherever remittance behaviour is visible in the user base.
Then expand from the same integration, one line per quarter, letting support and reconciliation settle between launches.
Frequently asked questions
What digital goods do superapps sell?
The standard set is four lines: gift cards (gaming, streaming, retail, app-store credit), game top-ups delivered straight to player accounts, mobile airtime and data top-ups, and travel eSIMs. All four ship as a code or a direct account credit, so there is no warehousing or shipping, and all four can come from a single catalogue integration with one distributor.
Do I need separate suppliers for gift cards and top-ups?
Usually not. Distributors and catalogue aggregators carry gift cards, game top-ups, airtime and eSIM in one catalogue behind one API, one contract and one settlement process. Splitting suppliers only makes sense when one provider is markedly stronger in a region or category you depend on, and even then most apps run a primary catalogue with a narrow secondary source rather than parallel full integrations.
Which digital goods category should an app launch first?
The one your audience already buys elsewhere. Payments-centred apps tend to start with gift cards, gaming-heavy audiences with game top-ups, and apps with remittance behaviour with airtime and data. The first line carries the supplier onboarding and integration work, so it needs real demand behind it; each later line reuses the same plumbing and launches faster.
How do superapps deliver airtime and eSIM products?
Airtime and data go as a direct credit to the phone number the user enters, with no code involved, while an eSIM arrives as an activation code or QR to scan into the device. Both need a careful confirmation step: a mistyped number sends airtime to a stranger, and an incompatible handset makes an eSIM useless. Publishing a device compatibility checker before checkout cuts most eSIM support tickets.
Why do direct top-up orders fail in superapps?
Almost always because the user mistyped the account ID or phone number. Direct fulfilment has no code to re-deliver: the credit lands on whatever account was entered, and a wrong entry is a loss, not a retry. The fix is validation before payment, showing the resolved account name where the game or operator supports a lookup, and a confirmation screen the user must actively approve.