Sometimes errors will happen. A user supplied the wrong phone number, didn’t fill in a required field, your wallet ran out of balance, a provider behind the scenes has an outage. When things don’t go as planned, we provide an error message on a failed transaction and a log on the transaction so you can pinpoint exactly where and why the problem happened.
When you start integrating, you may encounter these common errors:
Error Code | Error Description | Error Message | HTTP Response Code | Remedy | |
NOT_AUTHORIZED | Not authorized to access system | Your API key is incorrect or not authorized to access this system | 401 | Ensure you are sending your API Key in the headers as Authorization: Bearer Your API Key | |
FORBIDDEN | Forbidden from access | Your IP address is not recognized for access to this system | 403 | Check to make sure your IP address is whitelisted for the environment you are accessing | |
SYSTEM_UNAVAILABLE | System is currently unavailable | The system is currently unavailable to process your request. Please try again or check the system status page for more information. | 503 | How embarrasing, there’s a problem on our end but our engineers are working to get our clients moving again. |
In cases where there may be an issue with your wallet, maybe you forgot to top it up, we’ll return the following error:
Error Code | Error Description | Error Message | HTTP Response Code | Remedy | |
INSUFFICIENT_FUNDS | Insufficient funds to process transaction | Your wallet has insufficient funds to process this transaction | 200 | Recharge your wallet in the console then retry your transaction |
Sometimes it’s just not found or not available in the Catalog
Error Code | Error Description | Error Message | HTTP Response Code | Remedy | |
NOT_FOUND | Catalog Offer Not Found | The catalog item either doesn’t exist or is not enabled | 404 | Check to make sure the item exists and if so, make sure it’s enabled then try again | |
INVALID_REQUEST | Your request was not valid | Your request contained an invalid value. Please check the value of (list of fields containing invalid data) and try again. | 400 | Check to make sure you’re sending through correct values for parameter filters and try again |
And sometimes, there’s just a problem with the transaction.
Error Code | Error Description | Error Message | HTTP Response Code | Remedy | |
NOT_FOUND | Transaction Not Found | The transaction requested cannot be found | 404 | Make sure you’re using the correct transaction ID and try again | |
INVALID_REQUEST | Your request was not valid | Your request contained an invalid value. Please check the value of (list of fields containing invalid data) and try again. | 400 | Check to make sure you’re sending through correct values for parameter filters and try again | |
TRANSACTION_FAILED | Transaction Failed to Fulfill (24 hour timeout if using Queue and Retry) | Your transaction was unable to be fulfilled. Please try again. | 200 | The service provider was unable to fulfill the request for 24 hours, they may have an extended outage. | |
TRANSACTION_FAILED | Transaction Failed to Fulfill by the service provider | Your transaction was unable to be fulfilled: <A detailed message from the provider may be included > | 200 | The service provider was unable to fulfill the request, check the message for a description that may explain the problem |
Every zendit transaction contains a log so you can see the entire lifecycle of the transaction. An Example of the log on a transaction may look something like this:
... transaction details ...
"log": [
{
"dateTime": "2023-02-20T18:53:28.606Z",
"status": "PENDING",
"statusMessage": "Transaction created"
},
{
"dateTime": "2023-02-20T18:53:28.606Z",
"status": "AUTHORIZED",
"statusMessage": "Transaction authorized"
},
{
"dateTime": "2023-02-20T18:53:41.968Z",
"status": "IN_PROGRESS",
"statusMessage": "Transaction fulfilling"
},
{
"dateTime": "2023-02-20T18:53:41.968Z",
"status": "DONE",
"statusMessage": "Transaction completed"
}
]
... transaction details continued ...
Looking at this example of the log, we can see that the transaction was submitted for request, authorized against the wallet sucessfully processed through zendit for fulfillment and then completed. Using the transaction log you can get a deeper view of all the states that the transaction went through until it completed. In some cases if a temporary provider outage happens, you may get more IN_PROGRESS states to notify that the transaction is retrying after a problem at the fulfillment side.