UPI Merchant Onboarding Readiness Checklist for Indian Businesses

UPI integration starts before code. The business needs an eligible merchant relationship, approved bank destination, authorized account owner, support process, and a technical team that can protect credentials and verify payment events.

NPCI states that merchants partner with an acquiring bank for UPI infrastructure. Its onboarding overview includes due diligence, account setup, merchant identifiers, MCC classification, and acquiring-switch configuration. Exact documents and approval decisions belong to the bank or merchant provider, not VyaparGateway. Source: NPCI UPI FAQ.

Business and Provider Readiness

Prepare:

• Legal or proprietor business identity used for the merchant account
• Bank account selected for merchant receipts
• Authorized person who can access the merchant-provider account
• Business category and merchant use case
• Provider-issued merchant identifiers or approved access
• Official support channel for account or transaction issues

VyaparGateway currently presents three merchant-provider connections: BharatPe for Merchants, Paytm for Business, and HDFC SmartHub Vyapar. A customer paying with PhonePe or Google Pay does not mean those payer apps are merchant connections inside VyaparGateway.

Do not copy provider credentials into email, shared documents, ticket comments, or browser analytics. Complete authorization only in the intended product flow.

Technical Readiness

Assign owners for:

Area	Owner question
Checkout backend	Who calculates price and creates the payment order?
Secret storage	Where are API and webhook secrets protected?
Public endpoint	Who deploys and monitors the HTTPS webhook route?
Database state	Where are order reference, amount, event ID, and status stored?
Reconciliation	Who resolves uncertain and late payments?
Release	Who can disable checkout if verification is unhealthy?

Use one stable client_txn_id per order attempt, store money in integer minor units, and keep all gateway credentials on the server. Start with the Dynamic UPI QR API guide and select the framework-specific guide from the integration library.

Operations Readiness

Define answers before launch:

• What does support ask when a customer says money was deducted?
• Who can view full payment references?
• What happens when payment arrives after order expiry?
• How is an amount mismatch handled?
• What is the provider-specific refund or grievance path?
• Who reviews unresolved orders each day?
• What support reference can the customer safely share?

Use the UPI payment operations runbook as a starting point. Adapt it to your products, fulfilment risk, refund policy, and provider agreement.

Security Readiness

Confirm:

• API keys and webhook secrets are separate and server-only.
• Production credentials are not used in local screenshots or demos.
• Merchant-provider access is limited to authorized staff.
• Webhook signatures use raw body and timestamp replay checks.
• Event IDs are unique in the database.
• Analytics excludes secrets and customer payment identifiers.
• Logs use request and order references with restricted access.
• Credential rotation has an owner and recovery process.

The payment webhook go-live checklist covers valid, invalid, duplicate, and recovery tests.

Go-Live Evidence

Do not use “account connected” as the final readiness signal. Record:

1. Merchant connection completed by an authorized user.
2. Low-value payment order created where provider policy permits.
3. Payment verified against the expected order and amount.
4. HTTPS webhook saved.
5. Real test event returned 2xx.
6. Invalid signature was rejected.
7. Duplicate event produced one business effect.
8. Delayed-event recovery was demonstrated.
9. Support and reconciliation owners accepted the runbook.
10. Plan and volume limits match the intended launch.

This checklist cannot guarantee provider approval or replace legal, tax, bank, or compliance advice. It gives the business and engineering team a shared definition of readiness so the first customer payment is not the first time the complete system is tested.

Keep test and live readiness separate. A test endpoint, secret, merchant identifier, or sample payment must never be silently reused as production configuration. Record the environment beside every credential and webhook URL, restrict who can promote configuration, and run a fresh end-to-end verification after promotion.

A practical ownership review can be completed in one meeting:

Decision	Named owner required
Merchant-provider account access	Business administrator
Checkout and order-state release	Engineering owner
Webhook secret rotation	Security or platform owner
Paid-but-pending investigation	Payment operations
Refund or grievance escalation	Finance or provider-account owner
Customer status communication	Support owner

If any row has no owner, onboarding is incomplete even when the connection screen says success. Clear ownership reduces activation drop-off because each failure has a known next action instead of an open-ended support request.