Auto Transfer Integration Documentation
===
- [Bank Suppports](#Bank-Supports)
- [Deposit Method](#Deposit-Method)
- [Withdrawal Method](#Withdrawal-Method)
- [Account Listing Method](#Account-Listing-Method)
- [Bank Abbreviations](#Bank-Abbreviations)
# Bank Supports
Now we’re currently support the following banks
## Deposit & Withdrawal Options
| Bank | Account Type | Deposit | Withdrawal |
| ---- | ------------- | ------- | --------------- |
| GSB | Thai personal | ✅ Yes | ✅ Yes | |
| SCB | Company | ✅ Yes | ❌ Not supported |
| KTB | Company | ✅ Yes | ✅ Yes |
| TTB | Company | ✅ Yes | ✅ Yes |
# Deposit Method
Method for receiving a sucessfully deposited transaction from end-user via our **Auto Transfer** service.
## Data Receiver
### Sequence diagram
**Note:** The `triggered_url` and optional `triggered_apikey`, `check_ma_url` are defined together with your source system information. You can either provide these details to our support team, or configure them directly in the BAM configurations using the master account.
1. **Bank service** will notify **Auto Transfer service** when a new transaction from the payer is received.
2. **Auto Transfer service** then sends a `GET` request to your `check_ma_url` to determine if your service is currently under maintenance.
- If the response JSON body is `{ "is_ready": true }` **and** the HTTP status is in the **2xx range**,
the service will consider the Partner's service as **online** and proceed to step 3.
- Otherwise (i.e. response is not `{ "is_ready": true }` or the HTTP status is **not 2xx/3xx**),
the deposited transaction will be **skipped** and **not sent**.
3. When the Partner’s service is considered **online**,
Auto Transfer will send the transaction details to your `trigger_url` using a `POST` method ([described here](#JSON-body-payload)).
4. **In case of a callback failure** — for example, if the maintenance check fails (e.g. `is_ready = false` or invalid HTTP status),
or the `trigger_url` request returns an error (e.g. HTTP 4xx or 5xx),
you can manually retry the callback via the **"Bot Transaction History"** menu in the **BAM system**.
### Sample Triggered URL Request
[POST] `{triggered_url}`
#### Headers
| Key | Description |
| ------------ | ----------------------------------------------------------------- |
| content-type | application/json |
| apikey | `triggered_apikey`, If an API key is required for this connection |
#### JSON body payload
##### status key
| Key | Description |
| ---- | ------------------------------- |
| code | status code (only **200.41**) |
| type | status type (only **complete**) |
##### data key
| Key | Description |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| action | Action name, always be "deposit-auto-completed-transaction" |
| unique_hash | Received unique hash. No same hash with the same deposit transaction |
| session | Received session id (trace id) |
| transaction_id | Received transaction id |
| verified_from | Received method from Notification Gateway. Tells whether this transaction has verified from which method, "SMS", "APP", or "WEB" |
| payer_name* | Received payer name fetched from Bank ([with limitation](#Received-data-limitation)) |
| payer_bank* | Received payer bank fetched from Bank (May have an unpredictable format, [see here for the details](#Payer-Bank-Unpredictable-Format)) |
| payer_bank_abbr* | Received payer bank abbreviation if our system can recognize ([see bank abbreviations here](#Bank-Abbreviation))([with limitation](#Payer-Bank-Unpredictable-Format)) |
| payer_account* | Received payer account fetched from Bank ([with limitation](#Received-data-limitation)) |
| payee_bank | Received payee bank abbreviation ([see here](#Bank-Abbreviation)) |
| payee_bank_abbr | Received payee bank abbreviation ([see here](#Bank-Abbreviation)) |
| payee_account | Received payee account |
| amount | Received transferred balance |
| transferred_at | Transferred date and time fetched from Bank |
| is_internal_payer | Whether the payer account is internal (whitelisted) or not (true/false) |
##### Sample JSON body
```json
{
"status": {
"code": "200.41",
"type": "complete",
"message": "Transaction was completed."
},
"data": {
"action": "deposit-auto-complete-transaction",
"unique_hash": "532eaabd9574880dbf76b9b8cc00832c20a6ec113d682299550d7a6e0f345e25",
"session": "979b3d99-ceef-49ea-bb1f-5a6ee3433409",
"transaction_id": "79feaf6c-6efe-4baf-b6df-39678b0c6732",
"verified_from": "WEB",
"payer_name": null,
"payer_bank": "SCB",
"payer_bank_abbr": "SCB",
"payer_account": "1234567890",
"payee_bank": "TTB",
"payee_bank_abbr": "TTB",
"payee_account": "9999999999",
"amount": 10.00,
"transferred_at": "2022-06-15T18:00:00.000",
"is_internal_payer": false
}
}
```
## Received data limitation
Due to the limitation of fetching data from variety cases of destination bank. Unfortunately, it's impossible to get every data of each deposit transaction. Some will not get payer_name and different method can result different payer_account format. You need to do the rest to match them with your data by yourself.
The table below represents the received data seperated in 3 cases.
| payer bank -> payee bank | payee_account_type | payer_name | payer_account format |
| ------------------------ | ------------------ | ---------- | ------------------------------------------------ |
| ANY -> SCB | business | ✅ | x1234 |
| ANY -> GSB | personal thai | ✅ | 1234xxxx5678 (12 digits), 12xxxx3456 (10 digits) |
| ANY -> KTB | business | ❌ | 1234567890, 123456789012 |
| ANY -> TTB | business | ✅ | x1234 |
x123456 means the string 'x' followed by ANY known 6 numbers'.
'x' means unknown numbers with unknown digit length.
## Payer Bank Unpredictable Format
Typically, the source bank sends the bank name as an abbreviation (e.g., KTB) to the `payer_bank` field. However, some banks (i.e., GSB) send it as free text (e.g., ธนาคารกสิกรไทย). This makes it impossible for our system to verify which bank names are included, and there may be ambiguity in the names. This limitation prevents our system from converting the names to abbreviations.
Nevertheless, we provide convenience by including the `payer_bank_abbr` field. If we can convert the free text bank name to an abbreviation, the value will appear in this field. If we cannot convert it, we will send `null` instead.
### Examples
| `payer_bank` field | `payer_bank_abbr` field | Notes |
| ------------------ | ----------------------- | ------------------------------------------------------------------------------ |
| KTB | KTB | Directly sends abbreviation to payer_bank_abbr |
| ธนาคารกรุงไทย | KTB | Found a recognized bank, converted its name to abbreviation in payer_bank_abbr |
| ธนาคารไม่ทราบชื่อ | null | Found an unknown bank, payer_bank_abbr is set to null |
## Deposit Transaction Monitoring
You can monitor or verify past deposit transactions — particularly helpful if a callback was missed due to server downtime or maintenance. Simply access the bot transaction history via the BAM web service, where you can review all past activities and manually retry any failed callbacks if necessary.
## Send Slip API
This API provides three endpoints for verifying deposit transactions using payment slips in different formats. This is particularly useful when banks are slow to update their transaction statements, as it allows immediate verification by reading the QR code from the payment slip instead of waiting for the bank's automated notification system.
All endpoints verify the slip and automatically create a deposit transaction upon successful verification. The system guarantees that each slip can only be processed once, preventing duplicate transactions even if the same slip is submitted multiple times. Additionally, slips will not duplicate with transactions already received from bank statement notifications, and vice versa.
### Available Endpoints
1. **[POST]** `{ENDPOINT_URL}`/deposit/send_slip/qr_code - Submit QR code string directly
2. **[POST]** `{ENDPOINT_URL}`/deposit/send_slip/qr_image - Upload slip image file
3. **[POST]** `{ENDPOINT_URL}`/deposit/send_slip/qr_base64 - Submit base64-encoded slip image
---
## 1. Send Slip via QR Code String
**[POST]** `{ENDPOINT_URL}`/deposit/send_slip/qr_code
Submit the QR code string directly extracted from the payment slip.
### Request
#### Request headers
| Key | Description |
| ------------------ | ------------------------- |
| content-type | application/json |
| source-system-name | Your `SOURCE_SYSTEM_NAME` |
| apikey | Your `API_KEY` |
#### Request JSON body
| Key | Description | Type |
| ------------- | ----------------------------------------------------------- | ---- |
| session | Request session id (trace id), UUIDv4 is highly recommended | M |
| qr_code | QR code string from payment slip | M |
| payer_bank | Expected payer bank abbreviation (for validation) | M |
| payer_account | Expected payer account number (for validation) | M |
| amount | Expected amount (for validation) | O |
##### Sample JSON body (without amount validation)
```json
{
"session": "b497d650-ffbe-42ee-b5b0-ba6d240e9ea3",
"qr_code": "00020101021...",
"payer_bank": "KBANK",
"payer_account": "1234567890"
}
```
##### Sample JSON body (with amount validation)
```json
{
"session": "b497d650-ffbe-42ee-b5b0-ba6d240e9ea3",
"qr_code": "00020101021...",
"payer_bank": "KBANK",
"payer_account": "1234567890",
"amount": 100.50
}
```
### Response
#### status key
| Key | Description |
| ---------- | ----------------------------- |
| code | status code (with decimal) |
| type | status type |
| error_type | *only when error:* error type |
| message | status or error message |
#### data key
| Key | Description |
| -------------- | ---------------------------------------- |
| transaction_id | Created transaction id |
| amount | Transfer amount from slip |
| payee_bank | Payee bank abbreviation (normalized) |
| payee_account | Payee account number |
| transferred_at | Transfer date and time (ISO 8601 format) |
#### Sample 'success' JSON response
```json
{
"status": {
"code": "200.51",
"type": "success",
"message": "Successfully verified slip"
},
"data": {
"transaction_id": "79feaf6c-6efe-4baf-b6df-39678b0c6732",
"amount": 100.50,
"payee_bank": "SCB",
"payee_account": "1234567890",
"transferred_at": "2025-01-15T14:30:00+07:00"
}
}
```
#### Sample 'failure' JSON response - Slip Already Processed
```json
{
"status": {
"code": "422.51",
"type": "failure",
"error_type": "SlipAlreadyProcessed",
"message": "This QR code has already been processed"
},
"data": {
"transaction_id": "79feaf6c-6efe-4baf-b6df-39678b0c6732"
}
}
```
#### Sample 'failure' JSON response - Slip Expired
```json
{
"status": {
"code": "422.52",
"type": "failure",
"error_type": "SlipExpiredError",
"message": "Transfer time is too old: 2025-01-01T10:00:00+07:00 (more than 3 hours ago)"
}
}
```
#### Sample 'failure' JSON response - Amount Mismatch
```json
{
"status": {
"code": "422.57",
"type": "failure",
"error_type": "AmountMismatch",
"message": "Amount mismatch: expected 100.5, but slip shows 99.5"
}
}
```
#### Sample 'failure' JSON response - Invalid Slip Image
```json
{
"status": {
"code": "422.58",
"type": "failure",
"error_type": "InvalidSlipImage",
"message": "No QR code found in image. Please provide a slip image with visible QR code"
}
}
```
#### Sample 'failure' JSON response - Invalid QR Code
```json
{
"status": {
"code": "422.55",
"type": "failure",
"error_type": "SlipVerificationBadRequest",
"message": "Invalid QR Code"
}
}
```
#### Sample 'failure' JSON response - Slip Verification Failed
```json
{
"status": {
"code": "422.56",
"type": "failure",
"error_type": "SlipVerificationError",
"message": "Slip not found"
}
}
```
**Note about transaction_id in error responses:**
- When `transaction_id` is present: The QR code was already processed and a transaction was successfully created before. You can use this ID to reference the original transaction.
- When `transaction_id` is `null`: The system detected that another transaction with the exact same details (same sender, receiver, amount, and very similar timestamp) already exists. This prevents accidental duplicate transactions from being recorded in the system. This is a rare case and typically means the same payment was submitted multiple times within a very short time window.
### Status codes
| Code | Status type | Description |
| ------ | ----------- | ------------------------------------------------------------------------------------------------------ |
| 200.51 | success | Successfully verified slip and created transaction |
| 422.07 | failure | Request body format is not correct |
| 422.51 | failure | Slip Already Processed (QR code has already been used to create transaction) |
| 422.52 | failure | Slip Expired (slip is older than 3 hours) |
| 422.53 | failure | Payer Account Mismatch (payer account doesn't match request body) |
| 422.54 | failure | Payee Account Not Found (payee account not registered in system) |
| 422.55 | failure | Invalid QR Code (QR code is invalid) |
| 422.56 | failure | Slip Verification Failed (e.g. slip not found, slip is fraud) |
| 422.57 | failure | Amount Mismatch (amount doesn't match slip) |
| 422.58 | failure | Invalid Slip Image (cannot decode image or QR code not found in image) |
| 500.51 | failure | Slip Processing Internal Error (internal system error, please contact support team) |
| 500.52 | failure | Slip Verification Internal Error (internal system error, please contact support team) |
| 500.53 | failure | Slip Verification Server Error (slip checking server error, please try again, or contact support team) |
---
## 2. Send Slip via Image File
**[POST]** `{ENDPOINT_URL}`/deposit/send_slip/qr_image
Upload a payment slip image file. The system will automatically decode the QR code from the image.
### Request
#### Request headers
| Key | Description |
| ------------------ | ------------------------- |
| content-type | multipart/form-data |
| source-system-name | Your `SOURCE_SYSTEM_NAME` |
| apikey | Your `API_KEY` |
#### Request Form Data
| Key | Description | Type |
| ------------- | ----------------------------------------------------------- | ---- |
| session | Request session id (trace id), UUIDv4 is highly recommended | M |
| file | Payment slip image file (PNG, JPG, etc.) | M |
| payer_bank | Expected payer bank abbreviation (for validation) | M |
| payer_account | Expected payer account number (for validation) | M |
| amount | Expected amount (for validation) | O |
#### Sample cURL Request
```bash
curl -X POST "{ENDPOINT_URL}/deposit/send_slip/qr_image" \
-H "source-system-name: YOUR_SOURCE_SYSTEM_NAME" \
-H "apikey: YOUR_API_KEY" \
-F "session=b497d650-ffbe-42ee-b5b0-ba6d240e9ea3" \
-F "file=@/path/to/slip_image.jpg" \
-F "payer_bank=KBANK" \
-F "payer_account=1234567890" \
-F "amount=100.50"
```
### Response
Response format is identical to [Send Slip via QR Code String](#1-send-slip-via-qr-code-string).
---
## 3. Send Slip via Base64 Encoded Image
**[POST]** `{ENDPOINT_URL}`/deposit/send_slip/qr_base64
Submit a base64-encoded payment slip image. The system will decode the image and extract the QR code.
### Request
#### Request headers
| Key | Description |
| ------------------ | ------------------------- |
| content-type | application/json |
| source-system-name | Your `SOURCE_SYSTEM_NAME` |
| apikey | Your `API_KEY` |
#### Request JSON body
| Key | Description | Type |
| ------------- | ----------------------------------------------------------- | ---- |
| session | Request session id (trace id), UUIDv4 is highly recommended | M |
| qr_base64 | Base64-encoded payment slip image | M |
| payer_bank | Expected payer bank abbreviation (for validation) | M |
| payer_account | Expected payer account number (for validation) | M |
| amount | Expected amount (for validation) | O |
##### Sample JSON body (without amount validation)
```json
{
"session": "b497d650-ffbe-42ee-b5b0-ba6d240e9ea3",
"qr_base64": "iVBORw0KGgoAAAANSUhEUgAA...(base64 string)...CYII=",
"payer_bank": "KBANK",
"payer_account": "1234567890"
}
```
##### Sample JSON body (with amount validation)
```json
{
"session": "b497d650-ffbe-42ee-b5b0-ba6d240e9ea3",
"qr_base64": "iVBORw0KGgoAAAANSUhEUgAA...(base64 string)...CYII=",
"payer_bank": "KBANK",
"payer_account": "1234567890",
"amount": 100.50
}
```
### Response
Response format is identical to [Send Slip via QR Code String](#1-send-slip-via-qr-code-string).
---
# Withdrawal Method
Method for transferring balance to end-user via our **Auto Transfer** service.
## Withdrawal API
**[POST]** `{ENDPOINT_URL}`/withdraw/transfer
You can use this endpoint to transfer balances to any accounts with your registered account information we've received.
Every responses take time to transfer via Bank service. They can't response us immediately so we always result you in **processing** status (if not failed). You need to wait the real transfer result that will be sent to your **callback_url** in request JSON body.
Your system needs to remember the **transaction_id** that returned in this JSON response, when this transaction processing is done, we will sent this transaction to your callback_url with the same **transaction_id**, so you can recognize which transaction you received in callback is the transaction you've sent to this endpoint.
### Sequence diagram
### Request
#### Request headers
| Key | Description |
| ------------------ | ------------------------- |
| content-type | application/json |
| source-system-name | Your `SOURCE_SYSTEM_NAME` |
| apikey | Your `API_KEY` |
#### Request JSON body
| Key | Description | Type | Default |
| ------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------- | --------------------- |
| session | Request session id (trace id), UUIDv4 is highly recommended | M | |
| payer_bank | Payer bank abbreviation | M | |
| payer_account | Payer account number | M | |
| payee_bank | Payee bank abbreviation ([see here](#Bank-Abbreviation)) | M | |
| payee_account | Payee account number | M | |
| amount | Transfer balance | M | |
| callback_url | Callback URL that will be triggered when the processing was done | M |
| lang | The language of input for fetching bank API. Must be "en" or "th" | O | "en" |
| channel | Transfer channel ([see here](#Channel)) | O | depends on payer_bank |
| <!-- | service_method | The language of input for fetching bank API ([see here](#Service-Method)) | O | 1 --> |
##### Channel
We transfer money through two channels: 'app' and 'web'. Currently, KBANK supports only 'app'.
<!-- ##### Service Method
Each channel may offer various methods for transferring money. The SCB 'app' channel provides two methods, while others have only one method. -->
##### Sample JSON body
```json
{
"session": "b497d650-ffbe-42ee-b5b0-ba6d240e9ea3",
"payer_bank": "KBANK",
"payer_account": "9999999999",
"payee_bank": "SCB",
"payee_account": "1234567890",
"amount": 10,
"callback_url": "https://your.callback.url/"
}
```
Same session cannot be transferred more than one time if the prior response status was **success** or **ambiguous failure**
### Response
#### status key
| Key | Description |
| ---------- | -------------------------------- |
| code | status code (with decimal) |
| type | status type |
| error_type | *only when error:* error type |
| message | *only when error:* error message |
#### data key
| Key | Description |
| ----------------- | ----------------------------------------------------------------------- |
| transaction_id | Received transaction id |
| is_internal_payee | Whether the payee account is internal (whitelisted) or not (true/false) |
#### Sample 'processing' JSON response
```json
{
"status": {
"code": "202.00",
"type": "processing"
},
"data": {
"transaction_id": "54eee311-d7fd-48ca-a7d4-35fece08bcec",
"is_internal_payee": false
}
}
```
#### Sample 'failure' JSON response
```json
{
"status": {
"code": "422.01",
"type": "failure",
"error_type": "FlowException",
"message": "No suitable login accounts. The (source_system_name, payer_bank, account) should match in our database."
},
"data": {
"transaction_id": "54eee311-d7fd-48ca-a7d4-35fece08bcec"
}
}
```
### JSON Callback
When the transfer process is done (
or failure). You will receive the transfer result sent to your **callback_url** via request JSON body, with the same **transaction_id** you've sent to withdraw endpoint.
#### status key
| Key | Description |
| ---------- | -------------------------------- |
| code | status code (with decimal) |
| type | status type |
| error_type | *only when error:* error type |
| message | *only when error:* error message |
#### data key
| Key | Description |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| action | Action name, always be "withdraw-transfer" |
| transaction_id | Received transaction id |
| session | Received session id (trace id), should be the same as your request |
| bank_login | Received bank login |
| response_payee_name | Received payee name |
| response_payee_name_alt | Received alternate payee name |
| request_amount | Received requested amount |
| unique_amount | Received unique amount (random-generated value between request_amount and request_amount+1) ([see the details](#What-is-the-unique_amount)) |
| total_fee | Received total fee of transaction |
| transfer_ref_id | Bank reference id (use for getting transferred slip via https://checkslip.scb.co.th) |
| transfer_qr_code | Bank qr-code (use for getting transferred slip via KBANK App QR Code scanner) |
| via_service | Service that transfer executed (i.e. kbank_app ) |
| is_internal_payee | Whether the payee account is internal (whitelisted) or not (true/false) |
#### What is the unique_amount?
The unique_amount is the logical-generated actual balance we have transferred to the payee account instead of the amount which sent from Partner's request (requested_amount). The unique_amount will absolutely not transfer more than 1 baht from the requested_amount. The unique_amount will guaranteed the uniqueness of transfer amount during that time. This benefit is used for our service to trace back what transaction the decimal money came from.
For example, if Partner's service transfer 150 baht. We may transfer 150.07 baht in some situation.
#### Sample JSON 'success' callback
```json
{
"status": {
"code": "200.00",
"type": "success"
},
"data": {
"action": "withdraw-transfer",
"transaction_id": "54eee311-d7fd-48ca-a7d4-35fece08bcec",
"session": "b497d650-ffbe-42ee-b5b0-ba6d240e9ea3",
"bank_login": "test_login",
"response_payee_name": "เจน โด",
"response_payee_name_alt": "Jane Doe",
"request_amount": 10,
"unique_amount": 10.45,
"transfer_ref_id": "00000000aBcDeFgHiJkLmNoPq",
"transfer_qr_code": "004600060000010103014022500000000aBcDeFgHiJkLmNoPq5102TH91042AC5",
"via_service": "kbank_app",
"is_internal_payee": false
}
}
```
#### Sample JSON 'failure' callback
```json
{
"status": {
"code": "404.01",
"type": "failure",
"error_type": "ConnectionError",
"message": "HTTPConnectionPool(host='invalid', port=80): Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f88b003c890>: Failed to establish a new connection: [Errno -2] Name or service not known'))"
},
"data": {
"action": "withdraw-transfer",
"transaction_id": "54eee311-d7fd-48ca-a7d4-35fece08bcec",
"session": "b497d650-ffbe-42ee-b5b0-ba6d240e9ea3",
"bank_login": "test_login",
"request_amount": 10,
"unique_amount": 10.45,
"response_payee_name": null,
"response_payee_name_alt": null,
"transfer_ref_id": null,
"transfer_qr_code": null,
"via_service": "kbank_app",
"is_internal_payee": false
}
}
```
#### Sample JSON 'ambiguous_failure' callback ([see the detail here](#Ambiguous-failure-declaration))
```json
{
"status": {
"code": "422.21",
"type": "ambiguous_failure",
"error_type": "AmbiguousError",
"message": "Error after transferred!"
},
"data": {
"action": "withdraw-transfer",
"transaction_id": "ad1dfa3a-80ca-4995-aedd-689cf338d8d2",
"session": "b497d650-ffbe-42ee-b5b0-ba6d240e9ea3",
"bank_login": "test_login",
"request_amount": 10,
"unique_amount": 10.03,
"response_payee_name": null,
"response_payee_name_alt": null,
"transfer_ref_id": null,
"transfer_qr_code": null,
"via_service": "kbank_app",
"is_internal_payee": false
}
}
```
Some callback data were missing because they've failed before they've got the data.
## Withdrawal Transaction Monitoring
You can monitor or verify past transactions — especially useful when a callback was missed due to server downtime or maintenance. There are two ways to check:
### View bot transaction history via the BAM web service
You can also retry sending a callback if the original one failed.
### Use the fallback endpoint to fetch past transactions
Simply provide the `transaction_id`, which you can obtain from the BAM bot transaction history or the original withdrawal API response.
**[GET]** `{ENDPOINT_URL}`/withdraw/transfer/`{transaction_id}`
#### Request
##### Request headers
| Key | Description |
| ------------------ | ------------------------- |
| source-system-name | Your `SOURCE_SYSTEM_NAME` |
| apikey | Your `API_KEY` |
##### Request parameters
| Key | Description |
| -------------- | ----------------------- |
| transaction_id | Received transaction id |
##### Sample request
**[GET]** `{ENDPOINT_URL}`/withdraw/transfer/99a45631-ac80-49de-b71c-42bd16131c03
#### Response
Response body and sample responses is same as [Callback JSON body secion](#Callback-JSON-body), without "action" response data.
## Status chart
| Key | Status type | Description |
| -------------- | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 202.00 | processing | Processing |
| 200.00 | success | Success |
| 200.02 | already_success | Success, but in this case there was a previous success callback for the same transaction, with incomplete data at that time. Therefore, the additional information was sent in this callback. |
| 4xx.0x, 4xx.1x | failure | Client error / Bank error |
| 4xx.2x | ambiguous_failure | Ambiguous error (explain below) |
| 4xx.3x | failure | Serious error (e.g. sending the same session that was successfully transferred) |
| 503.xx | failure | Under maintenance |
| 5xx.xx | failure | Server error |
### Ambiguous failure declaration
- When status type is **ambiguous_failure** (or the response status code is 4xx.2x). It means that we don't know whether this transaction is success or fail. The reason is usually from Bank service, did not response to our service normally.
- The ambiguous failure may be automatically promoted to **success** and send to your **callback_url** again with the same transaction_id if our process can prove that would be transferred later. Usually takes around 0-15 minutes.
- If you still don't received any updated callback for a while. We recommend you to self-check by logging in your bank account and see the transfer log, see the **unique_amount** that transfer to another account. If it exists, that ambiguous failure transaction is successfully transferred. If not for a while, may be it was failed.
- If the time passed **after 12 hours**. All ambiguous failures would be automatically transformed to failure **without any acknowledges**.
### ⚠️ Caution
For KBANK Business, KTB Business, and TTB Business accounts, if the system fails to log in twice consecutively, or fails because of returning the suspension code, it will automatically disable the account to prevent the risk of exceeding the 3-time login failure limit by the bank.
Once disabled, you can reactivate the account via the BAM system.
It is recommended to wait 15–30 minutes after the issue occurs before attempting to reactivate.
# Account Listing Method
Retrieve a list of linked bank accounts used for auto transfer, along with their status and transfer type.
## Get Account List & Balance API
**[GET]** `{ENDPOINT_URL}`/get_account_balances
### Request
#### Request headers
| Key | Description |
| ------------------ | ------------------------- |
| content-type | application/json |
| source-system-name | Your `SOURCE_SYSTEM_NAME` |
| apikey | Your `API_KEY` |
#### Query String Parameters
| Name | Type | Description | Default |
| ------ | ---- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- |
| type | O | Transfer types: `DEPOSIT_AUTO_AND_WITHDRAW`, `DEPOSIT_AUTO`, `WITHDRAW` (multiple values allowed, separated by comma) | DEPOSIT_AUTO_AND_WITHDRAW, DEPOSIT_AUTO, WITHDRAW |
| status | O | Account status values: `ENABLED`, `DISABLED` (multiple values allowed, separated by comma) | ENABLED, DISABLED |
### Response
#### Data Key
| Key | Description |
| ----------------- | ------------------------------------------------ |
| `id` | Internal ID of the account |
| `bank_login` | Login identifier used by the system |
| `transfer_method` | Transfer type: e.g., `deposit_auto` |
| `full_name` | Full name of the account owner |
| `bank` | Bank name, e.g., `SCB`, `KBank`, `BBL` |
| `account_no` | Bank account number |
| `balance` | Current balance (can be null if unavailable) |
| `updated_at` | Last update timestamp |
| `is_disabled` | `true` if account is disabled, otherwise `false` |
a
#### Sample 'success' JSON response
```json
{
"status": {
"code": "200.00",
"type": "success"
},
"data": [
{
"id": 123,
"bank_login": "scb_1234567890_123",
"transfer_method": "deposit_auto",
"full_name": "สมชาย ชาญสมร",
"bank": "SCB",
"account_no": "1234567890",
"balance": 567.89,
"updated_at": "2025-01-20T12:34:56+07:00",
"is_disabled": false
},
{
"id": 135,
"bank_login": "scb_7777777777_135",
...
}
]
}
```
# Bank Abbreviations
| Bank Code | Bank Abbreviation | Bank Name |
| --------- | ----------------- | -------------------------------------------------- |
| 2 | BBL | Bangkok Bank |
| 4 | KBANK | Kasikorn Bank |
| 6 | KTB | Krung Thai Bank |
| 11 | TTB | TMBThanachart Bank |
| 14 | SCB | Siam Commercial Bank |
| 17 | CITI | Citibank |
| 18 | SMBC | Sumitomo Mitsui Banking Corporation |
| 20 | SCBT | Standard Chartered Bank (Thailand) |
| 22 | CIMB | CIMB Thai Bank |
| 24 | UOB | UOB Bank |
| 25 | BAY | Bank of Ayudhya |
| 29 | IOB | Indian Overseas Bank |
| 30 | GSB | Government Savings Bank |
| 31 | HSBC | HSBC Thailand |
| 32 | DB | Deutsche Bank |
| 33 | GHB | Government Housing Bank |
| 34 | BAAC | Bank for Agriculture and Agricultural Cooperatives |
| 35 | EXIM | Export–Import Bank of Thailand |
| 39 | MHCB | Mizuho Bank |
| 52 | BOC | Bank of China |
| 65 | TBANK | Thanachart Bank |
| 66 | ISBT | Islamic Bank of Thailand |
| 67 | TISCO | TISCO Bank |
| 69 | KKP | Kiatnakin Bank |
| 70 | ICBC | Industrial and Commercial Bank Of China (Thai) |
| 71 | TCRB | The Thai Credit Retail Bank |
| 73 | LHBANK | Land and House Bank |
| 79 | ANZ | ANZ Bank (Thailand) |
| 98 | SME | SME Bank |
| 99 | OTHER | Other bank |
Sign in with Wallet
Connect another wallet