How to Verify UPI Payments for a WhatsApp Group

If you run a paid WhatsApp group, a member may send a screenshot that says “payment successful.” The image can look convincing, include the right amount, and show a transaction ID. It still should not unlock your group. Screenshots can be edited, reused, or generated by fake payment applications. Your own payment provider record is the source that matters.

The safest policy is simple: no verified payment, no paid access. The member should not have to argue, and the group administrator should not have to inspect fonts or logos. Use a gateway order, verify the provider response on your server, and issue the next access step only after the payment is captured.

Why UPI screenshots are not proof of payment

A screenshot is static. It does not prove that funds moved, that the recipient was your business, that the transaction was completed, or that the reference was not copied from an older payment. A fake application can reproduce a familiar interface and play a success sound without connecting to the UPI network.

Cashfree's guide on fake payment screenshot scams advises merchants to verify payment in their own system and states that screenshots should not be treated as payment proof. That principle applies directly to WhatsApp memberships. Your digital service is the group access. Do not release it until your merchant side record confirms the transaction.

Common warning signs

• The member creates urgency and asks for access before your dashboard updates.
• The screenshot has the right amount but the payee identity is unclear.
• The transaction ID cannot be found in your own records.
• The image is cropped around the status and hides other transaction details.
• The same image or reference is used for multiple people.

These signs may help, but visual inspection is not a verification system. A perfect looking image can still be false. A genuine looking transaction can also remain authorised rather than captured. Check the payment provider.

The correct verification workflow

1. Create a unique Razorpay order for the membership amount.
2. Let the member complete Razorpay Checkout using an enabled payment method.
3. Receive the payment ID, order ID, and signature from the checkout result.
4. Verify the signature on your server using the correct secret.
5. Fetch the payment from Razorpay and confirm that it belongs to the same order.
6. Match the amount, currency, group, and membership plan.
7. Confirm that the provider payment status is captured.
8. Record the payment and membership in one database transaction.
9. Create a unique access reference or join code.
10. Show the member the access instructions.

Every check closes a different gap. Signature verification confirms the response was not invented. Fetching the payment confirms the current provider state. Matching the order, amount, and group prevents a valid payment for one item from unlocking another. A database transaction prevents a partial record where the payment exists but the membership does not.

Use Razorpay webhooks for asynchronous confirmation

The browser is not a reliable place to finish important payment work. A customer can close the tab, lose connectivity, or return late from the bank application. Razorpay describes webhooks as asynchronous server to server notifications for events such as order paid and payment captured.

Razorpay's current guidance says to rely on webhooks for automation and supplement them with an API fetch when a critical user facing flow needs immediate confirmation. Read the official Razorpay webhook overview and payment webhook events.

Webhook controls that matter

• Use a strong webhook secret and verify the Razorpay signature against the raw request body.
• Keep test and live mode endpoints and secrets correctly configured.
• Store the event ID and reject duplicate processing.
• Make handlers idempotent so a retry cannot create a second membership.
• Log success and failure without logging secrets or full sensitive payloads.
• Reconcile provider payments if a webhook is delayed or missed.

A webhook should not trust notes without checking the related merchant, order, and stored data. It should also fail closed when its signing secret is missing. An error must not become access.

Issue a join code after payment is captured

A join code creates a useful boundary between payment and WhatsApp. After MintLoop verifies a captured payment, it records a unique reference code for that successful transaction. The member can use the access page and send the code to the connected WhatsApp number. The server checks whether that code belongs to an active membership before returning the correct invite instructions.

This is safer than publishing the raw invite link on a generic success page. It also gives support a reference that can be checked without asking the member to send card details, a UPI PIN, or a private bank statement.

The invite link can still be forwarded after delivery. Use WhatsApp approval settings where available and review access requests against your active membership list. MintLoop currently uses a linked device through Baileys for WhatsApp operations. It is independent from WhatsApp and Meta, and linked device restrictions can affect automation. Keep a manual approval fallback.

What the creator dashboard should record

For each payment, keep the provider payment ID, order ID, amount, currency, verification status, membership, access period, and processing timestamps. For each membership, keep the group, member identity, current period end, status, and access state. This lets you answer operational questions without searching chat history:

• Did this exact payment reach the correct merchant order?
• Which group and plan did the member purchase?
• When should access expire?
• Was the payment refunded or disputed?
• Did the access handoff complete?

Do not store UPI PINs, card numbers, CVVs, or passwords. Payment gateways handle payment instrument data. Your membership system should store the minimum records needed for verification, support, accounting, and access.

Two minute payment verification checklist

• Open your own Razorpay or membership dashboard.
• Search the payment or order ID from your system, not only the screenshot.
• Check the captured status.
• Match the amount and currency.
• Match the order to the correct group and member.
• Confirm the payment has not already been used for access.
• Only then issue a join code or approve the request.

If the payment is authorised but not captured, tell the member that it is still processing. Do not create a second payment or grant access based on pressure. If a payment later changes state, your webhook or reconciliation process should update the record.

How MintLoop applies this process

MintLoop creates a Razorpay order for the creator's group or membership plan. On return, it verifies the signature, fetches the provider order and payment, matches the group, order, amount, and currency, and requires a captured payment before recording the membership. The payment receives a unique reference code. Checkout visits and orders can also be recorded so creators can understand the path from shared link to paid member.

The product reduces manual reconciliation, but creators still need clear terms, correct pricing, secure account access, and a fallback process for WhatsApp. Start with the complete paid WhatsApp group guide, see the manual payment comparison, or explore the coaching community workflow.

Frequently asked questions

Can I verify a UPI screenshot using its transaction ID?

Do not verify the image itself. Search the transaction in your own merchant or bank record and confirm the correct amount, recipient, status, and order association.

Is a bank SMS enough?

Your own bank or provider notification is more useful than a customer screenshot, but a structured online workflow should still use the payment gateway status and order verification before automatically granting access.

Which webhook event should I use?

Choose events based on your Razorpay integration and current provider documentation. Captured payment and paid order events indicate captured funds, but handlers must still verify signatures and process events idempotently.

What should a member see while payment is processing?

Show a clear processing state, the payment reference, and a retry verification option. Do not ask the member to pay again until you confirm the first attempt failed.