"White label", "custom software" and "API access" get used interchangeably in sales calls, but they are different products with different risk profiles. Before you evaluate any vendor, work out which of the four you are actually being sold, then use the checklist below to find out who really holds the licence, where your money sits, and what happens on the day something goes wrong.
Four ways to buy fintech capability
| Model | What you get | Who runs it | Typical fit |
|---|---|---|---|
| Managed portal / distributor account | An account on someone else's platform, under their brand | The vendor, end to end | You want to resell services quickly with no engineering |
| API integration | Endpoints you call from your own app or backend | You, for your own product | You have engineering capacity and want the service inside your own experience |
| White-label platform | A rebranded, per-client build of an existing platform: admin panel, portal, app | You operate day to day; the vendor built it | You want your own brand and app quickly, without building from scratch |
| Custom software development | Software built to your specification, potentially from a blank page | You, fully, once delivered | You have specific requirements no off-the-shelf platform meets |
Who holds the licence: a map
| Service | Regulated party | The white-label owner is... |
|---|---|---|
| AePS, Micro ATM, UPI cash withdrawal, DMT | The sponsor or acquiring bank; the BC acts for it | A BC sub-agent or distributor under a BC or aggregator contract |
| Bharat Connect bills, including recharge done through BBPS | An operating unit (COU), or an agent institution certified by NBBL | An agent under that COU or agent institution; check sub-agent rights |
| Dynamic QR collection, pooled payouts | A bank, or a payment aggregator authorised by RBI | The merchant, or the PA's technology partner |
| Operator recharge outside BBPS | The operator's distribution contract | A distributor or reseller |
| CMS / EMI collection | The lender (bank or NBFC) | The lender's collection agent or BC |
| A wallet usable beyond your own services | A PPI issuer authorised by RBI | Needs authorisation, or a redesign as a closed-system wallet |
The 12 questions to ask before you sign
- Who is the regulated partner, and is the contract with you or with them? Every regulated service, AePS, DMT, Bharat Connect billing, pooled payouts, sits under a bank, an operating unit, or a payment aggregator authorised by RBI. Ask the vendor to show you the shape of that relationship, and get clear on whether your commercial contract sits with the vendor, the regulated entity, or both.
- Do you get sub-agent rights? Some upstream contracts explicitly forbid onboarding further sub-agents. If your model depends on running a downline of retailers or distributors, confirm in writing that the upstream agreement the vendor operates under actually permits it.
- Where does the money sit at each step? Ask for a step-by-step account of one transaction: whose bank account, wallet or escrow holds the money between the customer's payment and final settlement. A vendor who cannot answer this in one sitting probably has not mapped it either.
- Who owns the source code, the data and the Play Store listing after go-live? Confirm in writing when source code transfers, on signing, on final payment, or never, who owns transaction data and user records, and whose developer account the Android app publishes under.
- How are pending transactions resolved, and how fast are refunds? Ask for the actual mechanism, automatic status polling, manual review, a fixed refund window, not just a promise that it is handled.
- What happens if an upstream provider shuts down? Every rail depends on a bank or aggregator partner behind the scenes. Ask what the vendor's replacement plan is, and how much of that risk transfers to you once you take over operations.
- What exactly does the price include? Get a line-item breakdown of what the headline number covers versus what is billed separately: setup, source handover, hosting, SMS, one-time Play Store publishing, and ongoing maintenance. Never accept a vague "all-inclusive" claim.
- Which audits apply, and where is data stored? Ask what security review the platform has had, whether data sits on servers in India, and who is responsible for a breach after you take over operations.
- Has the source been reviewed before handover, debug routes removed, secrets rotated? A platform built for one client can carry test logins, debug endpoints or default credentials left over from development. Ask specifically whether these are removed and whether every key and credential is rotated to values only you control before go-live.
- What support hours apply, and for how long? Get support hours and duration in writing, and understand what counts as support versus a paid change request once the free period ends.
- Whose Play Developer account publishes the app? If the vendor publishes under its own account, you do not control your own app's listing or removal risk. Confirm whether the app goes under your own Play Developer account, even if the vendor assists with the upload.
- What is explicitly excluded? iOS, multi-tenant support, specific payment rails, and email or WhatsApp notifications are common gaps. Get the exclusion list in writing before you sign, not after you notice something missing.
What a credible platform includes
A real hierarchy
Retailer, distributor and master-distributor roles with server-enforced rules on who can create whom below them, not just a UI toggle.
A ledger, not a number
Wallet balances backed by a transaction ledger with unique references and row-level locking, so two simultaneous actions cannot double-spend the same balance.
KYC that is actually checked
Document capture plus a verification step, not just a form that accepts any upload.
A dispute desk
An admin console that can see a disputed transaction's full history and reverse commission or refund the wallet without a raw database edit.
An honest exclusion list
A vendor who tells you plainly what the platform does not do, in writing, before you sign.
Red flags
- Claims that the platform itself is approved by RBI or certified by NPCI. Software isn't licensed that way; the regulated roles sit with banks, operating units and authorised payment aggregators.
- Invented transaction, partner or user-count figures used as proof of scale, with no way to verify them.
- "No licence needed for anything you do on this platform." Some things genuinely need no separate licence, such as software running on your own bank account; others need a licensed partner behind them. A vendor who says neither ever applies is not being straight with you.
- Pricing with no breakdown, or a demo that skips straight past who holds the licence.
Payonclick's model, stated honestly
Payonclick's white-label offer is a per-client build: your own admin panel, your own retailer and distributor web portal plus PWA, and a native Android app under your own app ID and keystore, not a shared, multi-tenant platform with your logo painted on top. Source code is handed over on final payment. You sign your own provider contracts for the regulated services you choose to offer, and you carry the regulatory responsibilities that come with operating them once the platform is live.
Practically, that means one assisted Play Store upload, one round of admin training, post-go-live support for a defined window, and a maintenance plan after that for ongoing changes. There is no iOS app, Android only, and no email or WhatsApp notifications; the platform uses SMS OTP and push notifications instead. See our white-label fintech software page for the full module list, or custom fintech software development if your requirements go beyond what a rebrand can cover. If any of the exclusions above matter to your plan, raise them before you sign, using the questions above.