Overview
While asynchronous webhook callbacks (payment_step: 2) are Niobi’s primary real-time notification mechanism, the Get Transaction Status API provides an authoritative on-demand verification endpoint.
Use this endpoint to:
- Resolve In-Doubt Transactions: Check transaction outcomes if a temporary network disruption delayed your incoming callback.
- Execute Double-Verification: Reconcile mission-critical payments (such as high-value payouts or instant digital wallet top-ups) by confirming webhook data against an independent status query.
- Audit & Recover: Safely query historical or batch transaction records during automated ledger closeouts.
API Environments & Base URLs
Request Parameters
The status query endpoint requires standard HMAC SHA-256 envelope parameters wrapping the query details in params:
Root Envelope Fields
Parameters (params Object)
Sample Status Query Requests
Collection Query (payin)
Payout Query (payout)
Sample Query Responses
Successful Transaction (000000)
Pending Transaction (000001)
Failed Transaction (000005)
Timed Out Collection (000006)
Status Codes & Action Matrix
When querying transaction status, inspect both data.status and data.status_code:
Strict Rule on pending (000001):
Never release value, credit user wallets, fulfill goods, or retry payments while a transaction is in pending status. A pending status indicates the transaction is in-flight across banking or telecommunication switches. Always wait for a terminal status (000000 or 000005).
The Double-Verification Reconciliation Recipe
For platforms managing high financial volume, automated payroll, or instant digital withdrawals, implement Niobi’s recommended double-verification recipe:
Reconciliation Checklist:
- Inbound Signature Verification: Validate incoming webhook signatures using your Secret Key before parsing data.
- Concurrency Control: Use database row-level locking (
SELECT ... FOR UPDATE or optimistic locking on third_party_reference_1) to ensure duplicate callbacks or simultaneous polling queries do not process twice.
- Triple-Point Match: Confirm that
statusCode, amount, currency, and third_party_reference_1 match your internal order record exactly.
- Atomic Settlement: Update your internal ledger to
SETTLED inside a single atomic database transaction.
Polling Guidelines & Best Practices
To ensure optimal performance and avoid hitting rate limits:
- Rely on Webhooks First: Use callbacks as your primary notification channel.
- Avoid Tight Polling Loops: Never poll the status API immediately in rapid loops (e.g. every second).
- Use Spaced Backoff Intervals: If you must poll for a pending transaction, use progressive spaced intervals (for example: wait 5 seconds after initiation, then 15 seconds, then 30 seconds, then 60 seconds).
- Idempotency Keys: Always query using the same
third_party_reference_1 or reference originally assigned to the transaction.
Next Steps
Explore related operational and security guides: