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?
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:
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:
that was returned on the Create.
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.
- Card Account Number
- Card Expiration Date
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:
and that means:
(1) if the Customer is on a Web Browser, then there should be:
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.
Using the API to tell you that a Resource is not found:
- Retrieve Account
- Retrieve Transaction
Using the API to tell you that you are reusing a ReferenceID:
- Create Account
- Create Transaction
- 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