---
title: Transaction Recovery
permalink: /en/notes/onlinePayment/bestPractices/rescue/
createTime: '2025/03/07 16:01:49'
description: 'Learn retry and recovery recommendations for timeout and processing scenarios.'
---

Failed transactions in certain cases, such as when shoppers have insufficient account funds, may succeed if the payment is resubmitted at a later time. In other cases, such as when shoppers' accounts are already closed, payments will be permanently rejected.
PingPongCheckout will arrange automatic retries for rejected payments that have a chance of success, or provide a short-term retry window for transactions that cannot succeed. Recovering a payment may require multiple retry attempts. These attempts are scheduled by you within a short time window.

## Transaction Retry Window

+ For the same payment order, additional payment requests can be initiated before successful payment completion (one payment order corresponds to multiple payment requests)
+ If merchants do not want multiple payment requests for the same payment order, they can pass the same requestId for the same payment order in the payment interface to allow only one payment request (Non-Hosted mode only)
+ Because of requestId idempotency, before an order is successfully paid, if merchants pass different requestIds (or use checkout mode) and initiate payment requests simultaneously, there is a possibility of duplicate payments, which would then require manual refund operations in the backend


```mermaid
%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#2196F3',
    'primaryTextColor': '#FFFFFF',
    'primaryBorderColor': '#1976D2',
    'lineColor': '#1565C0',
    'secondaryColor': '#E3F2FD',
    'tertiaryColor': '#BBDEFB',
    'background': '#F8FBFF',
    'mainBkg': '#E3F2FD',
    'nodeBorder': '#1976D2',
    'clusterBkg': '#F5F5F5',
    'clusterBorder': '#1976D2',
    'titleColor': '#0D47A1'
  }
}}%%

flowchart LR
    subgraph CheckOut["🔄 CheckOut"]
        direction TB

        subgraph Hosted["📦 Hosted Mode"]
            direction TB
            H1[INIT] -->|Various reasons for<br/>payment failure| H2[PROCESSING/FAILED]
            H2 -->|PROCESSING can<br/>retry payment| H2
            H1 --> H3[SUCCESS]
            H3 -->|Cannot retry<br/>payment| H3
            H1 --> H4[PROCESSING]
            H4 -->|Payment not yet<br/>successful| H5[FAILED]
            H5 --> H6[Retry payment<br/>within window]
        end

        subgraph NonHosted["🔧 Non-Hosted Mode"]
            direction TB
            N1[Same requestId] --> N2[PROCESSING/FAILED]
            N2 -->|Various reasons,<br/>can change card to retry| N3[SUCCESS]
            N1 --> N4[SUCCESS]
            N4 -->|Cannot retry<br/>payment| N4

            N5[Different requestId] --> N6[PROCESSING/FAILED]
            N6 -->|Cannot retry<br/>payment| N6
            N5 --> N7[SUCCESS]
            N7 -->|Cannot retry<br/>payment| N7

            N8[Local Payment] --> N9[SUCCESS]
            N9 -->|Cannot retry<br/>payment| N9
        end
    end

    style H3 fill:#4CAF50,stroke:#388E3C,color:#FFFFFF
    style H5 fill:#F44336,stroke:#D32F2F,color:#FFFFFF
    style N3 fill:#4CAF50,stroke:#388E3C,color:#FFFFFF
    style N4 fill:#4CAF50,stroke:#388E3C,color:#FFFFFF
    style N7 fill:#4CAF50,stroke:#388E3C,color:#FFFFFF
    style N9 fill:#4CAF50,stroke:#388E3C,color:#FFFFFF

```

::: note Note
For cases outside the retry window, it is recommended to add a suffix after the order number to initiate a new transaction. When performing reconciliation or observing success rate statistics, you can match them as the same order based on the suffix rules.
:::