CRING! is SPE's Digital Payment & Transaction Platform that provides a unified platform for integrating digital payment and financial transaction services.

CRING! enables businesses, merchants, financial institutions, and partners to integrate various payment and transaction services through standardized APIs, while providing a centralized portal for operational and integration management.

CRING! supports both Payment Facilitator and Payment Aggregator business models, allowing partners to access services based on their business requirements and integration needs.

CRING! consists of two main components:

API

The CRING! API provides programmatic access to payment and financial transaction services.

Through the API, partners can integrate services such as:

• Virtual Account
• QRIS
• Fund Transfer
• Bank Account Validation
• RDL (Rekening Dana Lender)
• Other supported payment and transaction services

API integration is available through SNAP or Non-SNAP depending on the product and integration configuration.

Portal

The CRING! Portal provides a centralized interface for managing and monitoring the integration.

The portal may be used for:

• Client and application management
• API credential management
• Integration configuration
• Transaction monitoring
• Operational activities
• Reporting
• Audit trail

The Portal complements the API integration by providing visibility and operational capabilities without requiring all activities to be performed through APIs.

---

CRING! provides two API integration types:

Integration Type	Description
SNAP	API integration that follows the SNAP (Standar Nasional Open API Pembayaran) standard.
Non-SNAP	API integration that uses CRING! and/or banking partner-specific integration standards outside the SNAP standard.

The available integration type depends on the product and banking service being integrated.

A product may be available through SNAP, Non-SNAP, or both.

Important

Authentication, request headers, signature requirements, and other integration requirements may differ between SNAP and Non-SNAP APIs.

Always refer to the relevant product documentation to determine the applicable integration type and requirements.

CRING! supports two business models:

Payment Facilitator

In the Payment Facilitator model, CRING! provides payment and transaction services directly to clients through its platform and connected banking partners.

The client integrates with CRING! APIs according to the services required by its business.

Payment Aggregator

In the Payment Aggregator model, CRING! enables clients to provide payment and transaction capabilities to their own merchants, partners, or downstream users.

The integration model and available services may differ depending on the client's business configuration.

CRING! provides multiple payment and financial transaction services.

Service	Description	Integration
Virtual Account	Virtual Account services for payment collection.	SNAP / Non-SNAP
QRIS	QRIS payment services for digital payment collection.	SNAP / Non-SNAP
Fund Transfer	Fund transfer and disbursement services.	SNAP / Non-SNAP
Bank Account Validation	Account information validation and inquiry services.	Non-SNAP
RDL	Rekening Dana Lender services.	Non-SNAP

At a high level, the integration involves:

Partner / Client
      |
      | API Request
      v
    CRING! API
      |
      | Process & Route
      v
Banking / Financial Partner
      |
      | Response
      v
    CRING! API
      |
      | API Response
      v
Partner / Client

CRING! supports different authentication mechanisms depending on the API integration type and product.

CRING! provides two integration types:

• SNAP — APIs that follow the Standar Nasional Open API Pembayaran (SNAP) standard.
• Non-SNAP — APIs that use authentication and integration mechanisms defined by CRING! and/or the applicable banking partner outside the SNAP standard.

Because SNAP and Non-SNAP APIs may use different authentication mechanisms, credentials, headers, and security requirements, always refer to the authentication method specified for the product you are integrating.

Security Requirement

All CRING! API requests must be made over HTTPS. Requests sent over plain HTTP will be rejected.

Integration Type	Authentication Approach	Key Security Mechanism
SNAP	SNAP-compliant authentication	B2B Access Token, Request Signature, Timestamp, and SNAP headers
Non-SNAP	Product-specific authentication	OAuth 2.0

Important

SNAP and Non-SNAP APIs do not necessarily use the same authentication mechanism, credentials, headers, or security requirements.

Non-SNAP APIs use authentication mechanisms defined by CRING! and/or the applicable banking partner.

The authentication mechanism may differ between products and banking integrations.

For Non-SNAP APIs using OAuth 2.0, CRING! uses the Client Credentials Grant to obtain a short-lived access token.

The general authentication flow is:

Client
  |
  | client_id + client_secret
  v
CRING! Authentication Endpoint
  |
  | Access Token
  v
Client
  |
  | Authorization: Bearer <access_token>
  v
CRING! API

Step 1 — Obtain Client Credentials

Before accessing Non-SNAP APIs, you must obtain the credentials required for authentication from CRING! after completing the onboarding process.

The credentials consist of:

Credential	Description
client_id	Unique identifier assigned to the client.
client_secret	Confidential credential used to authenticate the client.

Client credentials can be obtained through the CRING! Portal based on the client's access permissions and configuration.

Security Notice

Keep your client_secret confidential. Do not expose it in source code, public repositories, client-side applications, or logs.

Step 2 — Request an Access Token

Send a POST request to the token endpoint.

POST {{baseUrl}}/auth/token
Host: {{baseUrl}}
Content-Type: application/json
Authorization: Basic <base64(client_id:client_secret)>

The Authorization header uses HTTP Basic Authentication.

The value is generated by encoding:

client_id:client_secret

using Base64.

JSON Body

{
  "grantType": "client_credentials"
}

Step 3 — Receive the Access Token

Example response:

{
  "responseCode": "20000",
  "responseMessage": "Successful",
  "accessToken": "eyJhbGciOi...",
  "tokenType": "Bearer",
  "expiresIn": 900,
  "additionalInfo": {}
}

Parameter	Type	Description
responseCode	String	Indicates the result of the token request.
responseMessage	String	Description of the response result.
accessToken	String	Access token used to authorize subsequent API requests.
tokenType	String	Token type used in the authorization header. Typically Bearer.
expiresIn	Integer	Token validity period in seconds.
additionalInfo	Object	Additional information returned by the authentication service, if applicable.

Step 4 — Use the Access Token

Include the access token in subsequent API requests:

Authorization: Bearer <access_token>

Access Token Expiration

