Idempotency Modes

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

1. Non-Failure Final State (default)
2. Failure Final State

Transaction Status List

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

Automatic Capture

Status	Description
	Payment successful, transaction successful
	Transaction result due to timeout/closure
	Payment failed, user can retry payment
	Risk control review rejected, final state
	Intermediate state, merchant should wait for PingPongCheckout asynchronous result before business processing.
	Order initialization

Manual Capture

Status	Description
	Final CAPTURE successful
	AUTH operation successful, still need to initiate CAPTURE operation
	Transaction result due to timeout/closure
	Payment failed, user can retry payment
	AUTH operation successful, calling VOID pre-authorization cancellation
	Intermediate state, cannot initiate CAPTURE operation, merchant should wait for PingPongCheckout asynchronous result before business processing.
	Order initialization

Order Lifecycle

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.

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)

Previous pageCurrency Exchange Guide

Next pageTransaction Recovery