Use Case Examples for GSMA Simulator
This use case enables the caller to determine the availability of the service from the financial service provider. The provider will return a status of ‘available’, ‘unavailable’ or ‘degraded’.
This use case returns the applicable balance(s) for the specified account. The use case is typically used for two purposes: 1. Allows an API caller to determine whether an account has sufficient funds before a subsequent service is invoked. 2. Allows an API caller to return the balance(s) to the account holder.
This use case returns a set of transactions for a given account. The offset and limit parameters are used by the caller to retrieve the transactions in sets.
This use case enables a caller to retrieve bill information for an account holder with a financial service provider. The provider will in-turn route the request to the destination service provider (biller) who will return bills that outstanding for the account holder. Prior to this request, the caller has the option of retrieving a list of valid service providers from the financial service provider. This list can be used to allow the account holder to select the service provider for which they wish to view their bills.
A debit mandate is an authorisation to debit an account on a frequency and timing specified in the request payload. This use case enables a caller to request the creation of a debit mandate for an account holder of the financial service provider. The provider will request authorisation from the account holder prior to completing the request.
An authorisation code provides preapproval of a payment request to an amount and period specified in the request payload. When the period has ended, the code will no longer be valid. The financial service provider will ensure that the account holder authorises the request to generate a code prior to completing the request. This use case also illustrates how the authorisation code can be used to preauthorise a subsequent merchant payment.
This use case allows a link to be established between two separate accounts held with two separate financial service providers. Once established, a link allows the account holder to push and/or pull funds between accounts as demonstrated in this example.
This use case demonstrates how the Mobile Money API can be used to enable a person to person funds transfer between two financial service providers. The status of the account is verified before the transfer is initiated.
This use case enables a sending account holder to make a cross-border transfer to a destination account holder with another financial service provider. In this use case, the transfer will be routed via a remittance hub. The remittance hub provides transaction routing capabilities and avoids the need for bilateral connections. The sending financial service provider will initiate the process by requesting a forex/fee quotation from the remittance hub. Assuming the quote is accepted by the sender, the sending financial service provider will send the transfer request via the remittance hub to the receiving financial service provider.
This use case enables a merchant to initiate a request for payment to a financial service provider. The provider will obtain authorisation of the payer before completing the request.
This use case enables a merchant to initiate a request for payment to a financial service provider. In this example, the polling method is used instead of the call-back method.
This use case enables a caller to make a payment on behalf of an account holder at a financial service provider. This use case assumes that a mandate to debit the account holder’s account has previously been requested by the caller and enabled by the financial service provider. To make the payment, the financial service provider will route the request to the destination service provider. Once the destination service provider confirms acceptance of the payment, the financial service provider will complete the request and notify the caller accordingly. Prior to the payment request, the caller has the option to return bill details to enable the account holder to choose which bill to pay.
Using the mobile money API, a caller can submit a batch of transactions for processing to a financial service provider. Batch processing is always asynchronous and follows a createdàapprovedàcompleted state transition. The ‘created’ state is reached when the batch of transactions has been successfully parsed by the provider. Upon reaching this stage, a caller can approve the batch – this will move the batch to ‘approved’ state. The transactions in the batch are then processed and posted by the provider and the batch is set to ‘completed’.
This use case enables a caller (typically the payee) to perform a transaction reversal using the Mobile Money API. The caller provides the original transaction reference in the request that is subsequently used by the financial service provider the identify the transaction that is to be reversed. If no amount is specified in the payload, the provider will reverse the entire amount.
This use case enables a payee to refund a payer of goods and/or services. The payee requests a refund (type = ‘adjustment’) to the payer’s financial service provider. The original transaction reference does not need to be supplied for a refund.
In some circumstances, the caller may not have received the final representation of the resource for which it attempted to create. This use case allows a caller to retrieve a representation of the resource assuming that it exists. The provider will use the Client Correlation Id to identify the requested resource and return a link to that resource.