The expiresIn field indicates the token validity period in seconds.

For example, expiresIn: 900 means the token is valid for 900 seconds (15 minutes).

When the access token expires, request a new access token using the configured client credentials.

Note

The Client Credentials Grant does not require a user session or refresh token. When the access token expires, the client obtains a new access token using its client_id and client_secret.

---

CRING! SNAP APIs follow the authentication requirements defined by SNAP (Standar Nasional Open API Pembayaran).

SNAP authentication uses asymmetric cryptography to authenticate the client and protect API requests.

The authentication process consists of:

1. Client credential and key pair registration
2. Generate B2B access token
3. Generate request signature
4. Use the B2B access token to access SNAP APIs

The general flow is:

Merchant / Client
      |
      | Client Key
      | Timestamp
      | Signature
      v
CRING! B2B Token Endpoint
      |
      | B2B Access Token
      v
Merchant / Client
      |
      | Bearer Token
      | SNAP Headers
      | Request Signature
      v
CRING! SNAP API

---

Before using SNAP API authentication, the merchant must register an RSA public key with CRING!.

The key pair consists of:

• Private Key — generated and securely stored by the merchant.
• Public Key — registered with CRING! through the CRING! Partner Portal.

The private key is never shared with CRING!.

The authentication process works as follows:

Merchant
  |
  | Generate RSA Key Pair
  |
  +---- Private Key
  |       |
  |       +---- Stored securely by Merchant
  |
  +---- Public Key
          |
          v
    CRING! Partner Portal
          |
          v
    CRING! stores Public Key

CRING! uses the registered public key to verify signatures generated using the merchant's private key.

This ensures that only a merchant holding the corresponding private key can generate a valid signature.

Key Requirements

Item	Requirement
Algorithm	RSA
Minimum Key Size	2048-bit
Private Key Format	PKCS#8 PEM
Signature Algorithm	SHA256withRSA
Public Key	Must be registered with CRING!
Private Key	Must be securely stored by the merchant

Security Notice

The private key must never be shared with CRING!, exposed in source code, committed to a repository, or included in application logs.

---

The B2B access token is required to authenticate API requests to CRING! SNAP APIs.

The SNAP token request is authenticated using an asymmetric signature.

Endpoint

POST {{baseUrl}}/v1.0/access-token/b2b

Headers

Header	Required	Value	Description
Content-Type	Yes	application/json	Request body format.
X-TIMESTAMP	Yes	yyyy-MM-ddTHH:mm:ssTZD	Current local time in ISO 8601 format.
X-CLIENT-KEY	Yes	<client_key>	Client key / merchant identifier registered with CRING!.
X-SIGNATURE	Yes	<base64_signature>	Asymmetric signature generated using SHA256withRSA.

Example Headers

Content-Type: application/json
X-TIMESTAMP: 2026-08-09T07:49:00+07:00
X-CLIENT-KEY: 962489e9-de5d-4eb7-92a4-b07d44d64bf5
X-SIGNATURE: <base64_signature>

Request Body

{
  "grantType": "client_credentials"
}

Request Parameter

Field	Type	Required	Description
grantType	String	Yes	OAuth 2.0 grant type. Must be client_credentials for B2B authentication.

---

The X-SIGNATURE header is generated using the merchant's private key.

CRING! uses SHA256withRSA, based on RSA PKCS#1 v1.5 with SHA-256.

Signing Formula

StringToSign = {ClientKey}|{Timestamp}

Signature = Base64(
    RSA_SHA256_Sign(
        StringToSign,
        PrivateKey
    )
)

For example:

ClientKey:
962489e9-de5d-4eb7-92a4-b07d44d64bf5

Timestamp:
2026-08-09T07:49:00+07:00

The resulting string to sign is:

962489e9-de5d-4eb7-92a4-b07d44d64bf5|2026-08-09T07:49:00+07:00

The string is then signed using the merchant's RSA private key and SHA-256.

The resulting binary signature is Base64 encoded and sent through the X-SIGNATURE header.

---

Step-by-step Signing Process

Step 1 — Generate the Timestamp

Generate the current local time using ISO 8601 format:

yyyy-MM-ddTHH:mm:ssTZD

Example:

2026-08-09T07:49:00+07:00

The timestamp must be current and within the allowed time window configured by CRING!.

Step 2 — Build the String to Sign

Concatenate the client key and timestamp using |:

{ClientKey}|{Timestamp}

Example:

962489e9-de5d-4eb7-92a4-b07d44d64bf5|2026-08-09T07:49:00+07:00

Step 3 — Sign Using RSA-SHA256

Sign the string using:

• RSA private key
• SHA-256
• RSA PKCS#1 v1.5

Step 4 — Encode the Signature

Encode the resulting binary signature using Base64.

The result becomes the value of:

X-SIGNATURE: <base64_signature>

POST {{baseUrl}}/auth/token
Host: {{baseUrl}}
Content-Type: application/json
X-TIMESTAMP: 2026-08-09T07:49:00+07:00
X-CLIENT-KEY: 962489e9-de5d-4eb7-92a4-b07d44d64bf5
X-SIGNATURE: <base64_signature>

{
  "grantType": "client_credentials"
}

When the request is successfully authenticated, CRING! returns a B2B access token.

Example Response

{
  "responseCode": "2007300",
  "responseMessage": "Successful",
  "accessToken": "eyJhbGciOi...",
  "tokenType": "Bearer",
  "expiresIn": "900",
  "additionalInfo": {}
}

After obtaining the B2B access token, include it as a Bearer token when calling CRING! SNAP APIs.

Authorization: Bearer <access_token>

SNAP API requests may also require additional headers depending on the applicable API.

Example:

Authorization: Bearer eyJhbGciOi...
X-TIMESTAMP: 2026-08-09T07:50:00+07:00
X-SIGNATURE: <generated_signature>
X-PARTNER-ID: <partner_id>
X-EXTERNAL-ID: 123456789
CHANNEL-ID: 95221
Content-Type: application/json

