Bank transfers in Thailand

Bank transfers in Thailand is a payment method which allows you to accept payments from your customers. Customers make purchases by using bank transfers.

With the Bank transfers in Thailand payment method, you can accept payments from your customers by using Payment Page and Gate.

Download the logo in the vector format here.
Payment method type Bank transfers
Countries and regions Thailand
Payment currencies THB
Payment amount limits Contact your key account manager at Monetix for details. Also you can check the payment amount limits in your project by using Dashboard.
Payment processing time Contact your key account manager at Monetix for details.
Currency conversion On the Monetix side
Purchase
Payout
Stored credentials payments
Refund
Onboarding and access fee Contact your key account manager at Monetix for details.

Operations support

Interfaces
Payment Page Gate Dashboard
Purchase

You can check the payment amount limits in your project by using Dashboard. To check your payment amount limits, go to Dashboard, select the Projects section, and then click the Payment methods tab.

Payment scenario

When making a purchase, the customer is redirected to the provider service where they make a purchase.

Restrictions

The number of purchases using the Bank transfers in Thailand method for the same user (with the same customer_id) for specific amount can be limited. In other words, if the user initiates multiple identical purchases but completes none of them, the purchases are combined in a single series in which only the data for the first purchase is sent to the provider service. Once the last purchase in the series is completed and assigned the final status, the rest of the purchases in the series are declined and the platform sends callbacks with the 3613 response code. (For more information about the codes, see Operation statuses and response codes.)

Figure 1. Scenario 1: Multiple purchases with the same amount

By default, multiple purchases with the same amount are combined in a single series for 30 minutes after the user initiates the first purchase. Here an example of scenario of multiple purchases with the same amount:

  1. The user initiates the first purchase with amount of 500 THB. The purchase data are sent to the provider service, and then the payment platform receives the data for redirecting the user to the provider service. The user does not complete the purchase.
  2. The user initiates the second purchase with amount of 500 THB. The purchase data are not sent to the provider service, and the payment platform redirects the user to the provider service by using the data the payment platform have received when initiating the first purchase. The user again does not complete the purchase.
  3. The user initiates the third purchase with amount of 500 THB. The purchase data are not sent to the provider service, and the payment platform redirects the user to the provider service by using the data the payment platform received when initiating the first purchase. The user completes the purchase. The purchase is assigned the final status, and the first and the second purchases are automatically rejected.

Once all the purchases are assigned their final statuses, the corresponding callbacks are sent to the web service.

Figure 2. Scenario 2: Multiple purchases with different amount

Multiple purchases of the same user (with the same customer_id) with the amount which differs from the amount of any of the previous purchases do not create any series, instead each purchase spawns a new queue. Here an example of scenario of multiple purchases with different amounts:

  1. The user initiates the first purchase with amount of 500 THB. The purchase data are sent to the provider service, and then the payment platform receives the data for redirecting the user to the provider service. The user does not complete the first purchase.
  2. The user initiates the second purchase with amount of 600 THB. The purchase data are sent to the provider service, and then the payment platform receives the data for redirecting the user to the provider service. The user does not complete the second purchase.
  3. The user initiates the third purchase with amount of 700 THB. The purchase data are sent to the provider service, and then the payment platform receives the data for redirecting the user to the provider service. The user does not complete the third purchase.
  4. The user initiates the fourth purchase with amount of 800 THB. The purchase data are not sent to the provider service because of three-attempts limit. The payment platform receives the data for redirecting the user to the provider service which have been received when initiating the purchase for 700 THB.

Once the number of initiated purchases for different amounts (in which no amount is used twice) exceeds three, the user is redirected to the provider service with the redirection data of the last initiated purchase for unique amount. In our scenario, it is amount of 700 THB.

Thus, a new user session won't start, unless one of purchases from the series is successfully completed or the current session times out. The user is confined by the 30-minutes limit and three redirections to the provider service.

Monetix reserves the right to change the time-out period and the allowed number of attempts and will notify of any changes of these limits in a separate message.

This section provides detailed information about what you need to perform payments and how you can analyze the information on payments and operations.