This page gives you the common knowledge about Tabby operating.
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.
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:
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:
Request and response data are formatted as JSON. The following data formats are used across all Tabby APIs:
We use the ISO 4217 standard for defining currencies.
We expect amounts in minor units according to the ISO 4217 standard. That means they are formatted in the smallest unit of currency.
Tabby allows to send:
The following mobile phone formats are accepted, using the UAE +971 mask and phone number as an example:
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.
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.
Operating in the GCC region, Tabby supports the English and Arabic languages and refers to the RFC 1766 standard.
We are processing a maximum of 255 symbols in the “string” field.
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.
To authenticate with Tabby you will use your API credentials and HTTP basic auth.
These credentials consist of two elements:
Live API keys can be obtained:
If the credentials are missing or wrong, Tabby will respond with 401 Not authorized
. More information on HTTP Basic auth can be found in the API Reference article.
Tabby APIs use HTTP status codes alongside the error objects to handle errors. When an API call fails, Tabby will respond with a 4xx status code and a response body containing an error object with the error code, an array of error messages and a unique correlation ID to identify the request.
The error object contains an error_code
and an errorType
value (or errors
).
The error
object is a human-readable English message to aid in debugging. The message
is not meant to be displayable to end-users, nor it is meant to be machine-readable. It should be seen as something that the client would log to assist in debugging, but it’s never meant to be in any way parsed by the client.
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.
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.
This page gives you the common knowledge about Tabby operating.
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.
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:
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:
Request and response data are formatted as JSON. The following data formats are used across all Tabby APIs:
We use the ISO 4217 standard for defining currencies.
We expect amounts in minor units according to the ISO 4217 standard. That means they are formatted in the smallest unit of currency.
Tabby allows to send:
The following mobile phone formats are accepted, using the UAE +971 mask and phone number as an example:
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.
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.
Operating in the GCC region, Tabby supports the English and Arabic languages and refers to the RFC 1766 standard.
We are processing a maximum of 255 symbols in the “string” field.
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.
To authenticate with Tabby you will use your API credentials and HTTP basic auth.
These credentials consist of two elements:
Live API keys can be obtained:
If the credentials are missing or wrong, Tabby will respond with 401 Not authorized
. More information on HTTP Basic auth can be found in the API Reference article.
Tabby APIs use HTTP status codes alongside the error objects to handle errors. When an API call fails, Tabby will respond with a 4xx status code and a response body containing an error object with the error code, an array of error messages and a unique correlation ID to identify the request.
The error object contains an error_code
and an errorType
value (or errors
).
The error
object is a human-readable English message to aid in debugging. The message
is not meant to be displayable to end-users, nor it is meant to be machine-readable. It should be seen as something that the client would log to assist in debugging, but it’s never meant to be in any way parsed by the client.
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.
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.