zendit Error Messages

When you start integrating, you may encounter these common errors:

Basic 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:

Wallet 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

Catalog Errors

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.

Transaction Errors

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

The Transaction’s Log

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.