Skip to main content

This page gives you the common knowledge about Tabby operating.

Status Page

Tabby Status Page offers live status, maintenance alerts and incident history reports for Tabby Services. Please subscribe to our Status Page to stay informed about all changes and maintenance works and be able to manage your sales according to it.

Security Protocol

TLS is an industry-standard protocol for encrypting network communications and establishing the identity of websites over the Internet. Tabby API supports TLS version 1.2 and higher. Additionally, we rely on HTTPS to ensure all data is transmitted securely. Strongly restricted cipher suites for compliance with the Payment Card Industry Data Security Standard. Enhances payment card data security:

Allowlist

Tabby uses several IP addresses when sending webhook requests and new IPs may be utilized as our systems scale and new resources are brought online. Please allow this list of IP addresses to prevent webhook calls from failing:

Data Format

Request and response data are formatted as JSON. The following data formats are used across all Tabby APIs:

Currency

We use the ISO 4217 standard for defining currencies.

Amount

Amounts are decimal strings in major currency units — e.g. one hundred dirhams is "100.00", not 10000. Currency codes follow the ISO 4217 standard. Tabby allows to send:
  • up to 2 decimals for AED and SAR.
Keep the totals consistent. payment.amount must equal the sum of your order lines: Σ (item.unit_price × quantity − item.discount_amount) + tax_amount + shipping_amount − order.discount_amount. The classic mistake is rounding twice — compute each line, round it once to the currency’s decimals, then sum the already-rounded values to produce amount. Deriving amount independently from the cart (or rounding the grand total differently than the lines) produces off-by-a-fils mismatches that fail validation and QA.

Phone

The following mobile phone formats are accepted, using the UAE +971 mask and phone number as an example:

Merchant Code

Merchant code is a unique store identifier under one brand and should be sent as a string value. Usually merchant_code represents a merchant country or a specific store within the country.

Dates

The ISO 8601 standard with combined Date and Time in UTC for all API dates. The exceptions to this are dob fields where we accept values in the YYYY-MM-DD format.

Locale

Operating in the GCC region, Tabby supports the English and Arabic languages and refers to the RFC 1766 standard.

String Length Validation

We are processing a maximum of 255 symbols in the “string” field.

Allowed characters in redirect URLs (“success”, “cancel”, “failure”)

  1. Latin letters (a-z, A-Z)
  2. Arabic letters (ء-ي)
  3. Digits (0-9)
  4. Special characters - \ | / : ;., + {}? & @ = # %

Rate limit

API rate limiting is implemented to maintain stable operations for Tabby services. If an excessive number of requests are sent in a short time, rate limiting may be applied to your requests. The response will include an HTTP status code 429 error when rate limiting is triggered. Rate limits are enforced per API Key and are measured on a per-operation basis. Operations are categorized into Create Session and Payment operations.
  • Live API Keys: The rate limit is 200 Create Session operations per 10 seconds, while other operations are limited to 100 requests per second.
  • Testing API Keys: The rate limit is 10 requests per 10 seconds for Create Session operations and 50 requests per second for other operations.
    Tabby doesn’t allow any Performance testing with the Production APIs involved. Kindly exclude Tabby method from checkout when executing load or stress testing.These Keys and IP addresses might be automatically limited by a firewall. Also such Test or Live API keys payments might be limited manually upon detection.

Authentication

To authenticate with Tabby you will use your API credentials and HTTP basic auth. These credentials consist of two elements:
  • Secret Key: Associated with your merchant account, this key is used to authorize requests to Tabby’s Checkout and Payments APIs. Send it as a Bearer token in the Authorization header with every request:
  • Public Key: Associated with your merchant account, this key is used for promo snippets, plans, and customization support.
Live API keys can be obtained:
  • from Tabby Merchant Dashboard for Self-Hosted plugin integration;
  • by contacting Tabby account manager after QA testing carried out by Tabby team is completed for Custom API integration.
If the Authorization header is missing, doesn’t use the Bearer scheme, or carries a wrong key, Tabby responds with 401 Not authorized — see API Error Codes.

Errors

Tabby APIs use HTTP status codes alongside error objects to handle errors. When an API call fails, Tabby responds with a 4xx/5xx status code and a JSON body containing status: “error”, an errorType value, and either a single error message or an errors array for field-level validation failures. The error value is a human-readable English message to aid in debugging. It is not meant to be displayable to end-users, nor to be machine-readable — log it to assist in debugging, but never parse it. Branch your handling on the HTTP status code and errorType instead. The full list of errors per endpoint, with example bodies and remediation, lives on the API Error Codes page.

Supported Browsers & Devices

We support all common-spread desktop and mobile browsers and mobile devices.
As part of our development process, we test among all major browsers and across different versions of browsers. However, we do not support browsers that no longer receive security updates. Please, contact us if you have an issue with Tabby Checkout on a specific browser so we can improve its support.

Browsers & Versions

Chrome, Firefox, Safari and Microsoft Edge are supported on all platforms for three years from the version release. We also test across different mobile platforms: iOS 12 and above and Android 7 and above.