Transaction Status Cycle

Midtrans Transaction Status Cycle Description

The table given below describes the life cycle of Transaction Status and its possible changes.

Transaction Status

Transaction StatusDescriptionPossible changes(s)
pendingTransaction is created and available/waiting to be paid by customer at the payment provider (ATM/Internet banking/E-Wallet app/store). For card payment method: waiting for customer to complete (and card issuer to validate) 3DS/OTP process.settlement,
captureTransaction is successful and credit card balance is captured successfully.
If no action is taken by you, the transaction will be successfully settled on the next day and transaction status will change to settlement.
It is safe to assume a successful payment.
settlementTransaction is successfully settled. Funds have been received.refund, chargeback, partial_refund, partial_chargeback, deny*
denyThe credentials used for payment are rejected by the payment provider or Midtrans Fraud Detection System (FDS).
To know the reason and details for denied transaction, see the status_message field in the response.
cancelTransaction is cancelled. Can be triggered by Midtrans or merchant themselves.
Cancelled transaction can be caused by various reasons:
1. Capture transaction is cancelled before Settlement.
expireTransaction no longer available to be paid or processed, because the payment is not completed within the expiry time period.
failureThe transaction status is caused by unexpected error during transaction processing.
Failure transaction can be caused by various reasons, but mostly it is caused when bank fails to respond.
This occurs rarely.
refundTransaction is marked to be refunded. Refund can be requested by Merchant.
chargebackTransaction is marked to be charged back.
partial_refundTransaction is marked to be partially refunded.
partial_chargebackTransaction is marked to be partially charged back.
authorizeOnly available specifically only if you are using pre-authorize feature for card transactions (an advanced feature that you will not have by default, so in most cases are safe to ignore). Transaction is successful and card balance is reserved (authorized) successfully. You can later perform API “capture” to change it into capture, or if no action is taken will be auto released. Depending on your business use case, you may assume authorize status as a successful transaction.capture,

Reversal Case

Known specific to payment methods of Permata Bank Transfer, Mandiri Bill Payment, and Indomaret; In some very rare cases, there is a possibility where settlement can later change into deny, also known as Reversal. It may happen usually within the span of 1-5 minutes. It is caused by reversal triggered by the corresponding payment provider (issuing/acquiring bank), due to the nature of their payment networks. This status change will trigger HTTP(s) notification/webhook from Midtrans to your server.

The change of status to deny means the transaction fund is reversed back to the customer, no fund is received on the merchant side. So merchants should treat the transaction as "not paid" (or rejected) and should not proceed the customer's order (do not deliver the goods/service to the customer). Therefore, please ensure that your notification handling logic can cover this case.

The fund will bounce-back to the customer's account automatically, but it may take time depending on the process/policy of the payment provider and their chain of networks. Customers can be advised to contact the payment provider for the status.

Status When Using Snap API

When a transaction is created on Snap API, it does not immediately assign any payment status on Core API GET Status response. Even if the payment page is activated on Snap API, you might encounter 404 or Payment not found response while calling Core API GET Status.

This is because the customer did not yet choose any payment method within the Snap payment page (idling or abandoning the Snap payment page). Once the customer proceeds with a payment method, then the transaction status is assigned and is available on Core API GET Status.

Fraud Status

The table given below describes the Fraud status.

Fraud StatusFund ReceivedDescription
acceptTransaction is safe to proceed. It is not considered as a fraud.
denyTransaction is considered as fraud. It is rejected by Midtrans FDS. FDS rejected transaction usually will not result in transaction_status: pending, capture, settlement.

API Action / Method

You can perform a number of actions on Transaction Status through API calls.

The header for all backend requests is described below.

Header NameDescriptionRequiredValues
AcceptThe format of the data to be returned.Requiredapplication/json
Content-TypeThe format of the data to be postedRequiredapplication/json
AuthorizationThe authentication method used to access the resourceRequiredBasic AUTH_STRING

AUTH_STRING: For more information, refer to API Authorization and Header.


A sample Curl code given for an API request to cancel a pending transaction is given below.

curl -X POST \ \
  -H 'Accept: application/json'\
  -H 'Authorization: Basic U0ItTWlkLXNlcnZlci1UT3ExYTJBVnVpeWhoT2p2ZnMzVV7LZU87' \
  -H 'Content-Type: application/json'


  • Sandbox Environment :
  • Production Environment :

Endpoint URLHTTP MethodDescription
/v2/[ORDER_ID]/statusGETGet information status of a transaction with a order_id.
For more information, refer to GET Status.
/v2/[ORDER_ID]/cancelPOSTCancel a transaction with order_id.
Cancelation can only be done before settlement.
For more information, refer to Cancel Transaction.
/v2/[ORDER_ID]/refundPOSTMark order_id with settlement status to be marked as refund.
For more information, refer to Refund Transaction.
/v2/[ORDER_ID]/refund/online/directPOSTAttempt to send refund to bank or payment provider directly and update the transaction status to refund if it succeeded.
For more information, refer to Direct Refund Transaction for more information.
/v2/[ORDER_ID]/expirePOSTUpdate order_id with pending status to be marked as expired.
For more information, refer to Expire Transactions.
/v2/[ORDER_ID]/status/b2bGETGet information status of multiple B2B transactions related to order_id.
For more information, refer to GET transaction status for B2B.
/v2/capturePOSTCapture a pre-authorized transaction for card payment.
For more information, refer to Capture Transaction.

For a full list and details of APIs, refer to API docs.



You can also replace order_id used in API urls with transaction_id, which uniquely generated from Midtrans side and you received as response when creating transaction, and from HTTP Notification. This is useful if your order_id contains unusual character (such as #) that may result in an invalid URL pattern.



Each of the official Midtrans Language Libraries has easy-to-use functions implementing most of the endpoints above. Please refer to the library's GitHub Repository for usage example.