There are two kinds of API Scope, which are called B2B Access Token API and Transactional API. Both of these APIs have different sets of security specifications.

This is the flow that merchants will commonly use for all integrations, showing how both of these API scopes will be used throughout the integration:

As you can see on the above image, merchant will be required to call for B2B Access Token API to get the Access Token that will be used for subsequent Transactional API until the access token given expired.

Encryption Standards

Midtrans BI-SNAP Core API implements three categories of cryptographic standards, aligned with ASPI's specification:

Asymmetric Signature (Standard Asymmetric Encryption Signature)

Aspect	Specification
Algorithm	SHA256withRSA
Minimum key length	RSA 2048-bit
Key format	PKCS#8, PEM-encoded
Used for	B2B Access Token API signature (`X-SIGNATURE` header) — merchant signs with private key, Midtrans verifies with merchant's public key
Also used for	Notification callback signature — Midtrans signs with its private key, merchant verifies with Midtrans' public key

Symmetric Signature (Standard Symmetric Encryption Signature)

Aspect	Specification
Algorithm	HMAC_SHA512
Key	Client secret (provided by Midtrans during credential exchange)
Used for	Transactional API signature (`X-SIGNATURE` header) — ensuring message integrity and authenticity for payment, refund, cancel, and status operations
StringToSign formula	`HTTPMethod + ":" + EndpointUrl + ":" + AccessToken + ":" + Lowercase(HexEncode(SHA-256(minify(RequestBody)))) + ":" + Timestamp`

Symmetric Encryption (Standard Symmetric Encryption)

Aspect	Specification
Algorithm	AES-256
Key derivation	Client secret
Used for	Encryption of sensitive payload fields where applicable (e.g., credential exchange payloads transmitted via secured channels)

Midtrans implements secure channel communication to ensure the confidentiality of transmitted messages. The standard minimum version to be used is Transport Layer Security (TLS) 1.2 For detailed signature generation examples and step-by-step walkthroughs, refer to the Signature Generation page.

TLS Version & Cipher Suites (Secured Channel Communication)

Midtrans implements secure channel communication to ensure the confidentiality of transmitted messages.

Aspect	Specification
Minimum supported version	TLS 1.2
Preferred version	TLS 1.3
Protocol enforcement	All BI-SNAP Core API endpoints require HTTPS. Plain HTTP requests are rejected.
Weaker protocols	SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 are disabled on all endpoints

Supported Cipher Suites

Midtrans supports the following GCM-based cipher suites aligned with BI-SNAP requirements:

Cipher Suite	TLS Version
`TLS_AES_128_GCM_SHA256 (128 bits, Curve 25519)`Preferred	TLS 1.3
`TLS_AES_256_GCM_SHA384`	TLS 1.3
`TLS_CHACHA20_POLY1305_SHA256`	TLS 1.3
`ECDHE-RSA-CHACHA20-POLY1305`Preferred	TLS 1.2
`ECDHE-RSA-AES128-GCM-SHA256`	TLS 1.2
`ECDHE-RSA-AES256-GCM-SHA384`	TLS 1.2

Non-GCM and CBC-mode cipher suites are disabled to prevent known vulnerabilities. Please find more information in Security Information Page

Key Management Lifecycle

Key Types

Key Type	Owner	Purpose
Merchant private key	Merchant	Signs Access Token API requests (SHA256withRSA). Must be kept confidential on merchant's side.
Merchant public key	Merchant → Midtrans	Registered with Midtrans to verify merchant signatures on Access Token API requests.
Midtrans private key	Midtrans	Signs notification callbacks sent to merchants. Kept in secure key management infrastructure.
Midtrans public key	Midtrans → Merchant	Provided to merchants to verify notification callback signatures.
Client secret	Midtrans → Merchant	Shared secret used for HMAC_SHA512 symmetric signature on Transactional APIs.
TLS certificates	Midtrans / Merchant	Server certificates for HTTPS endpoints. Issued by trusted Certificate Authorities.

Key Generation

Merchant RSA keypairs: Generated by merchants using OpenSSL or equivalent tools. Minimum key length is 2048 bits (RSA). Keys must be in PKCS#8 format, PEM-encoded. See Credential Exchange for generation commands.
Midtrans-managed keys: Generated and stored within secure key management infrastructure with hardware-level protection and strict access controls.
Client secrets: Generated by Midtrans during credential provisioning and delivered via secured channels.

Key Storage

Party	Storage Controls
Midtrans	Keys are stored in hardware-backed key management services (KMS) with encryption at rest, role-based access control, and comprehensive audit logging
Merchant	Merchants are responsible for securing their private keys and client secrets. Recommended practices include: use of HSM or KMS, encryption at rest, restricted access, no storage in source code repositories

Key Rotation

Time-based rotation: Merchants may rotate their RSA keypairs at any time by generating a new keypair and registering the new public key via the Dashboard (Settings > Access Keys)
Client secret rotation: Merchants can request client secret rotation through Midtrans support.
Midtrans key rotation: When Midtrans rotates its signing keys, merchants are notified in advance and provided the new public key via secured channels

Key Revocation

When a merchant is offboarded, all associated credentials (Client ID, client secret, partner ID) are revoked and the registered public key is deactivated
If a key is compromised, Midtrans can immediately revoke the affected credentials upon notification, blocking all API access until new credentials are issued
Revoked keys and secrets cannot be reused

📘
Please refer to this page for more details on how to generate signature on BI-SNAP-based Core API flow.