TabaPay APIs are engineered for real-time transaction processing performance. TabaPay monitors for usage patterns that suggest usage of the API for non-transactional purposes. These usage behaviors can create unnecessary system load, especially at scale, and may trigger automated protections.
TabaPay APIs are:
Built (and optimized) for Transaction Processing
Not built (and optimized) for other processing tasks like:
- Creating and Managing Accounts
- Determining if an Account was previously created already or not
- Determining if a Transaction was previously submitted already or not
Expected API Usage
| API | Expected Usage |
|---|---|
| Retrieve ClientAPI | 0% |
| Create KeyAPI | 0 to 1 % |
| Retrieve KeyAPI | 0% |
| Delete KeyAPI | 0% |
| Query CardAPI | 39% |
| Create AccountAPI | 5% |
| Retrieve AccountAPI | 0 to 1 % |
| Update AccountAPI | 0 to 1 % |
| Delete AccountAPI | 0 to 1 % |
| Create TransactionAPI | 47% |
| Retrieve TransactionAPI | 0% |
| Delete TransactionAPI | 6% |
Cause for ConcernIf 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
1. Blind brute-force lookup
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%...!
2. Guessing ReferenceIDs
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
3. Using Create Account as Existence Check
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.
4. Retrieve Spamming
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
5. Query Card, Create Account, Delete Spamming
Similar to the 4. Retrieve Spamming, a similar client was also doing this behavior to check if an account was already added or not:
- Query Card
- Create Account
- Delete Account
Not once, but multiple times; and all of them were one right after the other one. This was identified as a client bug that caused the spamming.
So, what is the issue?
Unexpected or imbalance API usage causes the following:
1. Inactive Data
Causes TabaPay to hold a lot of inactive:
2. Duplicates
Causes TabaPay hold duplicate:
3. Unnecessary Repeat Requests
Causes TabaPay to processes a lot of useless requests:
Solutions
Clients should already be saving the data from the Response of the corresponding Create Call:
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.
Unnecessary RequestsIf this behavior occurred across all clients, with over 90% of requests serving no meaningful purpose, it would generate substantial non-critical traffic and place unnecessary strain on TabaPay systems at scale.