Important

The headers required for API requests after authentication may differ from the headers used to obtain the B2B access token.

Refer to the specific SNAP API reference for the complete request header requirements.

For SNAP transaction APIs, request signing may also be required.

The signature generation mechanism depends on the applicable SNAP API specification.

The API-specific documentation defines:

• Required headers
• String-to-sign format
• Signature algorithm
• Signing key
• Timestamp requirements
• Request body handling

Always use the signature rules defined by the relevant API.

The B2B access token is a short-lived credential.

The expiresIn field indicates the validity period in seconds.

For example:

{
  "expiresIn": "900"
}

means the token is valid for 900 seconds (15 minutes).

When the token expires, request a new B2B access token.

Important

The X-SIGNATURE must be freshly generated for every B2B access token request using the current X-TIMESTAMP.

To maintain secure communication:

• Always use HTTPS.
• Generate an RSA key pair with a minimum key size of 2048 bits.
• Keep the private key securely stored on the merchant side.
• Never send the private key to CRING!.
• Register the corresponding public key with CRING!.
• Generate a fresh X-SIGNATURE for every token request.
• Use the current X-TIMESTAMP.
• Ensure X-CLIENT-KEY matches the client key registered with CRING!.
• Do not expose private keys, signatures, or access tokens in logs.
• Request a new B2B access token when the current token expires.

Go

import (
    "crypto"
    "crypto/rand"
    "crypto/rsa"
    "crypto/sha256"
    "crypto/x509"
    "encoding/base64"
    "encoding/pem"
)

privateKeyPEM := `-----BEGIN PRIVATE KEY-----
YourPrivateKey
-----END PRIVATE KEY-----`

clientKey := "YourClientKey"
timestamp := "2026-08-09T07:49:00+07:00"

// 1. Build string to sign
dataToSign := clientKey + "|" + timestamp

// 2. Parse private key (PKCS#8)
block, _ := pem.Decode([]byte(privateKeyPEM))
if block == nil {
    panic("failed to decode PEM block")
}

privKeyInterface, err := x509.ParsePKCS8PrivateKey(block.Bytes)
if err != nil {
    panic(err)
}

privKey, ok := privKeyInterface.(*rsa.PrivateKey)
if !ok {
    panic("not an RSA private key")
}

// 3. Hash using SHA-256
hash := sha256.New()
hash.Write([]byte(dataToSign))
hashed := hash.Sum(nil)

// 4. Sign using RSA PKCS#1 v1.5
signature, err := rsa.SignPKCS1v15(
    rand.Reader,
    privKey,
    crypto.SHA256,
    hashed,
)
if err != nil {
    panic(err)
}

// 5. Encode signature to Base64
signatureBase64 := base64.StdEncoding.EncodeToString(signature)

println(signatureBase64)

PHP

<?php

$privateKey = '-----BEGIN PRIVATE KEY-----
YourPrivateKey
-----END PRIVATE KEY-----';

$clientKey = 'YourClientKey';
$timestamp = '2026-08-09T07:49:00+07:00';

// 1. Build string to sign
$dataToSign = $clientKey . '|' . $timestamp;

// 2. Sign using RSA-SHA256 (PKCS#1 v1.5)
$signatureBinary = '';

openssl_sign(
    $dataToSign,
    $signatureBinary,
    $privateKey,
    OPENSSL_ALGO_SHA256
);

// 3. Encode signature to Base64
$signatureBase64 = base64_encode($signatureBinary);

echo $signatureBase64;
?>

---

1. Generate RSA Key Pair
          |
          +---- Private Key → Merchant
          |
          +---- Public Key → Register in CRING! Portal
          |
          v
2. Generate X-TIMESTAMP
          |
          v
3. Build StringToSign
  {ClientKey}|{Timestamp}
          |
          v
4. Sign using Private Key
  SHA256withRSA
          |
          v
5. Base64 Encode Signature
          |
          v
6. Request B2B Access Token
  X-CLIENT-KEY
  X-TIMESTAMP
  X-SIGNATURE
          |
          v
7. CRING! Verifies Signature
  using Registered Public Key
          |
          v
8. B2B Access Token
          |
          v
9. Call SNAP API
  Authorization: Bearer <token>
          |
          v
10. CRING! SNAP API

Authentication-related errors may occur when:

• client_id is invalid.
• client_secret is invalid.
• The client is not authorized to access the API.
• The access token is missing.
• The access token is invalid.
• The access token has expired.
• The authentication format is invalid.
• The request signature is invalid.
• The timestamp is invalid or outside the allowed time window.

Refer to Error Handling for general error handling guidance and the relevant product documentation for product-specific response codes.

Regardless of the integration type, clients should:

• Always use HTTPS.
• Store client_secret securely.
• Never expose credentials in client-side applications.
• Never commit credentials to source code repositories.
• Never log client_secret, private keys, signing keys, or access tokens.
• Protect private keys and signing keys.
• Request a new access token when the current token expires.
• Generate request signatures according to the applicable SNAP specification.
• Use a unique X-EXTERNAL-ID for each request.
• Generate the appropriate X-TIMESTAMP for each request.
• Handle authentication errors without exposing sensitive credential information.

CRING! APIs use standard HTTP status codes and product-specific response codes to communicate the result of an API request.

The error handling mechanism may vary depending on the product, integration type, and banking partner. This section provides the general error handling principles applicable across CRING! APIs.

For product-specific response codes, refer to the Response Codes section within the relevant product documentation.

When processing a CRING! API response, clients should consider the following information:

1. HTTP Status Code
   Indicates the HTTP-level result of the request.

2. Response Code
   Provides more specific information about the API or business result.

3. Response Message
   Provides a human-readable description of the response.

4. Transaction Status
   For transaction-based APIs, indicates the current state of the transaction.

Important

A successful HTTP response does not always mean that the underlying transaction has been successfully completed.

