At TabaPay, we take anti-pattern activity seriously. We strongly urge you to follow our coding best practices highlighted in this section so you can avoid any service interruption.

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

So what are some Anti-Patterns we have seen from Clients while using the TabaPay API?

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 are getting a HTTP Status Code of 400 on the Production Environment, that usually means you are not handling these errors correctly on your end. We strongly recommend completing the Production Certification Test in its entirety, specifically the portion where we recommend integrating your application with our API calls.

All errors with a HTTP Status Code of 400 should have been caught before the API request is sent to us. We shouldn't have to return back a HTTP Status Code of 400. A HTTP Status Code of 400 means that something in your request is bad: Bad Request. You should not use us (API Request) to check for Customer entered data errors.

For example:

Card Account Number
Card Expiration Date
Amount

All of the above examples should have been caught on the client side (Customer's Device). It shouldn't need to travel from:

the Customer's Device
to your Servers
to our Servers
negative response (400) back to your Servers
and then finally some error message back to the Customer's Device
just to inform the Customer that the Customer entered a bad:
Card Account Number
or Card Expiration Date
or Amount

We believe the proper way of handling errors is:

Immediate
Interactive
Responsive
and that means:

(1) if the Customer is on a Web Browser, then there should be:

JavaScript code
to catch obvious errors;
(2) if the Customer is on a Mobile Device, then there should be:
Swift (or Objective-C) code on iOS
or Java code on Android
to catch obvious errors.

Even if an error gets past the code on the Customer's Device and goes up to your Servers, your BackEnd Code on your Servers should also catch these obvious errors. That is two layers of code that should have caught the error, so that is why we say:

We should never have to return back a SC=400 in Production...
That is why you should test on the Sandbox Environment and pass the Certification Test completely.

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