Anti-Patterns to Avoid

TabaPay takes anti-pattern activity seriously. Follow the coding best practices in this section to help prevent any service interruptions.

Remember, anti-patterns will result in the following:

  • Your IP Addresses to be automatically blocked by our WAF and/or IDS/IPS.
  • TabaPay API may return either SC=429 or SC=503 or SC=423 for certain anti-patterns

IPs for Sandbox and Production Environments

It is recommended to use different IP addresses for Sandbox and Production environment to help ensure operational security and minimize the risk of anti-pattern activity.

Retrieve by ReferenceID

Please remember to use the Retrieve by ReferenceID only in those rare cases when the connection is lost and you do not have:

  • AccountID
  • TransactionID

You should not be using Retrieve by ReferenceID to determine if you already have created the account or you already submitted a transaction.

You should always use:

  • AccountID
  • TransactionID

that was returned on the Create.

4xx Errors

If you receive an HTTP Status Code 400 in the Production environment, it usually indicates that request validation is not being handled correctly before the request is sent to TabaPay. A 400 Bad Request response means that something in the API request is invalid.

Whenever possible, errors in customer-entered data should be identified before the API request is sent to TabaPay. An HTTP Status Code of 400 means that something in the request is bad. Your application should validate this data beforehand and provide the customer with an immediate response rather than using an API request to identify input errors.

Common examples include:

  • Card account number
  • Card expiration date
  • Amount

Validate customer-entered data on the customer's device to provide immediate feedback. Your backend should also validate request data before sending it to TabaPay.

📘

Production Certification

Complete the Production Certification Test before going live, including test cases for request validation and error handling. This helps identify invalid requests in Sandbox before they result in 400 responses in Production.

400 errors should be caught on the customer's device. Invalid customer-entered data should not need to travel from:

  • the customer's device
  • to your servers
  • to TabaPay
  • back to your servers with a 400 response
  • back to the customer's device with an error message

Depending on the application, use:

  • Web Browser: Client-side JavaScript to identify invalid input.
  • iOS: Swift or Objective-C to identify invalid input.
  • Android: Java or the application's client-side validation logic to identify invalid input.
  • Backend: Validate request data again on your servers before sending the API request to TabaPay.

For more information on Certification, refer to the Production page.

404 Errors

Using the API to tell you that a Resource is not found:

  • Retrieve Account
  • Retrieve Transaction

409 Errors

Using the API to tell you that you are reusing a ReferenceID:

  • Create Account
  • Create Transaction

Others

  • Repetitively retrying an API request even though you are getting a Status Code of 406
  • Creating multiple Accounts with the same Card Number
  • Repetitively retrying the same API request with the same parameters, such as ReferenceID (for Account or Transaction), KeyID, AccountID, TransactionID