Anti-Patterns to Avoid

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:

• 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