Transaction Enquiry
Transaction Enquiry is a pull API — you call it on demand to get the current status of an order and its transactions, instead of waiting for Nimbbl to push you a webhook. Use it alongside webhooks, not instead of them.
When to Use This
Reach for Transaction Enquiry when:
- A client-side response times out or is unclear. If your server never receives the result of a payment attempt, poll this endpoint to resolve it rather than guessing from the client.
- You're reconciling your records. Confirm your stored status matches Nimbbl's before closing out an order.
- You want an on-demand status check. For example, before retrying a stuck order.
Webhooks remain your primary, real-time signal — this endpoint is the fallback and the reconciliation tool, not a replacement for consuming webhooks.
Making a Request
Call the endpoint with any one of transaction_id, order_id, or invoice_id:
{
"order_id": "o_Rz4Zx2WeyooEpyxa"
}
Encryption is supported the same way as elsewhere — see Using Encrypted Payloads if enabled for your sub-merchant.
Reading the Response
The response carries a transaction array and an order object. A successful, fully-captured payment looks like this (trimmed):
{
"transaction": [
{
"nimbbl_transaction_id": "o_g94KAZa6YmedjbaQ-8a291",
"transaction_type": "payment",
"payment_status": "succeeded",
"message": "Payment Successful",
"payment_partner": "Payu",
"payment_mode": "Netbanking",
"transaction_amount": 10000.0,
"transaction_currency": "INR",
"nimbbl_signature": "<hmac-sha256-hex>",
"signature_version": "v3"
}
],
"order": {
"nimbbl_order_id": "o_g94KAZa6YmedjbaQ",
"invoice_id": "r12_10651594",
"status": "completed",
"total_amount": 10000.0,
"refund_details": {
"refundable_currency": "INR",
"available_refundable_amount": 10000.0,
"refunded_amount": 0.0,
"total_refundable_amount": 10000.0
}
}
}
See the Transaction Enquiry API reference for the exhaustive field list.
Pre-Authorization Fields
When the transaction is a pre-authorization (capture_mode is manual on the sub-merchant), the transaction carries an authorization_details block:
{
"nimbbl_transaction_id": "o_g94KAZa6YmedjbaQ-8a292",
"transaction_type": "payment",
"payment_status": "authorized",
"authorization_details": {
"mechanism": "pre_auth",
"capture_mode": "manual",
"authorized_time": "2025-06-15 10:30:00",
"expiry_deadline": "2025-06-20 10:30:00",
"captured_amount": 0.0,
"voided_amount": 0.0,
"available_authorized_amount": 5000.0
}
}
See Pre-auth and Capture for how to act on these fields.
v4 Signature Behavior
If your sub-merchant is configured on payment_callback_version v4, this endpoint returns null for both nimbbl_signature and signature_version — the v4 whole-payload signature scheme doesn't apply here, and there's no replacement signature to validate on this surface. This is expected, not a bug: if you're migrating to v4 and currently validate the enquiry signature, remove that check before you flip the version.
Datetime Format
Timestamps on this endpoint (authorized_time, expiry_deadline, and others) are rendered as YYYY-MM-DD HH:MM:SS in UTC, with no timezone offset — for example 2025-06-15 10:30:00. This differs from the payment callback and webhook surfaces, which render the equivalent timestamps as ISO 8601 with an offset (2025-06-15T10:30:00Z). Parse each surface with the format it actually uses.