บริการชำระค่าสินค้าและบริการ

บริการรับชำระค่าสินค้าและบริการ โดยแจ้งผลยืนยันการรับชำระเงินทันทีในรูปแบบ API

API Security

Digital Signature & Structure (JWT)

JSON Web Token (JWT) is a fundamental security component for Bangkok Bank APIs. In every API request to the Bangkok Bank API Gateway, inclusion of a JWT in the header is crucial. This token, resulting from payload encryption using the merchant's private key, undergoes verification by Bangkok Bank using the merchant-provided public key. This process ensures the validity of the request, augmenting our OAuth Authentication for dual-layer security against cyber threats such as man-in-the-middle attacks.

In general, JSON Web Tokens (JWTs) consist of three main components: the Token Header, the Token Payload, and the Signature. These components work together to encode information securely for transmission between parties.

Understanding how Bangkok Bank implements JWT is crucial for successful integration. The following steps outline what are required from a developer's perspective:

  1. Preparing the Public and Private Key pair
    • Before initiating any API requests, merchants need to generate a secure Public and Private Key pair. These keys will be crucial for the cryptographic operations involved in JWT processing.
  2. Preparing the Payload
    • As part of an API request, merchants construct a JSON payload containing essential information. This JSON payload serves as the basis for the JWT claim and carries details pertinent to the specific request.
    • This JSON payload is used as the JWT claim.
  3. Generating the JWT
    • The merchant uses their private key to sign the JWT. This involves encoding the header and payload, concatenating them, and then applying the signature algorithm using the private key.
    • The result is the JWT.
  4. Verifying the JWT
    • Bangkok Bank, upon receiving the API request, uses the merchant's public key to verify the JWT.
    • The signature is verified, and claims within the payload are extracted and validated.

Remark:

  • The signature token follows the standard JSON Web Token format RFC 7519

By following these steps, merchants can seamlessly integrate JWT authentication with Bangkok Bank's API, ensuring secure and reliable communication. It is recommended to securely store and manage the generated keys throughout the implementation process.

For more details on how to generate JWT for Digital Signature, please refer to our guide here.

 

API Overview & Specification

Using bill payment API, Bangkok Bank system will send the payment confirmation notification to merchant's system via provided notification endpoint during onboarding. This API provides merchant's system with near real-time status about the status of payment transactions.

In case that the bank is unable to send the payment confirmation due to connection lost or timeout, the bank will attempt to make retry (max 3 retries).

POST {MERCHANT_NOTIFICATION_URL}

Web Services: RESTful JSON

HTTP Method: POST

Character encoding: UTF-8

Content Type: application/json

Authorization: Basic Authentication. Format Basic (Base64Encode(username:password))

Request URL

  • PROD:
    {MERCHANT_NOTIFICATION_URL}

Request Headers

ParameterTypeSizeMandatoryDescriptionExample/Values
AuthorizationString100YBasic authentication

Token encode with Base64
String = {username}:{password}

Basic {token}
Basic c3FIOG9vSGV4VHoAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ
SignatureString YDigital Signature sign with JWT RSA256eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJqadEIuNEPkxgfD8fzh2TlfOKVXwNGVr_p9TTCGkJ672MbkSoJZqcQVi-Pm-IaVX7hE8…
Request-RefString50YNotify request reference

(Unique)
TXN20171120-0000023
Transmit-Date-TimeString29YResponse transmit date time with Time zone

Format yyyy-MM-dd’T’HH:mm:ss.SSS+|-hh:mm
2017-03-15T15:23:11.001+07:00

Request Body

ParameterTypeSizeMandatoryDescriptionExample/Values
dataObject    
data
.billerId
String15YTaxId and Suffix of the Payee123456789012345
data
.transDate
String10YTransaction date

Format yyyy-MM-dd
2022-10-18
data
.transTime
String8YTransaction time

Format HH:mm:ss
15:21:35
data
.termType
String2Y
Terminal Type (Channel):
  • 10: IVR
  • 20: KIOSK
  • 30: ATM
  • 40: EDC/POS
  • 50: COUNTER
  • 60: IBANKING
  • 70: CDM
  • 80: MBANKING
80
data
.amount
String16YPayment amount = 13 digits + . + 2 decimals

Ex. xxxx.xx
500.00
data
.reference1
String30YFirst Reference number of the transaction from Partner123456789
data
.reference2
String30NSecond Reference number of the transaction from Partner20171106151550
data
.reference3
String30NThird Reference number of the transaction from Partner5555555
data
.fromBank
String3YFrom bank code. Right-aligned.

Left-padded with zeros.
002
data
.fromBranch
String6NFrom branch code.0123
data
.fromName
String50NPayer name

Eng/Thai (UTF-8)
ITTest
data
.bankRef
String25NBBL reference2022101914273423001321408
data
.approvalCode
String6N 123456
data
.txnType
String1N
  • C: payment transaction
  • D: payment was cancelled/deleted
C
data
.retryFlag
String1Y
Notification retry flag:
  • Y: for retry/resend message
  • N: for original message
N

Request Body Example

{
    "data": {
        "billerId": "123456789012345",
        "fromBank": "002",
        "fromBranch": "0123",
        "amount": "5024.00",
        "approvalCode": "123456",
        "retryFlag": "N",
        "transTime": "14:51:32",
        "transDate": "2022-10-19",
        "termType": "80",
        "txnType": "C",
        "fromName": "ITTest",
        "reference1": "123456789",
        "reference2": "20171106151550",
        "reference3": "5555555",
        "bankRef": "2022101914273423001321408"
    }
}

Response Body

ParameterTypeSizeMandatoryDescriptionExample/Values
responseCodeString3YResponse Code000
responseMesgString50YResponse Messagesuccess

Response Body Example (Success)

{
    "responseCode": "000",
    "responseMesg": "Success"
}

Response Body Example (Failure)

{
    "responseMesg": "Invalid data",
    "responseCode": "211"
}
 

Response HTTP Status

HTTP StatusReason Phrase
200Success
400Bad Request
401Unauthorized
403Forbidden
400Bad Request
404Resource not found
429Too many requests
500Internal Error
503/504Service Unavailable