Bank transfers in Vietnam

Bank transfers in Vietnam is a payment method that allows customers to perform payments by using local bank transfers with banking applications, online banking, and payment terminals.

With the Bank transfers in Vietnam 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 Viet Nam
Payment currencies VND
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 (scenario 1)
Purchase (scenario 2)

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

In the Bank transfers in Vietnam payment method, purchase procedure follows one of the following scenarios:

  • Scenario 1—the customer is redirected to the provider service where they make a purchase
  • Scenario 2—the customer follows the payment instructions displayed on the checkout page or in your system (when performing the purchase by using Gate)

Ask your key account manager at Monetix which of the scenarios is relevant to you.

Restrictions

The number of purchases using the Bank transfers in Vietnam 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 VND. 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 VND. 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 VND. 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 VND. 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 VND. 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 VND. 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 VND. 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 VND.

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 VND.

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.