Fallback & Recovery
Fallback and recovery in Pulse saves more payments when a payment partner fails. Instead of surfacing the failure immediately, Pulse can automatically try an alternative partner path, remember which partners recently failed for the same order or shopper, and avoid those partners on subsequent attempts.
Pulse provides three fallback behaviors:
- Automatic retry tries the next best eligible payment partner within the same payment attempt.
- Order memory avoids partners that failed for the same order within a recent time window.
- User memory avoids partners that failed for the same shopper within a recent time window.
| Behavior | Trigger | What It Does | Window | Merchant Impact |
|---|---|---|---|---|
| Automatic retry | A payment attempt fails | Tries the next best eligible partner, excluding partners already tried | Same attempt, bounded by soft timeout and retry limits | Improves in-attempt recovery without requiring the customer to restart |
| Order memory | Customer retries payment for the same order | Avoids partners that failed for this order in a recent window | Configurable hours, order-scoped | Improves success on subsequent attempts for the same order |
| User memory | Customer retries across orders or returns later | Avoids partners that failed for this shopper in a recent window | Configurable hours, user-scoped | Improves experience for repeat shoppers by skipping recently failed partners |
When a payment fails, Pulse evaluates whether an alternative payment partner is available. It excludes partners that have already been tried in the current attempt, partners flagged by order memory, and partners flagged by user memory. From the remaining eligible options, Pulse selects the next best partner using the active rule-based or dynamic routing configuration. Checkout stays responsive through a soft timeout that stops fallback retries if too much time has passed, preventing the customer from waiting indefinitely.
Automatic Retry
Automatic retry operates within a single payment attempt. When the initial payment partner returns a failure, Pulse immediately selects the next best eligible partner while excluding options already tried. This cycle continues until the payment succeeds or limits are reached.
How It Works
When a payment partner returns a failure, Pulse excludes that partner and selects the next best eligible option using the active rule-based or dynamic routing configuration. Partners already tried in the current attempt are excluded from consideration. This cycle repeats automatically until the payment succeeds, all eligible options are exhausted, or retry limits are reached. The customer does not need to restart the payment flow.
Soft Timeout
A soft timeout bounds how long automatic retry can run. If the timeout expires, Pulse stops returning new partner options for that attempt. This keeps checkout fast and predictable, preventing the customer from waiting indefinitely while retries are attempted in the background. The timeout applies to the entire retry sequence, not to individual partner attempts.
Single Reset
When all eligible options are exhausted, a single controlled reset can reopen options once. The reset clears the current ineligible set and marks earlier failed attempts as ignored so the routing engine can consider those partners again. This provides one additional recovery opportunity before the attempt is finalized. Only one reset is permitted per payment attempt.
Fee-Safe Rules
Where convenience fees apply, automatic retries are restricted so that fallback does not unexpectedly change fee outcomes for the customer. If a fallback configuration could produce fee surprises -- for example, by routing to a partner with a different fee structure -- the configuration is treated as invalid. This ensures that the fee displayed at checkout remains accurate regardless of which partner ultimately processes the payment.
Order Memory
Order memory ensures that when a customer retries payment for the same order, partners that recently failed are excluded. Pulse uses order memory as an implicit downtime signal: repeated failures for the same order cause the failing partner to be automatically bypassed on subsequent attempts.
How It Works
When a payment partner fails for a given order, Pulse records the failure against the order ID. On subsequent payment attempts for that same order, Pulse excludes partners that failed within the configured time window. This avoids sending the customer back to a partner that just failed, improving the likelihood of success on retry without requiring any action from the customer.
Configuration
Order memory is configured per payment mode with a time window measured in hours. Combined with dynamic routing, which monitors success rates across broader transaction populations, Pulse can respond to both individual-level failures (through order memory) and systemic performance degradation (through routing priority adjustments).
User Memory
User memory extends avoidance to the shopper level, so returning customers are not routed to partners that recently failed for them.
How It Works
When a payment partner fails for a given shopper, Pulse records the failure against the shopper's identity. On subsequent payment attempts by the same shopper -- whether for the same order or a different one -- Pulse excludes partners that failed within the configured time window. This improves the payment experience for repeat shoppers by preventing them from encountering the same failed partner path again.
Configuration
User memory is configured per payment mode with a separate time window (measured in hours) that is independent of order memory. The memory is scoped to the shopper's identity, so it applies across all orders placed by that shopper within the window. Combined with order memory, this provides layered failure avoidance at both the order and shopper levels.
Payment Modes Eligible for Fallback
Fallback routing applies to most payment modes but is not supported for Card EMI, Cardless EMI, Pay Later, UPI Collect, and Loyalty Points. For payment modes with sub-modes (such as UPI Intent and UPI Collect), eligibility is determined independently per sub-mode.