Our cloud-based Prepaid as a Service platform is now even more accessible with our reliable and efficient REST API. Our API provides seamless access to catalogs, balance information, and transactions for our:

• International Mobile Top Up Products
• International Mobile Bundles
• Digital Gift Cards
• Utility Payments
• eSIM

Our platform is built with industry-standard security protocols and is designed to integrate seamlessly with your existing systems. We are committed to providing top-notch support, so please don't hesitate to reach out to our experienced zendit support team with any questions or support needs.

As a supplement to this API guide, head over to Zendit University to understand the features of the system, how transaction flows work and how to get details from the catalog for your integration.

Testing and development before going live with your product or service is crucial. That’s why we provide easy access to both our test bed and production environments through our gateway.

When you register for zendit, you’ll be provided with a test mode API key to use for simulated transactions. These transactions will not transfer real value, but will deduct from your test bed wallet. No credit card is required for this environment, and you can manage your wallet balance through our administration console.

When you’re ready to switch to production mode and start processing real transactions, you’ll need to fund your prepay wallet with real value. This will allow you to process transactions using your production key.

For more information on using our testbed environment to simulate different responses, refer to our comprehensive test mode environment documentation.

Please don’t hesitate to contact our support team if you have any questions or need assistance.

When you sign up for our platform, you’ll be given access to your test mode key for testing your integration with our API. To send requests to an API endpoint, please use the Authentication header and include your API key as follows:

Authorization: Bearer YOUR_API_KEY

This will authenticate your requests and allow our API to process them securely. If you’re ready to switch to production mode and start processing real transactions, you’ll need to use your production key instead.

For more information about our security, refer to our security guide.

Transparency and visibility are most important when it comes to processing transactions. That’s why we process transactions asynchronously and provide detailed status updates throughout the process.

When you send a transaction through our platform, we first validate the parameters of the transaction and then return the transaction ID in the response, along with any error messages if the transaction cannot be processed. From there, the transaction enters the zendit ecosystem and begins to move through our system.

To check on the status of your transaction, you can periodically poll the transaction using the transaction ID. Our system provides detailed updates on the transaction’s status as it moves through the system, including updates on receipt, wallet authorization, offer fulfillment, and completion.

Once the transaction is complete, you’ll receive a final status update that reports whether it was successful or encountered any errors during processing. Additionally, each transaction contains a history log that shows all status updates throughout the transaction process, providing you with a comprehensive view of the transaction’s journey through our platform.

To understand more about how to work with transactions, refer to our transaction guide.

Transaction ID

Providing our users with maximum flexibility when it comes to tracking their transactions is important. That’s why we don’t automatically generate transaction IDs – instead, you can supply any alphanumeric string of your choosing (such as an autonumber or a GUID) to track your transaction in our system.

To ensure that your transaction is processed correctly, you must supply the ID you will use to track the transaction status with each transaction request. Please note that transaction IDs are unique per zendit account and environment, so you can use the same transaction ID in both your test environment and production environment (once per environment).

If you’re using an autonumber scheme and have test and production environments, there’s no need to worry about collisions of IDs between the two environments. We understand the importance of keeping your test and production environments separate, and our system is designed to handle this seamlessly.

We strive to ensure that your transactions are processed reliably and efficiently. While most transactions are processed in real time, occasional recoverable errors can occur when a product provider in the ecosystem encounters an issue.

To address this, our API automatically sets a 15-minute timeout on the transaction and then retries it. If there is an extended problem with a product provider, the system will continue to retry the transaction every 15 minutes until it either completes successfully or fails after 24 hours.

If you would prefer not to use the queue and retry feature, you may turn the feature off in the client console on the API settings page.

For more information refer to the Queue and Retry guide.

Digital Gift Cards and Utility Payments based on the brand requirements may require more information than just the recipient’s phone number. For the specific requirements of a Digital Gift Card or Utility Payment offer the list of fields required will be provided in the catalog. You can find all the possible fields that a these offers may require on the required fields page.

For a detailed list of possible error statuses, please see Error Message Guide.

