Hong Kong Payments

Overview:

Access the Fileactive API for efficient and secure payment processing in Hong Kong. The API supports various payment types, including ACH for automated clearing, FPS for faster payments, RTGS for real-time gross settlements, and CBFT for cross-border transactions. These capabilities allow businesses to handle both domestic and international payments with robust security measures, including OAuth 2.0 and JWT encryption.

Key seatures:

  • ACH: Automate clearing house payments for streamlined domestic transactions.

  • FPS: Fast and efficient payment processing for real-time settlements in Hong Kong.

  • RTGS: Real-time gross settlement for high-value transactions with immediate finality.

  • CBFT: Secure cross-border funds transfers to support international payment needs.

  • Secure authentication: Utilize OAuth 2.0 and JWT for secure access to all payment services.

  • Status tracking: Monitor payment statuses with dedicated endpoints for each payment type.

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.