Transaction Operations
Orbit provides operational capabilities across the full transaction lifecycle -- from authorization through settlement, refunds, and reconciliation. These capabilities ensure that you can manage payment outcomes reliably across all payment modes and payment partners.
Delayed Authorization Management
What is Delayed Authorization
In most payment flows, the payment partner confirms success or failure within seconds. Delayed authorization covers the cases where that confirmation does not arrive in real time. The partner may take minutes, hours, or even days to report a terminal outcome, leaving the transaction in a pending state until resolution. Orbit allows you to configure how long to wait for confirmation -- from 5 minutes to 5 days -- based on your business requirements. During this window, Orbit continues to monitor the transaction and will act on the outcome once the partner responds. For a full view of how transaction states progress, see Payment States.
Use Cases
Delayed authorization applies to several common scenarios:
- Bank server timeouts -- the acquiring bank does not respond within the expected window, leaving the transaction in a pending state until the bank confirms.
- UPI pending states -- the customer initiates a UPI payment but does not complete authentication on their device, or the UPI network delays the callback.
- Netbanking session drops -- the customer's session with the bank ends without a clear success or failure signal being returned to the payment partner.
- EMI processing delays -- EMI approvals that require additional verification from the issuer can take longer than standard card transactions.
The configurable delay window lets you match the wait period to your business model. A live event ticketing platform may use a short window (5--15 minutes), while a digital services provider may allow several hours.
Reversals
When a delayed payment succeeds after the configured authorization window has expired, Orbit automatically triggers a reversal to return the funds. This prevents scenarios where a customer is charged for an order that has already been cancelled or fulfilled through other means.
If multiple payments succeed for the same order (duplicate payments due to delayed confirmations), Orbit retains the first successful payment and reverses all subsequent duplicates. These automatic reversals follow a distinct flow from merchant-initiated refunds -- they are system-triggered and do not require action on your part. If an automatic reversal does not complete, the transaction moves to a "reversal failed" state, which you can resolve through the manual reversal flow in Refund Processing.
Error Code Mapping and Management
Orbit handles authorization and capture across all supported payment modes and partners. The authorization flow varies by payment mode -- UPI uses intent, QR, or collect flows; cards use 3DS authentication where required; Netbanking and wallets redirect to the respective provider.
Orbit normalizes authorization outcomes across partners so you receive consistent status updates regardless of which partner processed the transaction. Error codes from different partners are mapped to standardized codes and messages, which drives two key behaviors:
- Retry eligibility -- whether a failed transaction can be retried based on the error category.
- Fallback routing -- whether the error qualifies for routing to an alternative payment partner (when routing rules are enabled through Pulse).
Refund Processing
Refund Types
Orbit supports two primary refund types. A full refund returns the entire captured amount of the original transaction to the customer. A partial refund returns a specific amount that is less than the total captured amount. You can issue multiple partial refunds against a single transaction until the cumulative refunded amount equals the original captured amount. Refund amounts are validated against the original transaction to prevent over-refunding. Both types route through the same payment partner that processed the original transaction. For details on refund states and lifecycle, see Refund States.
SKU/Serial Number Refunds
For transactions that include order line items, Orbit supports item-level refunds using SKU references and serial numbers. Instead of specifying a refund amount directly, you reference specific items from the original order, and Orbit computes the refund amount from the item data. Serial numbers are recorded during payment and validated during the refund to ensure inventory consistency. For Pinelabs EMI transactions, this includes IMEI/serial blocking at payment time and automatic unblocking when the refund succeeds. While any serial number remains blocked on a transaction, amount-based partial refunds are prevented to maintain inventory accuracy.
Multi-Currency Refunds
When the original transaction involved currency conversion -- either Alternate Currency Conversion (ACC) or Dynamic Currency Conversion (DCC) -- the refund must account for exchange-rate handling. Orbit applies the appropriate exchange rate based on your configuration, which may use the original transaction rate or the current rate at refund time. The refund currency, exchange rate, and converted amount are tracked alongside the refund record for reconciliation. This ensures that the customer receives the correct refund value in their billing currency, and your settlement records reflect the accurate converted amounts. For full details on currency conversion behaviour, see Multi-Currency.
Bulk Refunds
Orbit supports processing multiple refunds in a single batch operation. Refund requests are grouped under a batch identifier, and each refund is processed independently -- routed through the original payment partner path with individual outcome tracking. This is useful for scenarios such as event cancellations, subscription billing corrections, or any case where you need to refund a large number of transactions at once. Batch status is tracked at both the individual refund level and the overall batch level, so you can monitor progress and identify any refunds that require attention.
Reversal Failed and Manual Reversals
When an automatic reversal (triggered by delayed authorization or duplicate payment detection) does not complete successfully at the payment partner, the transaction enters a "reversal failed" state. This is a distinct terminal state that indicates the funds were not returned automatically and require manual intervention.
From this state, you can initiate a manual reversal through the standard refund flow. The manual reversal follows the same processing path as a merchant-initiated refund -- it routes through the original payment partner and is tracked as a refund transaction. For context on when automatic reversals are triggered, see Delayed Authorization Management above. For the full set of transaction states including reversal states, see Payment States.
Transaction Status Monitoring and Reconciliation
Status Monitoring
Orbit continuously tracks payment status across all connected payment partners. When a transaction does not reach a terminal state (success or failure) within the expected timeframe, Orbit flags it for follow-up. Status checks are performed through partner enquiry APIs -- Orbit polls the payment partner for the latest status and compares it against the internal record. Inbound webhooks from partners are also processed as they arrive, providing an additional status signal. This combination of polling and webhook ingestion ensures that Orbit detects status changes even when one channel is delayed or unavailable.
Reconciliation
Reconciliation is the process of comparing Orbit's internal transaction records against the payment partner's records to detect discrepancies. When the partner reports a different status than what Orbit holds (for example, a transaction marked "pending" internally but reported as "success" by the partner), Orbit automatically corrects the internal status to match. For refund transactions, reconciliation continues until a terminal status is reached and partner artifacts such as the refund ARN (Acquirer Reference Number) are captured. This ensures that your records are accurate for settlement and audit purposes.
Intelligent Scheduling
Status checks are not performed at fixed intervals. Orbit uses intelligent scheduling with progressive delays between retries -- early checks are more frequent, and the interval increases as the transaction ages. Each transaction type has its own retry limits and maximum enquiry window. For example, payment transactions can be monitored for up to 5 days from creation, while refund transactions continue until a terminal status and partner artifacts are available. This approach balances timely detection against unnecessary load on partner APIs.
Webhook Delivery
When a transaction status changes, Orbit delivers the update to your systems via webhooks. Webhook payloads include the transaction identifier, the new status, and relevant metadata. Orbit uses a retry mechanism for failed deliveries -- if your endpoint does not acknowledge receipt, the webhook is retried with progressive backoff. Each webhook includes a signature that you can verify to confirm the payload originated from Nimbbl and was not tampered with in transit. For implementation details, see Webhooks and Transaction Enquiry.