Transaction Idempotency

About 790 wordsAbout 3 min

2025-03-07

Idempotency Modes

There are two supported idempotency modes, you can choose the appropriate idempotency mode from below:

The following are possible transaction statuses that may be returned in different scenarios:

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

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 pre-authorization cancellation
`PROCESSING`	Intermediate state, cannot initiate CAPTURE operation, merchant should wait for PingPongCheckout asynchronous result before business processing.
`INIT`	Order initialization

Status Transition Description

The following statuses will send transaction asynchronous notifications:
- SUCCESS
- FAILED
- CANCEL
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.

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)