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 Status	Description	Possible changes(s)
`pending`	Transaction 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, expire, cancel, deny
`capture`	Transaction 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.	settlement, cancel
`settlement`	Transaction is successfully settled. Funds have been received.	refund, chargeback, partial_refund, partial_chargeback, deny*
`deny`	The 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.
`cancel`	Transaction 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.
`expire`	Transaction no longer available to be paid or processed, because the payment is not completed within the expiry time period.
`failure`	The 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.
`refund`	Transaction is marked to be refunded. Refund can be requested by Merchant.
`chargeback`	Transaction is marked to be charged back.
`partial_refund`	Transaction is marked to be partially refunded.
`partial_chargeback`	Transaction is marked to be partially charged back.	chargeback
`authorize`	Only 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, deny, cancel, expire

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 Status	Fund Received	Description
`accept`	✅	Transaction is safe to proceed. It is not considered as a fraud.
`deny`	❌	Transaction 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 Name	Description	Required	Values
Accept	The format of the data to be returned.	Required	application/json
Content-Type	The format of the data to be posted	Required	application/json
Authorization	The authentication method used to access the resource	Required	Basic AUTH_STRING

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

Example:

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

curl -X POST \
  https://api.sandbox.midtrans.com/v2/myCustOrder123/cancel \
  -H 'Accept: application/json'\
  -H 'Authorization: Basic U0ItTWlkLXNlcnZlci1UT3ExYTJBVnVpeWhoT2p2ZnMzVV7LZU87' \
  -H 'Content-Type: application/json'

API Base URL:

Sandbox Environment : https://api.sandbox.midtrans.com
Production Environment : https://api.midtrans.com

Endpoint URL	HTTP Method	Description
/v2/[ORDER_ID]/status	GET	Get information status of a transaction with a `order_id`. For more information, refer to GET Status.
/v2/[ORDER_ID]/cancel	POST	Cancel a transaction with `order_id`. Cancelation can only be done before `settlement`. For more information, refer to Cancel Transaction.
/v2/[ORDER_ID]/refund	POST	Mark `order_id` with `settlement` status to be marked as `refund`. For more information, refer to Refund Transaction.
/v2/[ORDER_ID]/refund/online/direct	POST	Attempt 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]/expire	POST	Update `order_id` with pending status to be marked as `expired`. For more information, refer to Expire Transactions.
/v2/[ORDER_ID]/status/b2b	GET	Get information status of multiple B2B transactions related to `order_id`. For more information, refer to GET transaction status for B2B.
/v2/capture	POST	Capture 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.

📘
Note
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.

📘
Tips
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.

Updated about 4 hours ago