Overview Asynchronic Messaging

From Complete Cyclos documentation wiki
Jump to: navigation, search

Overview Asynchronic Messaging

What does the system do?

The objective of the system is to be able to send or recive asynchronous messages. The system has been developed to fullfill the need of Cyclos to work with SMS, although we wanted to isolate Cyclos from the complexities of the SMS world. The main idea was to work with SMS but we didn't want to restrict it only to the SMS world, so we build it to be able to handle any kind of asynchronous messages.

Brief review of the system

There are more than one responsability in the system. The main responsability is to connect one or several intances of Cyclos to the SMS world, this means the system should be able to decide which Cyclos is a message for or which number is a Cyclos message for (we named this routing). Once a message arrive to the system, it should be able to recognize the user request and extract the information needed to ask Cyclos to carry out the action.

There are several routing possibilities. In the most general scenario the system can be connected to several service providers and to several Cyclos instances. The other scenarios are simplifications of that one.

The system should be able to process a message. Once a message arrived the system will try to identify what kind of message it was (payment, request, detail, etc). If the message isn't recognized, the system would answer with a help message. The system would make Cyclos process the message, if the message was recognized and the parameters were correct.

Use cases

Simple payment

Paymen flow

In this scenario one member decides to do a payment to another member. At that time, the payer send a text message indicating the amount, his/her password and the identifier of the other member. The system send a text message to the other member to notify that a payment has been done.
Parameters

  • Password: Depending on Cyclos configuration the password could be the user login password for the web or a user generated PIN.
  • Member identifier: Again depending on Cyclos configuration it could be the username, card pin, etc.
  • Amount: This is how much do you want to pay.
  • Currency: Optional parameter to indicate the currency you want to use to pay (There is a default currency).


Request payment

Request flow

A member want to ask another member to pay him some money. The member send a text message indicating the amount, the payer member identifier, the amount and possibly the currency. The other member receives a text message indicating other member has requested a payment, the member could answer the message responding with the code that was sent to him/her to agree to realize the payment or don't answer at all so the payment will never be done.

  • Member identifier: Depending on Cyclos configuration it could be the username, card pin, etc.
  • Amount: This is how much do you want to pay.
  • Currency: Optional parameter to indicate the currency you want to use to pay (There is a default currency).


Transactions detail

Details flow

The member want to see the transactions he/she has made. He/She send a text message indicating the password and possibly the currency and page number.

  • Password: Depending on Cyclos configuration the password could be the user login password for the web or a user generated PIN.
  • Currency: Optionaly you can specify the currency you want to see the transactions for (there is a default currency).
  • Page number: The results are paginated so optionaly you can specify the page number here.