Vietnam Payments

Overview:

The Fileactive API provides secure ACH payment processing for Vietnam, allowing businesses to efficiently manage domestic transactions. With strong security features such as OAuth 2.0 and JWT encryption, the API ensures that payments are handled with the highest level of security and reliability.

Key features:

  • ACH: Automate clearing house payments for domestic transactions in Vietnam.

  • Secure authentication: Leverage OAuth 2.0 and JWT for secure payment processing.

  • Status tracking: Track payment statuses through dedicated API endpoints for complete visibility.

Rate limits and throttling:

By default the following rate limits are applied.

Type TPH (Transactions Per Hour) TPM (Transactions Per Minute) TPS (Transactions Per Second)
Authorisation 10 n/a 2
Payments n/a 30 2
Payment Enquiry n/a 90 2

Rate limiting algorithms:

For most use cases one of two algorithms is implemented for rate limiting.

Fixed Window The system uses a window size of n seconds (typically using human-friendly values, such as 60 or 3600 seconds) to track the fixed window algorithm rate. Each incoming request increments the counter for the window. It discards the request if the counter exceeds a threshold. The current timestamp floor typically defines the windows, so 12:00:03, with a 60-second window length, would be in the 12:00:00 window.

Sliding Window Sliding Window is a hybrid approach. Like the fixed window algorithm, we track a counter for each fixed window. Next, we account for a weighted value of the previous window’s request rate based on the current timestamp to smooth out bursts of traffic.

Sliding window example:

Given a limit of 100 transactions per hour.

  • Window 1 (13:00 - 14:00)
    Between 13:00 - 14:00, 80 requests are received. This is within the 100 tph limit, so all are allowed.

  • Window 2 (14:00 - 15:00)
    By 14:15, 20 requests are received. This is 25% (15 minutes) into window 2, so the weighted average would include 75% from the previous window.

    Request rate: 20 (all requests within window 2) + 60 (75% of requests from window 1) = 80 requests.
    The request rate is still within the 100 tph maximum.

    By 14:30, 75 requests have been received. This is 50% (30 minutes) into window 2, so the weighted average would include 50% from the previous window.

    Request rate: 75 (all requests within window 2) + 40 (50% weighted average from previous window) = 115 requests.
    This exceeds the 100 tph limit, so further requests would return an HTTP 429 (Too Many Requests) status code until the weighted request rate is below the agreed limit.

    By 14:45, no further requests have been made. This is 75% (45 minutes) through window 2.

    Request rate: 75 (current window) + 20 (25% weighted average from previous window) = 95 requests.
    As this is below the 100 tph limit, further requests will be accepted.