Transaction Log Structure

zendit Transactions contain a log of activity as the transaction progresses through the system. You can find this on any transaction under the “log” structure. The log will give more detail about the transaction from when it was submitted, when it was authorized against the wallet, when it was submitted for fulfillment and any errors that were encountered while processing will be noted at the stage where the transaction failed.

When using the createdAt date on the transaction search endpoints (/topup/purchases, /transactions and /voucher/purchases) dates use the RFC 3339 format in UTC Timezone (e.g. 2023-02-15T03:15:22Z)

When searching with createdAt there are a few prefixes you can add to the time in order to search around the timestamp supplied. The search formats are as follows:

Catalog methods support filtering/searching products by region. Regions are string values and supported with the following values:

• Global (includes global esim)
• Africa
• Asia
• Caribbean
• Central America
• Eastern Europe
• Western Europe
• North America
• Oceania
• South America
• South Asia
• Southeast Asia
• Middle East and North Africa

Swagger pages for the api can be found at https://api.zendit.io/swagger/index.html

Phone number lookup is currently in beta with select clients. The beta group is closed to new participants. For testing in the test mode environment, the following phone number patterns may be used to get simulated results:

Using any number sequence to fill in the X in these numbers will yield these results in the test mode environment. All other phone numbers will yield a phone number not found error. For the production environment, all valid phone numbers will work.

Note that for US phone numbers and some destinations that use MVNOs (e.g. Boost, Mint) the carrier result will return the network the device is assigned to (e.g. T-Mobile in the case of Mint Mobile) and will not return the name of the MVNO. This is a limitation of the service.

Clients who aren't included in the beta will receive an error on the endpoints of LOOKUP_NOT_ENABLED when calling the endpoint.

Transaction reports can be generated from the API. Transaction reports are generated asynchronously and are first called with the POST request to generate the report with a start datetime and end datetime. The report generates a CSV file of transactions that are either in DONE or FAILED status. Transactions that have not completed will not be included in the report since their final status is not known until they complete.

For the time period, the start datetime includes transactions that are at the start datetime or later. For the end datetime, transactions included in the report will be earlier than the set time. As an example, to produce a report for 1 day, set the start datetime to "2024-02-01T00:00:00Z" and the end datetime to "2024-02-02T00:00:00Z" and it will include all transactions starting from midnight on February 1, 2024 and completing before February 2, 2024. Transactions still in flight on February 1, 2024 but not completing until February 2, 2024 will appear on a report for 1 day for February 2, 2024.

When selecting a time period, consider the length of time between the start and end time and your transaction volume as a guide to how long a report may take to generate. The longer the period and number of transactions completed within this period will require more time to generate the report.

After sending a generate report, you will receive an acknoledgement of the request including a system generated report Id to track the status. You may poll the status endpoint (polling interval should be at least 1 second between poll requests) to check on the progress of the report. When the report status has responded with Ready, the file is ready to download.

Downloading the report you may use the reportId and filename included in the status response. You may also use the downloadUrl which has the fully formed API call to download the report. Downloading the report must include your API Key since report downloads are not on a public URL.

In the case of failure, the failure reason will be returned in the error structure and the report will have a FAILED status. You can check the log structure in the report to find out more information as to why the report generation failed.

Check your account balance. For wallet inforatmion see the zendit wallet guide.

eSIM Catalog and Transaction Operations. For more information about eSIM products see the eSIM Guide. For catalog operations refer to the zendit catalog guide. For transactions refer to the zendit transaction guide. For webhooks refer to the zendit webhook guide.

Mobile Top Up, Mobile Bundle, and Mobile Data Catalog and Transaction Operations For catalog operations refer to the zendit catalog guide. For transactions refer to the zendit transaction guide. For webhooks refer to the zendit webhook guide.

Digital Gift Card and Prepaid Utilities Catalog and Transaction Operations For catalog operations refer to the zendit catalog guide. For transactions refer to the zendit transaction guide. For webhooks refer to the zendit webhook guide.