For transaction APIs, clients should evaluate the transaction status in addition to the HTTP status and response code.

CRING! follows standard HTTP status codes.

HTTP Status	General Meaning
2xx	Request was successfully received or processed
4xx	Request or client-side condition could not be processed
5xx	Server or upstream service error

Common HTTP status codes include:

HTTP Status	Description
200	Request successfully processed
201	Resource successfully created
202	Request accepted and processing may still be in progress
400	Invalid request
401	Authentication failed or missing
403	Request is not permitted or transaction cannot be processed
404	Resource or transaction not found
409	Request conflicts with the current state
429	Too many requests
500	Internal server error
502	Upstream service error
503	Service temporarily unavailable
504	Gateway or upstream service timeout

The actual HTTP status codes supported may vary depending on the product and integration type.

In addition to the HTTP status code, CRING! APIs may return a response code that provides more specific information about the result.

Response codes may represent conditions such as:

• Successful request
• Request validation failure
• Authentication failure
• Authorization failure
• Resource not found
• Duplicate request
• Transaction failure
• Transaction pending
• Transaction expired
• Transaction limit exceeded
• Insufficient funds
• Timeout
• System error

The response code format and definitions may differ between products and integration types.

For example, different API integrations may use different response code structures.

Therefore, clients should always refer to the product-specific Response Codes documentation when implementing error handling.

The response structure may vary depending on the API product and integration type.

A response may contain information such as:

{
  "responseCode": "4000000",
  "responseMessage": "Invalid Request",
  "data": null
}

Some API may provide additional information:

{
  "responseCode": "4000000",
  "responseMessage": "Invalid Request",
  "errors": [
    {
      "field": "accountNumber",
      "message": "Invalid account number"
    }
  ]
}

This section describes the general conventions and recommended practices for integrating with CRING! APIs.

The guidelines apply across CRING! API products unless otherwise specified in the relevant product documentation.

HTTP Methods

CRING! APIs use standard HTTP methods according to the operation being performed.

Method	Usage
GET	Retrieve information
POST	Create or initiate a transaction
PUT	Update an existing resource
PATCH	Partially update an existing resource
DELETE	Remove or deactivate a resource

The applicable HTTP method is specified in each API endpoint reference.

API requests may require standard and product-specific headers.

Common headers may include:

Header	Description
Content-Type	Specifies the format of the request body
Accept	Specifies the expected response format
Authorization	Contains authentication information
X-Request-ID	Unique identifier for tracking an API request
X-External-ID	Client-provided external reference, where applicable

Additional headers may be required depending on the product and integration type.

For SNAP APIs, refer to the corresponding API documentation for SNAP-specific headers and requirements.

CRING! APIs generally use JSON as the request and response format.

Request

{
  "example": "value"
}

Response

{
  "responseCode": "2000000",
  "responseMessage": "Successful",
  "data": {}
}

CRING! provides a Payment Simulator as part of the Sandbox environment to help developers test and validate their API integrations without processing real financial transactions.

The Payment Simulator can be used to simulate transaction scenarios for CRING! products and APIs, including both SNAP and Non-SNAP integrations.

It allows developers to validate integration flows, test transaction scenarios, and verify system behavior before moving to the Production environment.

The Payment Simulator can be used to:

• Test API integration in the Sandbox environment.
• Simulate payment and transaction scenarios.
• Validate integration workflows.
• Verify transaction status handling.
• Test system behavior before Production implementation.

The Payment Simulator is available in the CRING! Sandbox environment.

It applies to APIs across CRING! products, whether the integration uses SNAP or Non-SNAP, based on the applicable product configuration.

No real financial transactions are processed through the simulator.

Note

The Payment Simulator is intended for Sandbox testing only. Simulation results do not represent real financial transactions.

Access the CRING! Payment Simulator through the following link:

Open Payment Simulator

Developers can use the simulator together with the corresponding API documentation to test their integration flow.

The videos below are provided as sample demonstrations of how the Payment Simulator can be used.

They are intended as examples and do not represent the complete functionality or all products supported by the Payment Simulator.

Virtual Account Simulation

Sample demonstration of a Virtual Account payment simulation:

QRIS Simulation

Sample demonstration of a QRIS payment simulation:

Note

The videos above are sample demonstrations only. Available simulation scenarios may vary depending on the product, API, and Sandbox configuration.

CRING Non-SNAP Authentication provides a standard mechanism for clients to authenticate and obtain access tokens before accessing protected CRING APIs.

The authentication process uses client credentials issued by CRING. Clients must provide valid credentials to obtain an access token, which is then used to authorize subsequent API requests.

The following table summarizes the response codes returned by the Authentication Non-SNAP service.

HTTP Code	Response Code	Response Message	Description
200	20000	Successful	The authentication request was processed successfully.
400	40000	General Request Failed	The request could not be processed due to a general request error, including message parsing failure.
400	40001	Invalid Field Format	One or more request fields contain an invalid format.
400	40002	Invalid Mandatory Field	A mandatory field is missing or contains an invalid value or format.
401	40100	Unauthorized	Authentication failed due to an invalid API credential, failed OAuth authentication, failed Client Secret verification, forbidden client access to the API, or an unknown client.
401	40101	Invalid Token	The provided authentication token is invalid or cannot be verified.
403	40304	Unauthorized Client	The specified Client Key could not be found or is not authorized to access the API.
422	42201	Invalid Route	The requested API route or endpoint is invalid or not supported.
500	50000	General Error	An unexpected system error occurred while processing the request.
500	50001	Internal Server Error	An internal error occurred within the authentication service.
504	50400	Timeout	A timeout occurred while processing the request or communicating with a required service.

The HTTP response codes can be grouped based on the result of the request:

• 2xx — Success
  The authentication request was processed successfully.

• 4xx — Client Error
  The request could not be processed due to invalid request data, authentication failure, unauthorized access, invalid client credentials, or an invalid route.

• 5xx — Server Error
  The request could not be completed due to an internal system error or timeout.

