Expected Usage

❗️

TabaPay APIs are:

• Built (and optimized) for Transaction Processing
  • Not built (and optimized) for other processing tasks like: (1) Creating and Managing Accounts (2) Determining if an Account was previously created already or not (3) Determining if a Transaction was previously submitted already or not

Expected API Usage

📘

Cause for Concern

If you are outside these expected usage, your ClientID may be detected to be performing Anti-Pattern behavior and is subject to our Anti-Pattern Behavior Detection.

While our anti-pattern behavior detection finds bugs that we do not recommend, in order to protect our TabaPay Systems from a runaway bug, we will have to stop any non-recommended integration aspects before they cause any issue or irretrievable damage. This means:

• Returning SC=429, Too many Requests
• Returning SC=503, Forbidden, Permissions
• Returning SC=423, Locked
• Removing IPs whitelisted for the Client

Instances of Bad Practices

A client doesn't know what transactions they sent to us, so they were sending a Retrieve Transaction with ReferenceID for all the possible Transactions they have Created even those not processed by us, so >99% of all this traffic was a Retrieve Transaction failure with SC=404, Not Found. That was >99%...

A client doesn't know what transactions they sent to us, so they were sending us 10 calls to Retrieve Transaction with ReferenceID (not actual but just an example) of:

• 000001-0
• 000001-1
• 000001-2
• 000001-3
• 000001-4
• 000001-5
• 000001-6
• 000001-7
• 000001-8
• 000001-9
  and looking for which one returned a 200 or 404. So >25% of all their traffic was this Retrieve Transaction call.

What was incorrect?

• Doing a Retrieve by ReferenceID
• But the biggest concern was them not knowing if they sent the transaction or not

A client was using us to determine if an account was already added or not, so they were sending us a Create Account and expecting:

• 200 - new
• 409 - duplicate
  So >10% of all their traffic was this Create Account call that was returning 409.

Another client was using us to determine if an account was already added or not, so they were sending us a Retrieve Account with ReferenceID (not actual but just an example) of:

• 123v1
• 123v1
• 123v2
• 234v1
• 234v1
• 234v1
  So >90% of all their traffic was this Retrieve Account call.

What was incorrect?

• Over 90%
• Doing a Retrieve by ReferenceID
• Doing a Retrieve with the same ReferenceID multiple times

This same client was also doing this behavior:

• Query Card
• Create Account
• Delete Account
  Not once, but multiple times; and all of them were one right after the other one. It was some sort of a bug.

So, what is the issue?

We are also holding a lot of inactive:

• Accounts
• Keys
  and we are holding a lot of duplicate:
• Accounts
  and we are processing a lot of useless requests:
• Retrieve Account
• Retrieve Transaction
  that the Clients should already be saving the data from the Response of the corresponding Create Call:
• Create Account
• Create Transaction
  From a Real Life Example described above:

Just think if all the clients where sending us requests where >90% of all these requests were basically useless.

🚧

And the lesson is...

From a Real Life Example described above:

Just think if all the clients where sending us requests where >90% of all these requests were basically pointless.