Frequently Asked Questions

Each product in our API contains a redemption mechanism. This is either “Immediate” or “ReadReceipt”. 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, discounts etc. will remain the same. All your transactions (regardless of the API version) will be included in any 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 with the 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.


TransferType RedemptionMechanism Benefits Notes
TopUp Immediate Mobile, Minutes
Data Immediate Mobile, Data
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:

  • 18760000000 – 1, Success
  • 18760000004 – 5, ProviderError, ProviderRefusedRequest
  • 18760000005 – 4, AccountNumberInvalid, ProviderRefusedRequest
  • 18760000006 – 5, ProviderError, ProviderUnknownError


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:

  • Countries (getCountries)
  • Providers (getProviders)
  • Regions (getRegions)
  • Products (getProducts)


With this information available in your system, your application should be able to:
  • Ask the customer to select country
  • Filter providers by that country
  • Ask the customer to select the provider
  • Show regions (only if there is more than one for that provider)
    • Ask the customer to select the region
  • Filter products using country and provider (and region if applicable)
  • Ask customer to provide account number
  • Send transfer with the necessary information
manual flow image

In our second recommendation your application will use our lookup functionality to find out the products available to a given account number. The customer is expected to provide the account number upfront and from this your application should be able to show the products available.

Initially (and ideally outside of the transaction flow) your system should again request and persist the following:
  • Countries (getCountries)
  • Providers (getProviders)
  • Regions (getRegions)
  • Products (getProducts)


With this information available in your system, your application should:
  • Ask customer for account number
  • Call getAccountLookup with the given account number, possible outcomes:
    • Successful (ResultCode 1)
      • Filter your products with country, region and providers
      • Ask customer to select product
      • Send transfer
    • Nearest match (ResultCode 2) – we are not sure about the providers for the account number but we identified the country
      • Filter your providers with country
      • Ask customer to select provider
      • Ask customer to select region (if there is more than one)
      • Filter products by country, region and provider
      • Ask customer to select product
      • Send transfer
    • Failure (ResultCode 4) – we don’t recognise the country
      • Ask customer to review the phone number or offer the customer to select country, region and providers manually
account lookup image

In our 3rd recommendation your application will use our getProduct functionality to find out what products the phone number maps to. The customer is expected to provide the account number upfront and from this your application should be able to show the products available.

Initially (and ideally outside of the transaction flow) your system should again request and persist the following:
  • Countries (getCountries)
  • Providers (getProviders)
  • Regions (getRegions)
  • Products (getProducts)


With this information available in your system, your application should:
  • Ask customer for account number
  • Call getProduct with the given account number, possible outcomes:
    • Successful (ResultCode 1)
      • Filter your products with country, region and providers
      • Ask customer to select product
      • Send transfer
    • Successful (ResultCode 1) – we are not sure about the products for the account number so a list is displayed, ask the customer to
      • Filter your providers with country
      • Ask customer to select provide
      • Ask customer to select region (if there is more than one)
      • Filter products by country, region and provider
      • Ask customer to select product
      • Send transfer
    • Failure (ResultCode 4) – we don’t recognise the number
      • Ask customer to review the phone number or offer the customer to select country, region and providers manually
get product image


We have an integration team. Please email partnersupport@ding.com to get in contact.


Contacting partnersupport@ding.com is the best option for further questions.