Please contact your Midtrans sales representative to integrate with the API.

This section covers API references for the Standar Nasional Open API Pembayaran (SNAP) version of Midtrans' Core API.

Standar Nasional Open API Pembayaran, or in short SNAP, is a national payment open API standard published by Bank Indonesia as per enacted in BI Governor Decree No. 23/10/KEP.GBI/2021, dated 16th of August 2021.

SNAP covers aspects of the payment integration between payment providers and merchants that includes:

  1. Technical and security standards that include data standards and technical specifications
  2. Governance guidelines for interconnected and interoperable open API payments

What Change?


For more details on merchant migration & backward compatibility, please refer to this page

As regulated by Bank Indonesia, merchants will need to integrate to BI-SNAP-based Core API. This section describes how Midtrans merchant can integrate to this new API, we will also explain in detail what are the differences between BI-SNAP-based Core API and Midtrans existing Core API.

API Domain

EnvironmentLegacy Core APIBI-SNAP-based Core API
Staging- Get Auth Code API: merchants-app.stg.midtrans.com
- All other APIs: merchants.stg.midtrans.com
Productionapi.midtrans.com- Get Auth Code API: merchants-app.midtrans.com
- All other APIs: merchants.midtrans.com


Merchant Credentials

Legacy Core APICredentialsDefinition
Server keyMerchant’s key generated by Midtrans that is used for BASIC AUTH authentication for all Midtrans API
Merchant ID (MID)Merchant’s unique ID generated by Midtrans as part of the onboarding process

While in SNAP-based Core API, the credentials differ based on the API scope as follow:

BI-SNAP-based Core APICredentialsDefinitionRemarks
Both API scopeMerchant ID (MID)Merchant’s unique ID generated by MidtransExisting
Access Token API scopeMerchant's public keyCreated by merchant. Will be used by Midtrans to validate merchant’s signatureNew
Client IDProvided by Midtrans. Will be used as X-CLIENT-KEY on request headerNew
Transactional API scopeClient secretProvided by Midtrans. Will be used for signature generationNew
Partner IDProvided by Midtrans. Will be used as X-PARTNER-ID on request headerNew

Authorization Behavior

Legacy Core APIBI-SNAP-based Core API
Merchant will only need to use server key to initiate API calls1. Merchant need to call Access Token API first to generate a token that will be used for subsequent APIs, up until the token expired
2. Merchant need to create signature for all API calls. Please refer to Signature Generation section.

Transaction Status

Legacy Core APIBI-SNAP-based Core API
PENDING03 (Pending)
AUTHORIZE01 (Initiated)
SETTLEMENT00 (Success)
CANCEL05 (Canceled)
FAILURE06 (Failed)
EXPIRY08 (Expiry)
DENY09 (Rejected)


  • Only transaction status on API response that will change. Transaction status on Midtrans dashboard and reporting will remain the same as Legacy API.
  • We will only return the transaction status numeric value in the actual API response. The text value (...) is only the status code description that won't be returned.

Transaction & Account Identification

Legacy Core APIBI-SNAP-based Core API
Midtrans generated transaction unique ID that is generated after transaction is successfully created. This ID can be used on all Midtrans APIs, such as in status API, cancel API, and refund API.
Same definition and usage as transaction_id in legacy API.
Merchant generated transaction ID that is unique per successful transaction. This ID can be used on all Midtrans APIs, such as in status API, cancel API, and refund API.
Same definition as order_id, this ID will be shown as merchant's order ID on the dashboard and reporting.

Merchant generated ID that needs to be unique for all transactions. This ID can be passed in subsequent API calls (status, refund, cancel API) as an alternative value for originalExternalId. Please note we highly recommend merchant to use UUID format to avoid duplication. The TTL for this ID is 24 hours.

Note: Unlike order_id in the legacy API, partnerReferenceNo doesn't have unique validation and is not recommended to be used as a value in subsequent APIs. Instead, we highly recommend merchant to use originalReferenceNo (referenceNo value that is generated by Midtrans) or originalExternalId (X-EXTERNAL-ID value) in subsequent API calls.
Key that is sent by merchant to ensure that transaction is only created once. If transaction already succeed and merchant re-send the same idempotency-key on request, Midtrans will response the same successful response as the first request.
Has the same usage as idempotency-key in legacy API.
account_id (only for GoPay Tokenization)
Midtrans account unique ID that is generated as part of the account linking process. Will be used for initiating transaction.
Authorization-Customer (only for GoPay Tokenization)
Same definition as account_id in legacy API. For account that has been linked using the legacy API, merchant need to exchange the account_id with Authorization-Customer token to initiate transaction in SNAP-based API.


Legacy Core APIBI-SNAP-based Core API
Merchant only required to share one notification URL for all payment type notification in MidtransThere will be differences in notification’s relative path per payment type flow. Merchant required to share their notification URL domain, where Midtrans will attach the dynamic relative path.

Merchant’s SNAP-based URL: https://www.merchant.open-api.com/1.0

URL that will be dynamically created by Midtrans will be:
- Direct Debit API: https://www.merchant.open-api.com/1.0/debit/notify
- MPM API: https://www.merchant.open-api.com/1.0/qr/qr-mpm-notify

Note: Virtual Account will still uses the legacy Midtrans post notification

To be able to receive notification from Midtrans, merchant will need to whitelist this set of IPs based on the environment.