Payment lifecycle and order statuses

Order status transitions

Order status reference

Status	Description	Final
`PAY_IN_PROGRESS`	The order has been accepted and the user is in the process of paying	No
`AUTHORIZATION_REQUIRED`	The payment method requires user authorization (e.g., an e-wallet)	No
`AUTHED_WAITING_CAPTURE`	Authorized, awaiting capture confirmation (card payments; requires the merchant to confirm capture)	No
`PAY_SUCCESS`	Payment succeeded	Yes
`ORDER_CLOSE`	The order is closed (cancelled, failed, or timed out)	Yes

Subscription statuses

A subscription starts in IN_PROGRESS. It enters AUTHORIZATION_REQUIRED when the user must select a payment method or complete authorization. After the user completes authorization, processing continues toward ACTIVE; failures or timeouts move the subscription to CLOSE. Cancellation statuses and EXPIRED are final. The diagram shows only the key path through creation, authorization, activation, and completion; see the table below for each final status.

Status	Description	Action
`AUTHORIZATION_REQUIRED`	User authorization is required (e-wallet scenario)	Redirect to the `subscriptionAction` URL
`IN_PROGRESS`	The user is confirming the subscription	Wait for the Webhook
`ACTIVE`	The subscription is active and charging normally	Store the `subscriptionId`
`CLOSE`	Closed (timed out or failed)	Re-initiate if needed
`MERCHANT_CANCELLED`	Cancelled by the merchant	—
`USER_CANCELLED`	Cancelled by the user	Update local records
`CHANNEL_CANCELLED`	Cancelled by the channel	Notify the user
`PLATFORM_CANCELLED`	Cancelled by the platform	Check `cancelReason` in the subscription inquiry response
`EXPIRED`	The subscription has expired	Re-initiate if needed

Refund statuses

Status	Description
`REFUND_IN_PROGRESS`	Refund is being processed
`ORDER_PARTIALLY_REFUNDED`	Partial refund completed
`ORDER_FULLY_REFUNDED`	Full refund completed
`ORDER_REFUND_FAILED`	Refund failed

Best practices

Use the Webhook as the only source of truth: redirect URLs are only for user experience and should not be used to determine the payment result.

Handle intermediate states: do not automatically close orders in PAY_IN_PROGRESS; wait for the Webhook or query proactively
Idempotent handling: Webhooks may be delivered more than once; ensure your handling logic is idempotent. See Idempotency
Unknown status: when you encounter error code E0001, query using the original paymentRequestId and do not automatically close the order. For the full handling flow, see Error handling

Getting Started

Core Concepts

Integration

Webhook

SDK

Tools & Reference

Point Topup API

Payment lifecycle and order statuses

Order status transitions

Order status reference

Subscription statuses

Refund statuses

Best practices

​Order status transitions

​Order status reference

​Subscription statuses

​Refund statuses

​Best practices

Order status transitions

Order status reference

Subscription statuses

Refund statuses

Best practices