Each product in our API contains a redemption mechanism. This is either “Immediate” or
PIN products are of the “ReadReceipt” type.
The information you must provide to your customer will be available in the “ReceiptText” which is part of the SendTransfer response.
The default account number for PIN products is 0000000000
All versions of the API connect to the same system. Your account credentials, products,
will remain the same. All your transactions (regardless of the API version) will be included in
report or invoice.
Previous API versions may not have the same products supported.
When you are in UAT mode (before going Live) you use the UAT test numbers. When you are in Live mode you can still test with the UAT success numbers you can find in getProducts response (UatNumber field). These numbers always return success and will not deduct anything from your balance.
Typically, they cannot be changed but certain cases can be made from time to time.
There are no test accounts. Testing can be accomplished by sending UAT transactions as described above in question 4.
ValidateOnly is True it only checks if the syntax are correct and if the user has enough balance, it never deducts from the balance. When it is set to false, money is deducted from the balance and a top up is sent as well as the successful response if no errors occur.
Some products declare SettingDefintions that mandate name-value pairs that can be submitted
transfer and will be passed to the Provider.
Distributors can submit their own name-value pairs and we will store them with the transfer. These name-value pairs can be queried upon using the ListTransferRecords method.
The distributor should also include a DistributorRef that uniquely identifies the transfer within their system.
Each batch request will contain an array of input items that are POSTed in the body of the request. Each of these items must contain a string BatchItemRef property that will uniquely identify the item within the overall request.
|PIN||ReadReceipt||Mobile, Minutes, Data||Mobile operator products that return a PIN (Can be minutes, data, etc)|
|LDI||ReadReceipt||LongDistance, Minutes||Involves access numbers/calling services (See Pure Minutes)|
|Voucher||ReadReceipt||Digital Product||Products unrelated to mobile operators (See iTunes, Spotify, Google Play, iFlix)|
|Bundle||Immediate||Mobile, Minutes, Data|
|DTH||Immediate||TV, Utility||Look into DTH India for example|
It is suggested to run getProducts daily. Depending on sale output and system performance it could be performed hourly or weekly. Automatic email system can be created client side to notify of product changes.
While integrating with our API, your account will be in live mode by default. While in this
mode, only test numbers will work with the SendTransfer API method. You can use Live numbers
for all other methods.
The success case number is available by calling the GetProducts method. It is listed as “UatNumber”. The other test numbers for the different cases can be assumed from the success number. The only difference is that the final digit of the number.
As an example, for Digicel Jamaica, the UatNumber returned from GetProducts is 18760000000.
This is the number we will use for the successful case. For the other cases we need to replace the final digit with either 4, 5 or 6 for the other cases like below:
SendTransfer for UAT numbers would work with zero balance. You can fund your account using Self-Funding (Credit/debit Card or PayPal, if currency is supported) or by funding our bank account. You can contact our BD team for account details.
There are countless different means of consuming our API depending on your system and
requirements, the below is just proposed suggestions.
Customer manually selects country, provider and product
In this first recommendation your application will get all the information beforehand. The main idea of this suggestion is that your system has minimal API calls during each transaction. The customer is expected to provide the necessary parameters needed to complete the transfer.
Initially (and ideally outside of the transaction flow) your system should request and persist the following: