Transaction Idempotency
Idempotency Modes
There are two supported idempotency modes, you can choose the appropriate idempotency mode from below:
Transaction Status List
The following are possible transaction statuses that may be returned in different scenarios:
Automatic Capture
| Status | Description |
|---|---|
SUCCESS | Payment successful, transaction successful |
CLOSED | Transaction result due to timeout/closure |
FAILED | Payment failed, user can retry payment |
CANCEL | Risk control review rejected, final state |
PROCESSING | Intermediate state, merchant should wait for PingPongCheckout asynchronous result before business processing. |
INIT | Order initialization |
Manual Capture
| Status | Description |
|---|---|
SUCCESS | Final CAPTURE successful |
AUTH_SUCCESS | AUTH operation successful, still need to initiate CAPTURE operation |
CLOSED | Transaction result due to timeout/closure |
FAILED | Payment failed, user can retry payment |
CANCEL | AUTH operation successful, calling VOID for pre-authorization void |
PROCESSING | Intermediate state, cannot initiate CAPTURE operation, merchant should wait for PingPongCheckout asynchronous result before business processing. |
INIT | Order initialization |
Order Lifecycle
Cashier Mode
In Cashier mode, the merchant creates a payment session first. The order enters PROCESSING from INIT, and the shopper completes the payment flow on PingPong Checkout.
API Only Mode
In API Only mode, the merchant server creates and advances the payment request through APIs. The status usually starts from PROCESSING; in non-terminal failure mode, the shopper can place a new payment request for re-attempt.
Status Transition Description
The following statuses will send transaction asynchronous notifications:
SUCCESSFAILEDCANCEL
For scenarios where transaction status is not in the above status list, the order API or query interface will synchronously respond with
PROCESSING, merchants should wait for PingPongCheckout asynchronous result before business processing.When the merchant sends the order closure notification URL (closeNotificationUrl) in the order placement interface, an order closure asynchronous notification will be sent after the order is closed:
CLOSED
This status is the order's final state. This notification is associated with merchantTransactionId (merchant transaction ID) to ensure accurate tracking and identification of specific orders.
Order Association Relationship
Transaction Idempotency Rules
- Payment orders require merchantTransactionId (merchant website order number) to be globally unique; if duplicate orders are placed, the system will idempotently return the payment order information. (Cashier Mode)
- Payment requests are uniquely identified by merchantTransactionId + requestId; if duplicate payment requests are made, the system will idempotently return the payment request status information (S2S Mode)
Based on the above idempotency rules, we provide some retry windows (see detailed Transaction Recovery)