This practical guide explains UPI payment verification for WhatsApp group for Indian creators who want a clearer payment, access, and member management process.
Why screenshots are weak evidence
A UPI screenshot is created and controlled by the buyer. It may show a pending transaction, a payment to another account, an edited amount, or an old successful transfer. Even a genuine image may not tell the creator which group plan the buyer intended to purchase. Access should follow the merchant-side transaction record, not the image sent in chat.
The practical goal is not to accuse members. It is to use a process that treats everyone consistently. Ask the buyer to complete a checkout tied to a specific order. If support is needed, search the provider dashboard using the payment or order reference and compare it with the membership record.
Checks before the buyer pays
Use a checkout page that identifies the creator, group, plan, amount, access period, and refund contact. Do not send a generic QR image without context. The member should know what they are buying and which business will receive the money before opening a payment application.
Create the Razorpay order on the server. Do not accept the price from a browser field as final. Read the selected plan from your own database, calculate the amount on the server, and attach a group or plan reference to the order notes where appropriate. This prevents a changed browser request from selecting a lower amount.
- The public page uses HTTPS and the expected MintLoop domain.
- The group and plan exist and are available for purchase.
- The amount is calculated server-side in the smallest currency unit.
- The order has a traceable internal group or plan reference.
Checks after Razorpay returns payment details
Verify the checkout signature using the order ID, payment ID, and the correct secret on the server. Then retrieve or validate the provider record. Confirm that the payment belongs to the expected order, uses INR, matches the plan amount, and is captured before activating the membership.
Use a database transaction or another atomic operation when recording the payment and membership. Add a uniqueness rule for the provider payment ID. If the same callback or webhook arrives twice, the second attempt should return the existing result rather than creating a second member period or join code.
Use webhooks for late and asynchronous changes
Payment windows can close, networks can fail, and authorisation can finish after the member leaves the page. Webhooks help the system receive provider updates without relying on the member to keep a tab open. Validate the webhook signature against the raw request body and return a successful response only after the event is accepted safely.
Track event identifiers and processing outcomes. Razorpay may retry a webhook when the endpoint does not respond correctly. A webhook endpoint should be idempotent, fast, and observable. It should record why an event was ignored, matched, failed, or completed so support can investigate without guessing.
Handle payment disputes without exposing secrets
Give support a short checklist: confirm the member contact, request the payment ID or internal reference, search Razorpay, compare the group and amount, and check whether a membership already exists. Ask for a screenshot only as supporting context, never as final proof.
Do not request OTPs, UPI PINs, API keys, webhook secrets, complete card details, or WhatsApp session files. If a payment appears successful in Razorpay but the membership is missing, correct the record through an auditable admin process and document the reason.
Implementation checklist
- Price is calculated from a server-side plan record.
- Razorpay signature validation happens on the server.
- Order, amount, currency, and captured status match.
- Provider payment IDs are unique in the database.
- Webhook signatures use the raw request body.
- Support uses payment references, not private credentials.
Frequently asked questions
Is a UPI transaction ID enough?
It is useful for tracing, but access should follow the successful merchant-side payment record connected to the correct order and amount.
What if the member closes the payment page?
Use webhook events and provider status verification to detect late success or failure. Do not depend only on the open browser tab.
Can one payment be reused?
A unique database constraint on the provider payment ID helps prevent one payment from creating multiple memberships.
Should support ask for a UPI PIN?
Never. A legitimate creator or software provider does not need a member's UPI PIN, OTP, or banking password.