The Response Code provides a more specific identifier for the result of the authentication request.

For example:

20000 = Successful
40001 = Invalid Field Format
40101 = Invalid Token
50001 = Internal Server Error

CRING uses digital signature mechanisms to authenticate merchant requests in accordance with the SNAP (Standar Nasional Open API Pembayaran) standard. The signature is generated by the merchant using the credential provided or registered during onboarding and must be sent in the X-SIGNATURE request header.

CRING uses two different signature mechanisms to authenticate requests based on the type of API being accessed:

1. Signature Access Token used when requesting a SNAP Access Token B2B.
2. Signature Service used when calling SNAP Service APIs after obtaining an Access Token.

Both signatures are generated by the merchant locally and sent to CRING through the X-SIGNATURE request header.

Important: CRING does not provide a Generate Signature API. The merchant must generate the applicable signature before sending the request.

Signature	Used For	Algorithm	Credential
Signature Access Token	Access Token B2B request	RSA SHA-256	RSA Private Key
Signature Service	SNAP Service API request	HMAC-SHA512	Client Secret

Signature Access Token is used to authenticate requests for obtaining a SNAP Access Token B2B.

CRING uses asymmetric cryptography (RSA) with SHA-256, following the SNAP signing standard.

---

How It Works

The merchant owns and manages the RSA key pair:

Merchant                              CRING
  │                                     │
  ├── Generate RSA Key Pair             │
  │                                     │
  ├── Keep Private Key                  │
  │                                     │
  └── Register Public Key ────────────► │
                                        │
                                        └── Store Public Key

The Private Key must never be shared with CRING. CRING uses the registered Public Key to verify the signature received from the merchant.

---

Signing Process

Build the string to sign:

StringToSign = {ClientKey}|{Timestamp}

Example:

962489e9-de5d-4eb7-92a4-b07d44d64bf5|2025-01-01T23:59:59+07:00

Sign the string using RSA SHA-256 and the merchant's Private Key:

Signature = Base64(
    RSA_SHA256_Sign(
        StringToSign,
        PrivateKey
    )
)

The resulting Base64-encoded signature is sent through the X-SIGNATURE header.

X-SIGNATURE: {Base64Signature}

Required Data

Data	Description
ClientKey	Merchant identifier provided by CRING
Timestamp	Current timestamp in yyyy-MM-ddTHH:mm:ssTZD format
Private Key	Merchant RSA Private Key in PKCS#8 PEM format

The Timestamp used to generate the signature must be exactly the same as the value sent in the X-TIMESTAMP request header.

---

Signature Service is used to authenticate requests to SNAP Service APIs after the merchant has obtained the Access Token.

CRING uses symmetric signing with HMAC-SHA512. The merchant generates the signature using the Client Secret provided by CRING.

---

How It Works

The request information is processed in the following sequence:

HTTP Method
    +
Endpoint URL
    +
Request Body
    +
Timestamp
    │
    ▼
SHA-256 Request Body
    │
    ▼
Build String to Sign
    │
    ▼
HMAC-SHA512
    │
    ▼
Base64 Signature
    │
    ▼
X-SIGNATURE
    │
    ▼
CRING

---

Step 1 - Hash the Request Body

For requests with a request body, convert the JSON into a single-line representation and hash it using SHA-256.

Example request body:

{
    "partnerServiceId": "98130003",
    "startDate": "2024-08-03",
    "startTime": "14:56:11+07:00",
    "endDate": "2024-08-04",
    "endTime": "14:56:11+07:00"
}

Convert it into a single-line JSON string:

{"partnerServiceId": "98130003", "startDate": "2024-08-03", "startTime": "14:56:11+07:00", "endDate": "2024-08-04", "endTime": "14:56:11+07:00"}

Then calculate the SHA-256 hash and encode the result as lowercase hexadecimal:

069a81f985277e7aade3f503088cde559ba09ea0603e00a568aed10a3d8f1920

For requests without a body, use an empty string ("") as the LowercaseHashedRequestBody.

Step 2 - Build the String to Sign

Use the following pattern:

{HTTPMethod}:{EndpointUrl}:{LowercaseHashedRequestBody}:{Timestamp}

Example:

POST:/v1/transfer:069a81f985277e7aade3f503088cde559ba09ea0603e00a568aed10a3d8f1920:2025-01-01T23:59:59+07:00

Step 3 - Generate the Signature

Sign the resulting string using HMAC-SHA512 with the merchant's Client Secret:

Signature = Base64(
    HMAC-SHA512(
        StringToSign,
        ClientSecret
    )
)

Send the resulting Base64-encoded signature through the X-SIGNATURE header:

X-SIGNATURE: {Base64Signature}

The Timestamp used to generate the signature must be exactly the same as the value sent in the X-TIMESTAMP request header.

Required Data

Data	Description
HTTPMethod	HTTP method of the SNAP service request, such as POST or GET
EndpointUrl	Relative URL path of the SNAP service endpoint
LowercaseHashedRequestBody	SHA-256 hash of the request body in lowercase hexadecimal, or empty string when no body exists
Timestamp	Current timestamp, identical to the X-TIMESTAMP header
Client Secret	Secret credential provided by CRING

---

Use the signature mechanism based on the API being called:

                Merchant
                    │
                    ▼
            API being called?
                    │
          ┌─────────┴─────────┐
          │                   │
          ▼                   ▼
  Access Token B2B      SNAP Service API
          │                   │
          ▼                   ▼
Signature Access       Signature Service
      Token
          │                   │
    RSA SHA-256          HMAC-SHA512
          │                   │
          └─────────┬─────────┘
                    ▼
              X-SIGNATURE
                    │
                    ▼
                  CRING

Security Notes

• Never expose or share the RSA Private Key or Client Secret.
• Generate the signature on the merchant side before sending the request.
• Use the current timestamp to prevent replay attacks.
• Ensure the timestamp used during signing is identical to the X-TIMESTAMP request header.
• The X-SIGNATURE value must be Base64-encoded.

