Learn how to use Razorpay get payment details API to fetch transaction data, verify UPI payments, and reconcile gym receipts with real code examples.
GymPilot TeamLooking for the product itself? See gym billing software — built for Indian gyms, with WhatsApp reminders and UPI tracking.
A member says the ₹1,500 membership payment was completed through UPI. The front desk sees a successful screenshot on the member's phone, but the gym's billing screen still shows dues. The bank statement confirms that money moved, yet the staff still need to identify the correct payment, member, status, and gateway record.
Razorpay get payment details becomes a practical operations task, not just an API exercise. A reliable lookup gives the backend a specific payment record to reconcile with the member account. The result can support a receipt, renewal update, and revenue entry without asking staff to trust screenshots or manually search through messages.
Indian gyms usually collect through a mix of UPI, cash, and card. UPI has become the dominant digital payment rail. It handled 185.9 billion transactions in FY25, with transaction value reaching ₹260.6 lakh crore, according to Moneycontrol's report on India's real-time payments and UPI growth. In March 2025, UPI recorded 19.78 billion transactions worth ₹24.77 lakh crore, while QR-code acceptance reached 658 million codes by March 31, 2025, as reported in the same source.
For a small gym, the important point isn't the national scale. It's the frequency of modest collections. A front-desk operator may handle several membership renewals, supplements, personal-training charges, or partial dues payments in a working day. A screenshot can show that a member initiated or completed a payment, but it doesn't automatically prove that the gateway record matches the member, amount, and expected order.
Razorpay's Payments API is designed to retrieve details for a specific payment ID. The response includes the payment state, amount, currency, payment method, and other payment fields, as documented in the Razorpay Payments API reference for India. That makes it more useful than a WhatsApp confirmation when the question is, “Did this payment reach Razorpay, and what does Razorpay say about it?”
A gym system should connect the payment ID to an internal member ID or invoice reference at the time of checkout. If a member later claims to have paid, the staff can search the internal record, retrieve the gateway details, and decide whether to mark the renewal as paid. For teams designing a wider workflow, guidance on tracking payments by source can help frame how gateway records, cash entries, and member accounts should be kept distinct.
The same principle applies to cash. Cash has no Razorpay payment ID, so it must be recorded through a separate cash-entry workflow with staff ownership and an audit trail. A gym management platform should keep cash and gateway payments in the same member payment history while preserving the original payment method. More context on an online gym management system can help owners assess the surrounding operational requirements.
The direct lookup uses a GET request to /v1/payments/:id. The :id value must be replaced with the Razorpay payment ID, such as pay_.... Razorpay documents this endpoint as a retrieval operation. It fetches payment details, but it doesn't collect a new payment.
A basic cURL request looks like this:
curl -u rzp_test_key_id:rzp_test_key_secret \
-X GET
The API uses the API Key ID and API Secret through HTTP Basic Authentication. Production code should read both values from protected server-side configuration. The secret must not be placed in a browser bundle, a WhatsApp link, or a front-desk page.
The most common Indian billing mistake is treating the API amount as rupees. Razorpay represents the amount in the smallest currency unit, so ₹1 appears as 100 paise, as stated in the Razorpay Payments API documentation. A ₹1,500 membership payment therefore appears as 150000 in the response.
A simplified response can be handled like this:
{
"id": "pay_example",
"status": "captured",
"amount": 150000,
"currency": "INR",
"method": "upi"
}
The application should store the gateway value as an integer and convert it only when displaying rupees:
display_rupees = amount_in_paise / 100
That prevents a receipt from showing ₹150,000 for a ₹1,500 payment. It also keeps comparisons reliable when the dashboard total, member ledger, and gateway response use the same base unit.
For a broader view of how systems exchange records across business tools, a practical API integration guide for businesses provides useful background. In a gym implementation, the essential checks remain straightforward:
A single lookup helps resolve a disputed renewal. Monthly reconciliation needs a collection process that can retrieve older records as well. Razorpay's fetch-all-payments endpoint returns created payments, but its default response contains only the last 10 records, according to the Razorpay fetch-all-payments documentation.
That default is easy to miss. A dashboard or backend job that reads only the first response can appear to work while excluding earlier collections. The API supports count and skip, allowing the application to request later pages.
A simple pagination pattern is:
skip = 0
repeat:
response = GET /v1/payments?count=page_size&skip=skip
save response.items
skip = skip + number_of_items_returned
until number_of_items_returned is less than page_size
The exact page size should be selected within the API's documented limits. The important design choice is to advance skip using the number of records returned. A final page may contain fewer entries than the requested count, and that condition should end the loop.
For a gym with a few hundred members, a backend can run a scheduled collection sync and store each payment's gateway ID, amount in paise, currency, method, status, and creation information. The internal database should enforce uniqueness on the Razorpay payment ID so that a retry doesn't create duplicate member payments.
The job should also separate successful, failed, and unresolved records. A failed payment must not extend a membership. A payment that needs review should remain visible to staff rather than being treated as paid because a member shared a confirmation image.
Date handling deserves care. Store gateway timestamps in a consistent server format, then apply the gym's local business date when producing daily or monthly reports. A payment made near midnight can otherwise appear in the wrong reconciliation period.
Practical rule: The first API response is not the month's history. It is only one page of the history.
Cash entries should not be forced into Razorpay pagination. They originate at the front desk and need their own receipt number, staff attribution, and payment method. The final revenue report can combine both sources, but it should retain the distinction between gateway-confirmed digital payments and manually recorded cash.
A gym needs a quick decision after a member pays. If the gateway confirms the payment, the system can issue a WhatsApp receipt and update the member's renewal record. If the system marks the member paid before confirmation, staff may grant access for a payment that later remains unresolved.
Webhooks are the efficient first path. Razorpay recommends subscribing to events such as payment.authorized and order.paid, as described in its payment webhook documentation. Razorpay sends the event to the configured endpoint, so the gym backend doesn't need to repeatedly ask for every payment.
Direct API retrieval is the safety net. Razorpay's documented approach is to fetch the payment or order status immediately when a user-facing flow needs an answer and the webhook hasn't arrived within the business SLA. That matters at a busy reception desk, where the member is waiting for a receipt or access update.
| Situation | Preferred action | Reason |
|---|---|---|
| Normal payment flow | Process the webhook | It avoids repeated status requests |
| Member is waiting and no webhook has arrived | Fetch the payment or order | The front desk needs a direct answer |
| Nightly reconciliation | Fetch records with pagination | It catches records that need review |
| Duplicate notification | Ignore the repeated business action | The payment ID should be idempotent |
Webhook endpoints must use port 80 or port 443, according to Razorpay's documentation. The handler should verify the webhook signature before changing a member's billing state. It should also return an appropriate response promptly and move heavier work, such as receipt generation, into a safe background process.
A useful practical guide for API integration can help teams think through retries, event handling, and system boundaries. For gym billing, the key rule is simple: a webhook can trigger processing, but the application must make that processing idempotent.
The system should record the event, check whether the payment ID has already been applied, and only then update the member record. If the event is delayed, the fallback lookup should reach the same business logic. That prevents a payment from producing two receipts or extending the expiry date twice.
A gym's webhook and fallback policy should be written around its actual front-desk SLA. The application doesn't need to poll constantly. It needs a clear rule for when a missing event becomes a direct lookup, followed by a later reconciliation check for anything still unresolved. The UPI payment tracking guide for gyms in India covers the operational side of keeping those records usable for staff.
Most production failures are not caused by a complicated API design. They come from small mismatches between the gateway response and the gym's billing logic.
Authentication failure: The request returns an authentication error or an unauthorised response. The usual cause is an incorrect API Key ID, an incorrect API Secret, or credentials from the wrong environment. The fix is to check the server-side Authorization header and confirm that test credentials aren't being used against a live record.
Invalid payment ID: The application rejects the identifier or Razorpay returns a validation error. Confirm that the value is a Razorpay payment ID beginning with pay_, and make sure the application hasn't stored a member invoice number in the payment-ID field.
Payment not found: A 404 response usually means the ID is wrong, the record isn't available to those credentials, or the request is pointed at the wrong account context. Log the requested ID, check for whitespace or truncation, and confirm that the payment belongs to the account being queried.
Receipt shows the wrong rupee value: The code displays the paise integer directly. Keep the API value as an integer, divide by 100 only for presentation, and test the conversion with known rupee amounts.
Payment marked successful too early: The front end treats a redirect or screenshot as final confirmation. Make the backend verify the gateway status before issuing the receipt or extending access.
Duplicate renewal: A webhook retry and a manual fallback both update the member. Store the payment ID and make the update idempotent, so the second attempt produces no second financial action.
Older transactions are missing: The job reads only the default last-10 response. Use count and skip, save progress safely, and retry failed pages without inserting duplicate payment IDs.
Webhook delivery is rejected: Check the signature verification process, the exact raw request body used for verification, and the endpoint requirement for port 80 or 443. Logging the event ID and verification result helps isolate configuration errors.
Reconciliation job fails under load: Requests are sent too aggressively or retries happen immediately. Use bounded retries with exponential backoff, preserve the last successful page, and alert an operator when the job stops rather than producing an incomplete report.
Do not “fix” a missing payment by manually marking it paid. Record the exception, retrieve the gateway status, and preserve the review trail.
Payment retrieval becomes valuable when it changes a real front-desk action. A confirmed Razorpay payment can update the member's payment history, trigger a WhatsApp receipt, and refresh the revenue dashboard. The same record can support a renewal workflow without requiring staff to copy details between the gateway, a spreadsheet, and WhatsApp.
The business rules should remain explicit:
Payment-method data also helps an owner understand how collections arrive. UPI records come from Razorpay lookups, while cash requires staff entry and review. Combining both into a single revenue view without losing the original method gives the owner a clearer picture of daily collections and outstanding dues.
GymPilot supports member management, payment tracking for UPI, cash, card, partial payments, and dues, WhatsApp automation for welcome messages, receipts, and expiry reminders, revenue dashboards, attendance, check-in, product sales, staff roles, email notifications, and biometric check-in. Owners evaluating a broader payment reconciliation software workflow should check that the system preserves gateway IDs, handles paise correctly, and keeps cash records auditable.
The practical test is not whether a payment appears in a dashboard. It is whether the system can answer the member's question, update the correct account, issue the right receipt, and leave an organised record for the owner.
Gym owners and developers should test the complete flow with Razorpay test credentials before connecting live billing. Verify a single payment lookup, paise conversion, paginated history, webhook verification, duplicate-event handling, and the direct API fallback. Teams that want these payment records connected to member history, WhatsApp receipts, dues, and revenue reporting can review GymPilot's pricing and available options and choose a workflow that fits their gym's collection process.