A founder who says “we are building a wallet” may mean stored customer value, a checkout screen, a merchant settlement product or a technology interface. Those are not the same RBI category, even if they appear together in one app.
Before choosing the entity or seeking investors, trace where customer money sits and who owes the customer or merchant. That single exercise usually exposes which product is actually being sold.
Quick Answer
A prepaid wallet or other PPI stores value under RBI’s PPI framework. A payment aggregator collects and settles merchant payments under the PA framework. A gateway may only process transactions as technology. One app can combine these functions, but one label or partner contract does not cover every activity. Classify each flow and legal entity separately.
1. Wallet and PPI: value held for later use
A PPI is not simply an account screen. The issuer receives value that can be used later according to the instrument’s permitted features. RBI’s PPI directions distinguish types, usage limits, customer checks, escrow and other duties. A startup should decide whether it will issue the instrument or serve an authorised issuer.
Closed-loop credits usable only with the issuer can present a different question from broadly accepted prepaid value. Product teams should not assume that reward points, gift value and transferable balances all receive identical treatment. Test the exact redemption network and cash movement.
- Define who owes the stored balance.
- Map loading, redemption and refund.
- Check issuer and customer KYC rules.
2. Aggregator: collecting for merchants
A PA enables merchants to accept payments and handles collection and settlement. A non-bank PA has an RBI authorisation framework, including escrow, merchant onboarding and security obligations. If a wallet product also settles third-party merchants, assess the PA function separately.
A PA does not become a PPI issuer because it shows a balance; equally, PPI authorisation does not automatically cover merchant aggregation. Contractual terms should make clear who holds the money, when the merchant is paid and who handles chargebacks.
- Identify the merchant contracting party.
- Use prescribed escrow rather than company cash.
- Test disputes, refunds and reserves.
3. Gateway: technology can still matter
A gateway may route transaction messages and provide checkout technology without holding the merchant settlement role. Its status depends on the real operating arrangement. Marketing a collection business as “gateway only” does not make the fund flow disappear.
A technology provider can still face demanding security, outsourcing and data responsibilities from regulated customers. The technical architecture and bank integration should match the legal contracts, including what happens if a transaction fails midway.
- Record whether the gateway controls funds.
- Check security and partner obligations.
- Reconcile the UI with legal roles.
4. Select a model before adding features
Start with one customer use case and draw the legal obligations created by loading, paying, settling and refunding. Then repeat for every proposed feature. The answer may be a licensed entity, a vendor-to-licensee structure or several regulated relationships.
Foreign investment and cross-border transactions deserve separate review. A domestic product classification should not be stretched to cover overseas merchant collections or remittances. Revisit the classification when a new balance, payout or acceptance feature is introduced.
- Map every money flow and legal counterparty.
- Check RBI direction and any FDI/FEMA condition.
- Make approval milestones part of the product roadmap.
How to record the decision
A short decision note should explain why the chosen route fits the facts, which authority controls the point, what was checked and which assumptions remain open. For Wallet, PPI, the note should also identify the responsible person, the next filing or approval event and the evidence that supports each conclusion.
Keep the note with board materials, agreements, portal acknowledgements and professional advice. This simple record helps founders answer investor, lender and regulator questions without reconstructing the reasoning months later. Update it whenever the business model, ownership, money flow, instrument terms or scheme status changes.
Documents to keep in one working file
The exact set depends on the transaction, but the working file should make the facts easy to test. Start with these records and add authority-specific forms or declarations where required:
- Define the exact product promise.
- Draw loading, payment, refund and settlement flows.
- Identify every account and legal counterparty.
- Classify PPI, PA and gateway functions.
- Review ownership and cross-border features.
Use dated versions and keep a clear approval trail. A missing email, valuation input or portal receipt can become a material due-diligence issue even when the commercial decision itself was sound.
Decision table
Use the facts of the proposed transaction to test each row before choosing a route.
| Model | Handles value or settlement? | Main RBI question |
|---|---|---|
| PPI or wallet | Holds prepaid value | Is issuer authorisation required? |
| Payment aggregator | Collects and settles for merchants | Is PA authorisation required? |
| Payment gateway | May be processing technology only | Is it actually handling merchant funds? |
| Software vendor | May never hold customer money | Who is the authorised operator? |
Practical checklist
Work through these steps using dated documents, not assumptions made in a pitch deck.
- Define the exact product promise.
- Draw loading, payment, refund and settlement flows.
- Identify every account and legal counterparty.
- Classify PPI, PA and gateway functions.
- Review ownership and cross-border features.
- Align contracts and app screens with the chosen model.
Mistakes that create avoidable delay
The following shortcuts frequently create avoidable legal or filing work later.
- Treating a wallet balance as a harmless UI feature.
- Assuming one partner’s approval covers all product functions.
- Adding merchant settlement to a gateway without reassessment.
When professional review is useful
A fact-specific review should test the chosen route, evidence and filing sequence before money or customer commitments make a correction expensive.
For a fact-specific review, share the proposed activity, ownership, funding instrument and present stage with Sunny G And Co. at contact@cssunnygupta.com. The scope and professional fee should be agreed only after the facts and required filings are clear.
Related service paths
If the issue involves actual filings or structuring, these service pages describe the relevant scope of work. They do not change the eligibility and approval tests explained above; the right route still depends on the company’s documents and intended activity.
Official sources and last review
This article was last reviewed on 15 September 2026. Rules, portal status and filing practices can change, so check the current authority before acting.