Before sending callback requests, CRING obtains an access token from the merchant's system. The merchant must provide a callback authentication endpoint that allows CRING to obtain a valid access token.

Unlike the Access Token B2B endpoint provided by CRING, this endpoint is provided and managed by the merchant.

POST {clientBaseUrl}/v1.0/access-token/b2b

Where {clientBaseUrl} is the base URL of the merchant's system.

Example:

POST https://merchant.example.com/v1.0/access-token/b2b

The endpoint is called by CRING before sending callback requests to the merchant.

CRING
  │
  │ 1. Request callback access token
  │    POST /v1.0/access-token/b2b
  │
  ▼
Merchant
  │
  │ 2. Verify X-CLIENT-KEY,
  │    X-TIMESTAMP and X-SIGNATURE
  │
  │ 3. Generate / return access token
  │
  ▼
CRING
  │
  │ 4. Use returned token
  │    Authorization: Bearer {accessToken}
  │
  ▼
Merchant Callback API

Header	Required	Description
Content-Type	Yes	Request body format. Must be application/json.
X-TIMESTAMP	Yes	Current timestamp in ISO 8601 format.
X-CLIENT-KEY	Yes	Client identifier registered by the merchant for callback authentication.
X-SIGNATURE	Yes	Base64-encoded asymmetric signature generated using the merchant's RSA Private Key.

Example:

Content-Type: application/json
X-TIMESTAMP: 2025-01-01T23:59:59+07:00
X-CLIENT-KEY: 962489e9-de5d-4eb7-92a4-b07ad44d64bf5
X-SIGNATURE: {Base64Signature}

The merchant must verify the signature before processing the authentication request.

The signing data is:

StringToSign = {ClientKey}|{Timestamp}

The signature is generated using:

Signature = Base64(
    RSA_SHA256_Sign(
        StringToSign,
        PrivateKey
    )
)

The X-TIMESTAMP and X-CLIENT-KEY values used for signature verification must match the values received in the request headers.

The request body uses application/json:

{
  "grantType": "client_credentials"
}

Request Fields

Field	Type	Required	Description
grantType	string	Yes	Must be client_credentials.

Upon successful authentication, the merchant returns an access token to CRING.

The access token will be used by CRING as a Bearer token when sending subsequent callback requests to the merchant.

Success Response

{
  "responseCode": "2007300",
  "responseMessage": "Successful",
  "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "tokenType": "Bearer",
  "expiresIn": "900",
  "additionalInfo": {}
}

Response Fields

Field	Type	Required	Description
responseCode	string	Yes	Response code indicating the result of the callback authentication request.
responseMessage	string	Yes	Description of the authentication request result.
accessToken	string	Yes	Access token issued by the merchant for authenticating subsequent callback requests from CRING.
tokenType	string	Yes	Type of access token. The value is Bearer.
expiresIn	string	Yes	Access token validity period in seconds.
additionalInfo	object	No	Additional information related to the authentication response.

After successfully obtaining the access token, CRING uses the token to authenticate callback requests to the merchant.

The token is sent using the Authorization header:

Authorization: Bearer {accessToken}

Example:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

• This endpoint is provided and managed by the merchant.
• {clientBaseUrl} is determined by the merchant.
• CRING calls this endpoint to obtain an access token before sending callback requests.
• The merchant must validate the X-SIGNATURE before issuing an access token.
• The returned access token must be valid for the period specified by expiresIn.
• The access token must be accepted as a Bearer token on subsequent callback requests.
• The merchant's RSA Private Key must never be shared with CRING.

This section lists the HTTP response codes returned by the SNAP Authentication service when processing Access Token B2B requests.

The response code indicates the result of the request, while the response message provides a more specific description of the outcome. All response codes in this section belong to Service Code 73.

HTTP Code	Response Message	Description	Service Code
200	Successful	Access token generated successfully.	73
400	Bad Request	Invalid request body or failed message parsing.	73
400	Invalid Field Format {fieldName}	One or more fields have an invalid format. {fieldName} identifies the field with the invalid format.	73
400	Invalid Mandatory Field {fieldName}	A required field is missing or contains an invalid value. {fieldName} identifies the affected mandatory field.	73
401	Unauthorized. [reason]	Client authentication failed due to an invalid Client ID, Client Secret, Signature, API Key, or unauthorized access. [reason] provides additional information about the authentication failure.	73
404	Partner Not Found	The specified partner or client identifier cannot be found.	73
429	Too Many Requests	The rate limit for access token requests has been exceeded.	73
500	General Error	An unexpected system error occurred while processing the request.	73
500	Internal Server Error	An internal failure occurred within the authentication service.	73
500	External Server Error	An external dependency, such as a database, HSM, or authentication service, failed while processing the request.	73
504	Timeout	A timeout occurred while communicating with the authentication service.	73

The HTTP response codes can be grouped based on the result of the request:

• 2xx — Success
  The request was processed successfully and the access token was generated.

• 4xx — Client Error
  The request could not be processed because of invalid request data, missing mandatory fields, authentication failure, an unknown partner, or exceeded rate limits.

• 5xx — Server Error
  The request could not be completed because of an unexpected internal failure, external dependency failure, or timeout.

---

Field Placeholder

Some response messages contain placeholders that provide additional context:

{fieldName}

Used to identify the request field that caused the validation error.

Example:

Invalid Field Format grantType

or:

Invalid Mandatory Field grantType

[reason]

Used to provide additional information about an authentication failure.

Example:

Unauthorized. Invalid Signature

is a payment collection service that enables businesses to receive payments through a unique Virtual Account number assigned to a customer or transaction.

Each payment is automatically identified and reconciled based on the Virtual Account number, eliminating the need for manual payment verification and simplifying the collection process.

CRING! provides Virtual Account Credit services through two business models: Payment Facilitator and Payment Aggregator, allowing clients to choose the integration model that best suits their business needs.

