Why the Merchant Account Comes Before the Technology
A white-label gateway does not replace a merchant account. In the Centabal Pay model you bring the merchant accounts and we set up and run the technology: the UPI pay-in API, the IMPS and NEFT payout API, the branded payment page on your domain and the reseller panel. The accounts themselves are opened with banks or regulated payment aggregators, and they decide whether to onboard you.
In India, banks and payment aggregators carry out KYC and due diligence on the merchants they serve, following Reserve Bank of India rules. That means the exact list of requirements depends on the provider you approach, your legal entity type and your business category. Licensing, regulatory approvals and compliance with the terms of each account stay with you as the account holder. Our role is to integrate and operate the channel on top of what you have arranged.
Documents for a Merchant Account in India
Most providers ask for a similar core pack, although the format and the extra items vary. Preparing these in clean, current, consistently named scans before you apply usually shortens the back-and-forth. Make sure the legal name, registered address and authorised signatory match across every document, because mismatches are one of the most common reasons an application is sent back.
For partnerships, LLPs and sole proprietorships the list changes: expect partnership deeds, LLP agreements or proprietor KYC instead of company incorporation documents. Foreign entities expanding into India should ask early whether the provider onboards non-Indian companies at all, or whether a local entity is needed.
- Certificate of incorporation or registration of the business entity
- PAN of the entity
- GST registration certificate, where the business is registered for GST
- Memorandum and articles of association, partnership deed or LLP agreement, as applicable
- Board resolution or authorisation letter naming the signatory for the account
- KYC of directors, partners or authorised signatories, such as PAN and an officially valid address proof
- Proof of the business bank account for settlement, such as a cancelled cheque or recent bank statement
- Proof of registered and operating business address
- A clear written description of the business model, products and customer base
Website, Policies and Business Model Review
Providers review the platform where payments will be taken, not only the paperwork. Expect them to visit your website or app and check that it describes what you sell, shows prices or fee structures, and publishes the policies a customer would need. A site still under construction, or one that differs from the business description in the application, often delays approval.
They will also ask about the flow of funds: who pays you, for what, how and when money goes back to users, and what your expected monthly volume and average transaction size look like. Platforms that both collect from and pay out to the same users should explain that cycle plainly, since it affects which account types and limits the provider offers.
- Terms of use and privacy policy published on your domain
- Refund and cancellation policy, with timelines
- Visible customer support contact details and business address
- Product or service descriptions that match the application
- Estimated monthly volume, average ticket size and peak periods
- A short explanation of how funds move between users, your platform and payouts
UPI Merchant Account Requirements
To collect through UPI you need a merchant set up for UPI with a bank or a payment aggregator, usually with its own virtual payment address and a merchant category assigned by the provider. The category must match what you actually sell, because it determines how transactions are classified and which limits apply.
Before integration, confirm with your provider which UPI flows are enabled for your account, such as intent links, dynamic QR codes or collect requests, and how settlement works. Those answers shape the payment page we build on your domain and the callbacks your backend must handle. Ask too how refunds and failed or pending transactions are reported, since reconciliation depends on it.
- Merchant VPA or equivalent UPI merchant identifier
- API credentials and test environment access from the provider
- Confirmed UPI flows: intent, QR, collect or a combination
- Settlement account details and settlement cycle
- Callback or webhook specification and status-check endpoint
- Refund process and reporting format
Payout Prerequisites for IMPS and NEFT
Paying users back requires a separate capability from collecting. Payouts typically run from a funded account with a bank or payout provider that exposes an API for IMPS and NEFT transfers. IMPS transfers settle in real time, while NEFT settles in half-hourly batches, so your users' experience depends on which rail is used and when.
Payout providers usually ask how you will fund the account, what your expected payout volume is, and how you validate beneficiary details before sending money. Many also require that API calls come only from whitelisted server IP addresses. Agree on per-transaction and daily limits up front, and on how reversals and failed transfers are returned, so that the operations team can reconcile balances every day.
- Payout account and funding method agreed with the provider
- Payout API credentials and sandbox access
- Whitelisted server IP addresses for API calls
- Per-transaction and daily limits for IMPS and NEFT
- Beneficiary validation approach for account number and IFSC
- Process for reversals, failures and balance reports
What You Need for a White-Label Gateway: Step-by-Step Checklist
Once the merchant accounts are approved, or at least in final review, the white-label setup can move in parallel. The list below is what we typically ask for to set up a channel that carries your brand from the first click to the payout confirmation. Timing depends mostly on how quickly provider credentials, DNS changes and test transactions are completed on your side.
For payment resellers, the multi-tenant panel lets each merchant sit in its own space with separate credentials, transactions and reports. In most setups each underlying merchant still has to be onboarded and checked by the bank or aggregator individually, so confirm with your provider how sub-merchants are approved before you promise go-live dates to your own clients.
- Step 1: Share the approved merchant account details and provider API documentation for pay-in and payout
- Step 2: Choose the domain or subdomain for the branded payment page and prepare DNS access
- Step 3: Send brand assets: logo, colours, company name and support contact shown to users
- Step 4: Define callback URLs and the transaction statuses your backend needs
- Step 5: For resellers, list the merchants or tenants and the access each one should have
- Step 6: Run test collections and test payouts end to end, including failures and refunds
- Step 7: Agree on operations contacts and escalation on Telegram before going live
Requirements in Pakistan, Bangladesh, Vietnam, the Philippines and Myanmar
The same principle applies outside India: local banks, payment institutions or wallet providers onboard merchants under their own national rules, and they will ask for entity documents, signatory KYC, a business description and a settlement account. What differs is which entity types they accept, whether a local company or local bank account is required, and which collection and payout methods are available.
If you are a regional expansion lead, start conversations with local account providers early and ask the same questions about flows, limits, settlement and APIs listed above. We can run the technical channel while you arrange local accounts and approvals, but obtaining those accounts and any required licences remains your responsibility in each country.
Mistakes to Avoid During Merchant Onboarding
Most delays come from preventable gaps rather than from the technology. The points below are worth checking before you submit an application or ask a gateway team to start building.
- Names, addresses or signatories that differ between documents
- Applying with a website that lacks published policies or contact details
- Describing the business vaguely or choosing a category that does not match the product
- Arranging collections but leaving payout accounts until after launch
- Underestimating volumes, which can lead to limits that block growth later
- Skipping failure and refund scenarios during testing
- Assuming a reseller's own approval covers every merchant it serves
- Treating the technology provider as responsible for licences or account compliance