List of ITP Use Cases

The Use Case (UC) code identifies the use case in relation to the others. The code contains the acronym UC and a reference code (e.g. UC19). All use cases currently available on the ITP platform and those under development are listed below.

UC01 - Merchant-Initiated Merchant Payment

This use case describes the process in which a user (payer) purchases a service or goods from a merchant. The transaction is initiated by the merchant and needs to be validated by the user (payer).

User Story

Didier walks into a store to purchase a modem for his home.

After giving his information to the merchant, the merchant generates a transaction request which gets processed through the system. Didier is notified of the request by his FSP, and approves the payment. After approval, both parties receive a confirmation of payment from their respective FSPs.

Use Case Name:	Merchant-Initiated Merchant Payment
Summary:	This use case simulates a scenario where the payer would like to purchase goods or services from a merchant but they are each using different wallet providers.
Actors:	Payer FSP Payee FSP Service Provider Switch
Preconditions:	Service Provider has GSMA Mobile Money API Implemented. Service Provider is capable of handling async calls. Payee and Payer MMOs exist in Mojaloop as Participants. Payee and Payer exist in Mojaloop as Parties.
Description:	Payer wants to buy goods/services from a merchant. Merchant sends a transaction request to their FSP (Payee FSP). The Payee FSP then sends this request to the Payer FSP via the Switch Payer FSP sends a quote back to Payee FSP for conformation After conformation, the transfer is sent from the Payer FSP to the Payee FSP via the Switch
Exceptions1:	Rejected Transaction by Payer FSP, Rejected Transaction Request by Payer FSP, Rejected Quote by Payee FSP, Declined Transaction by Payee FSP
Postconditions:	Transaction Request: Accepted Rejected Quote: Accepted Expired Rejected Transfer: Committed Aborted

The sequence diagram below shows the typical flow for an authorized transaction:

UC02 - Customer-Initiated Merchant Payment

Under development

This section is still under development.

UC03 - Peer-to-Peer

This use case describes the process involved when a user (payer) needs to carry out a transaction to send money to another user (payee) who has a different financial service provider.

User Story

Zuri needs to transfer money to her brother who lives in another city through her mobile money service provider. Both have phones but have different financial service providers. After entering her brother's information, or using previously saved information, she starts the transfer process. Zuri can see all fees (including exchange rates, if any) and decides to proceed with the transfer. A few seconds later, Zuri receives confirmation of the transaction and her brother receives the money in his mobile money account.

Use Case Name:	Peer to Peer
Summary:	This use case simulates a scenario where the Payer would like to send money to a Payee but each of them is using different wallet providers
Actors:	Payer Payee Payer FSP Payee FSP Mobile Money Operator Switch
Preconditions:	The user has permission to use P2P transfer FSPs are capable of handling async calls. Payer FSP and Payee FSP exist in Mojaloop as Participants. Payee and Payer exist in Switch as Parties.
Description:	Payer shows interest in making a transfer; Payer FSP performs the transfer quote via switch to Payee FSP; After receiving the quote with fees and commissions, Payer decides to proceed with the transfer; Payer FSP transfers to Payee FSP via Switch; Payee FSP notifies Payee of receipt of the transfer.
Exceptions1:	Payee FSP Rejected Quote, Payee Rejected Quote
Postconditions:	Quotes: Accepted Expired Rejected Transfer: Committed Aborted

Sequence diagram for one of the basic paths (happy flow) for P2P:

UC04 - International Remittance

Under development

This section is still under development.

---

Footnotes

• 1 : The exceptions listed are directly related to alternative paths the use case can take. Using the exceptions, it is possible to derive the unhappy flows covered by the appropriate test cases.