Key Benefits

• Standardized API across multiple banking partners.
• Automatic payment identification and reconciliation.
• Real-time payment notification through Callback.
• Single integration for multiple banking services.
• Support for both Payment Facilitator and Payment Aggregator business models.

Payment Facilitator

For Payment Facilitator clients, VA Credit is currently available through:

• Bank BNI
• Bank BTN
• Bank Permata

Payment Aggregator

For Payment Aggregator clients, VA Credit is currently available through:

• Bank BRI

Virtual Account Credit is available for both Payment Facilitator and Payment Aggregator clients. However, the supported banking partners differ by business model.

Business Model	Supported Banks
Payment Facilitator	Bank BNI, Bank BTN, Bank Permata
Payment Aggregator	Bank BRI

Important

Payment Facilitator and Payment Aggregator do not have the same banking partner coverage. The available bank depends on the client's business model and configuration.

Refer to the relevant API section for the specific bank and integration flow supported by your client configuration.

Virtual Account Credit API for Non-SNAP integration with Bank BNI.

This service allows merchants to create Virtual Account numbers issued by Bank BNI.

The following table summarizes the response codes you may encounter when using CRING's Non-SNAP APIs. Each code indicates the result of the request and provides information about the potential cause.

HTTP Code	Response Code	Response Message
200	20000	Successful
202	20200	Transaction Still in Progress
202	20201	Data Not Found
400	40000	General request failed error, including message parsing failure.
400	40001	Invalid Field Format
400	40002	Missing or invalid format on mandatory field
400	40003	Improper datetime field implementation
400	40004	Incomplete/Invalid Parameter(s)
400	40005	Billing Type Does Not Match Billing Amount
400	40006	Invalid Expiry Date/Time
400	40007	IDR Currency Cannot Have Billing Amount with Decimal Fraction
400	40008	VA Number Should Not Be Defined When Billing Number Is Set
400	40009	Invalid Billing Type
400	40010	Customer Name Cannot Be Used
400	40011	Invalid Content-Type Header
401	40100	General unauthorized error, including invalid API credentials, OAuth failure, Client Secret verification failure, forbidden client access, or unknown client.
401	40101	Invalid Token
401	40102	IP Address Not Allowed or Wrong Client ID
403	40300	Transaction Expired
403	40302	Exceeds Transaction Limit
403	40304	Invalid Permission(s)
403	40314	Insufficient Funds
404	40400	Service Not Found
404	40401	Transaction Not Found
404	40402	Invalid Billing Number
404	40403	Invalid VA Number
404	40404	Billing Not Found
404	40412	Invalid Bill/Virtual Account
404	40413	Invalid Amount
404	40414	The Bill Has Been Paid
404	40418	Inconsistent Request
404	40420	Amount Cannot Be Changed
404	40421	VA Number Is in Use
404	40422	Billing Number Is in Use
405	40500	Request Function Is Not Supported
409	40900	Conflict
409	40901	Duplicate Reference Number
409	40902	Duplicate Transaction
409	40903	Duplicate Billing ID
422	42203	The Given Data Was Invalid
429	42900	Too Many Requests
429	42901	Too Many Inquiry Requests per Hour
500	50000	General Error
500	50001	Internal Server Error
500	50002	Technical Failure
500	50003	Unexpected Error
500	50004	System Is Temporarily Offline
500	50005	Service Not Defined
500	50006	Failed to Send SMS Payment
500	50007	SMS Payment Can Only Be Used with Fixed Payment
500	50008	Billing Type Not Supported for This Client ID
504	50400	Timeout

Virtual Account Credit API for Non-SNAP integration across supported banks.

Supported Banks

• BTN
• Permata
• BRI
• BNI (New)

Code	Name
002	BANK RAKYAT INDONESIA (BRI)
009	BANK NEGARA INDONESIA (BNI)
013	BANK PERMATA
200	BANK TABUNGAN NEGARA (BTN)

The following table summarizes the response codes you may encounter when using CRING's Virtual Account Non-SNAP APIs Multi Bank. Each code indicates the result of the request and provides information about the potential cause.

Bank	Http Code	Service Code	Case Code	Response Code	Response Message
Bank BTN, Permata, BRI, BNI (New)	200	any	00	200XX00	Successful
Bank BTN, Permata, BRI, BNI (New)	400	any	00	400XX00	Bad Request / Parsing Error
Bank BTN, Permata, BRI, BNI (New)	400	any	01	400XX01	Invalid Field Format
Bank BTN, Permata, BRI, BNI (New)	400	any	02	400XX02	Invalid Mandatory Field
Bank BTN, BNI (New), BRI	401	any	00	401XX00	Unauthorized
Bank BTN, BNI (New), BRI	401	any	01	401XX01	Invalid Token (B2B)
Bank BTN, BNI (New), BRI	401	any	02	401XX02	Invalid Customer Token
Bank BTN, BNI (New), BRI	401	any	03	401XX03	Token Not Found (B2B)
Bank BTN, BNI (New), BRI	403	any	00	403XX00	Transaction Expired
Bank BTN, BNI (New), BRI	403	any	02	403XX02	Exceeds Transaction Amount Limit
Bank BTN, BNI (New), BRI	403	any	04	403XX04	Activity Count Limit Exceeded
Bank BTN, BNI (New), BRI	403	any	05	403XX05	Do Not Honor
Bank BTN, BNI (New), BRI	403	any	09	403XX09	Dormant Account
Bank BTN, BNI (New), BRI	403	any	10	403XX10	Need To Set Token Limit
Bank BTN, BNI (New), BRI	403	any	14	403XX14	Insufficient Funds
Bank BTN, Permata, BRI, BNI (New)	403	any	15	403XX15	Transaction Not Permitted. [reason]
Bank BTN, BNI (New), BRI	403	any	16	403XX16	Suspend Transaction
Bank BTN, BNI (New), BRI	403	any	17	403XX17	Token Limit Exceeded
Bank BTN, BNI (New), BRI	403	any	18	403XX18	Inactive Card/Account/Customer
Bank BTN, BNI (New), BRI	403	any	21	403XX21	Set Limit Not Allowed
Bank BTN, BNI (New), BRI	403	any	22	403XX22	Token Limit Invalid
Bank BTN, BNI (New), BRI	404	any	00	404XX00	Invalid Transaction Status
Bank BTN, BNI (New), BRI	404	any	01	404XX01	Transaction Not Found
Bank BTN, BNI (New), BRI	404	any	02	404XX02	Invalid Routing
Bank BTN, BNI (New), BRI	404	any	03	404XX03	Bank Not Supported By Switch
Bank BTN, BNI (New), BRI	404	any	04	404XX04	Transaction Canceled
Bank BTN, BNI (New), BRI	404	any	07	404XX07	Journey Not Found
Bank BTN, BNI (New), BRI	404	any	11	404XX11	Invalid Card/Account/Customer [info]/Virtual Account
Bank BTN, Permata, BRI, BNI (New)	404	any	12	404XX12	Invalid Bill/Virtual Account [Reason]
Bank BTN, Permata, BRI, BNI (New)	404	any	13	404XX13	Invalid Amount
Bank BTN, Permata, BRI, BNI (New)	404	any	14	404XX14	Paid Bill
Bank BTN, BNI (New), BRI	404	any	16	404XX16	Partner Not Found
Bank BTN, BNI (New), BRI	404	any	19	404XX19	Invalid Bill/Virtual Account
Bank BTN, BNI (New), BRI	409	any	00	409XX00	Conflict
Bank BTN, BNI (New), BRI	409	any	01	409XX01	Duplicate partnerReferenceNo
Bank BTN, BNI (New), BRI	500	any	00	500XX00	General Error
Bank BTN, BNI (New), BRI	500	any	01	500XX01	Internal Server Error
Bank BTN, BNI (New), BRI	500	any	02	500XX02	External Server Error

Virtual Account Credit API for SNAP integration across supported banks.

Supported Banks

• BTN
• Permata
• BRI
• BNI

Supported Services

The following services are supported for Virtual Account Credit integration.

Service	Service Code
Payment Notification Virtual Account Credit	25
Inquiry Status Virtual Account Credit	26
Create Virtual Account Credit	27
Update Virtual Account Credit	28
Inquiry Virtual Account Credit	30
Delete Virtual Account Credit	31

Type of Virtual Account

Code	Type	Banks	Usage
C	Closed Payment	BTN, Permata, BNI, BRI	va-closed-payment- Fixed payment with exact amount, paid once.
O	Open Payment	BTN, BRI, BNI	va-open-payment - Any amount, paid once.
I	Partial Payment	BTN	va-partial-payment - Multiple payments allowed until fully paid.

Code	Name
002	BANK RAKYAT INDONESIA (BRI)
009	BANK NEGARA INDONESIA (BNI)
013	BANK PERMATA
200	BANK TABUNGAN NEGARA (BTN)

The following table summarizes the response codes you may encounter when using CRING's Virtual Account SNAP APIs. Each code indicates the result of the request and provides information about the potential cause.

HTTP Code	Response Code	Response Message	Description	Service
200	2002500	Successful	Request processed successfully.	25
200	2002600	Successful	Request processed successfully.	26
200	2002700	Successful	Request processed successfully.	27
200	2002800	Successful	Request processed successfully.	28
200	2003000	Successful	Request processed successfully.	30
200	2003100	Successful	Request processed successfully.	31
202	2022500	Request In Progress	Request is still being processed asynchronously.	25
202	2022600	Request In Progress	Request is still being processed asynchronously.	26
202	2022700	Request In Progress	Request is still being processed asynchronously.	27
202	2022800	Request In Progress	Request is still being processed asynchronously.	28
202	2023000	Request In Progress	Request is still being processed asynchronously.	30
202	2023100	Request In Progress	Request is still being processed asynchronously.	31
400	4002500	Bad Request	Invalid request or failed message parsing.	All
400	4002501	Invalid Field Format {fieldName}	One or more fields have an invalid format.	All
400	4002502	Invalid Mandatory Field {fieldName}	Required field is missing or invalid.	All
401	4012500	Unauthorized	Authentication or authorization failed.	All
403	4032500	Transaction Expired	The transaction has expired.	All
403	4032501	Activity Count Limit Exceeded	Request exceeds the allowed transaction frequency.	All
403	4032502	Merchant Blacklisted	Merchant is suspended or not allowed to access the API.	All
403	4032503	Merchant Limit Exceed	Merchant transaction limit has been exceeded.	25, 27
404	4042500	Invalid Transaction Status	The transaction status is invalid for the requested operation.	26, 28, 31
404	4042501	Transaction Not Found	Transaction cannot be found.	26, 28, 31
404	4042502	Invalid Merchant	Merchant does not exist or is inactive.	27, 28, 30, 31
404	4042503	Invalid Virtual Account	Virtual Account number is invalid, suspended, blocked, or expired.	All
404	4042504	Invalid Amount	Payment amount does not match the expected amount.	25, 27
404	4042505	Paid Bill	The Virtual Account has already been paid.	25
404	4042506	Inconsistent Request	Request parameters are inconsistent with the existing transaction.	27, 28
405	4052500	Requested Function Is Not Supported	Requested operation is not supported.	All
409	4092500	Conflict	Duplicate X-EXTERNAL-ID within the same day.	All
409	4092501	Duplicate Partner Reference Number	The transaction with the same partnerReferenceNo has already been processed successfully.	27
429	4292500	Too Many Requests	Rate limit exceeded.	All
500	5002500	General Error	Unexpected system error.	All
500	5002501	Internal Server Error	Internal server failure occurred.	All
500	5002502	External Server Error	Downstream service or external system failure.	All
504	5042500	Timeout	Timeout occurred while communicating with the external system.	All