MComviva_mobiquity_MovilRed_Incomm Code_FSD_v1.0_27092018

Functional Specification Document

MovilRed – Incomm Code

Document Version: 1.0

Date: 27 th Sep’ 2018

MovilRed_MOV-35

Document Change History

Version

Number

Date Description of Changes Author Reviewer Comments

1.0 Sep 27th,

2018

Initial Version

Surbhi

Source: Comviva

Comviva Technologies Ltd. 2

MovilRed_MOV-35

Table of Contents

DOCUMENT CHANGE HISTORY ............................................................................................................. 2

1. DOCUMENT INFORMATION ......................................................................................................... 5

1.1 CONTEXT AND PERSPECTIVE ........................................................................................................................... 5

1.2 DOCUMENT SCOPE.......................................................................................................................................... 5

1.3 REQUIREMENT REFERENCE ............................................................................................................................. 5

1.4 ACRONYMS, ABBREVIATIONS AND CONVENTIONS ............................................................................................ 5

1.4.1 ACRONYMS & ABBREVIATIONS................................................................................................................ 5

1.4.2 CONVENTIONS ....................................................................................................................................... 6

1.5 INTENDED AUDIENCE ....................................................................................................................................... 6

1.6 LIMITS OF THE DOCUMENT ............................................................................................................................... 6

2. CONTENT PURCHASE – INCOMM AND AGENT CODE ............................................................. 7

2.1 REQUIREMENT ................................................................................................................................................ 7

2.2 PROPOSED SOLUTION ..................................................................................................................................... 7

2.3 IMPORTANT NOTES & ASSUMPTIONS ............................................................................................................... 7

2.4 DEPENDENCIES ON MOVILRED ........................................................................................................................ 8

3. CONTENT PURCHASE PIN AGENT/MERCHANT – DECRYPTED FORM .................................. 8

3.1 REQUIREMENT ................................................................................................................................................ 8

3.2 USE CASE – CONTENT PURCHASE AGENT/MERCHANT INITIATED...................................................................... 8

3.3 SEQUENCE DIAGRAM .................................................................................................................................... 10

3.4 BUSINESS RULES .......................................................................................................................................... 10

3.5 IMPORTANT NOTES & ASSUMPTIONS ............................................................................................................. 10

4. CONTENT PURCHASE PIN AGENT/MERCHANT – ENCRYPTED FORM ................................ 11

4.1 REQUIREMENT .............................................................................................................................................. 11

4.2 PROPOSED SOLUTION ................................................................................................................................... 11


4.4 DEPENDENCIES ON MOVILRED/THIRD PARTY SYSTEM .................................................................................... 11


MovilRed_MOV-35

5. CONTENT PURCHASE PIN SUBSCRIBER – DECRYPTED FORM ........................................... 12

5.1 REQUIREMENT .............................................................................................................................................. 12

5.2 USE CASE – CONTENT PURCHASE SUBSCRIBER INITIATED ............................................................................. 12

5.3 BUSINESS RULES .......................................................................................................................................... 13

5.4 SEQUENCE DIAGRAM .................................................................................................................................... 14


6. APPENDIX.................................................................................................................................... 15

SIGN OFF’S ............................................................................................................................................. 15

CONTACT US .......................................................................................................................................... 17


MovilRed_MOV-35

1. Document Information

This chapter gives a brief introduction to the scope and organization of the document.

1.1 Context and Perspective

The purpose of this functional specification document is to describe the below listed new

requirements that have been requested by MovilRed

• Incomm Code

1.2 Document Scope

The scope of this document is to provide functional details of changes/modifications that need to be

included in current Mobiquity system in order to support Incomm code requirement

Note: This FSD has been formulated basis on the feasibility shared in the Migration tracker, verbal

communication over calls with MovilRed’s business team and e-mail exchanges. So Once FSD is

signed-off only this document will be referred for scope of Change Request (CR) in future.

No other document and communication will be referred. If there is a change in the scope, then FSD

needs to be updated, shared with MovilRed’s team. Sign-Off to be provided on the latest version.

(which may lead to changes in efforts and delivery date)

1.3 Requirement Reference

Document, Web-link, E-mail

https://plan.mahindracomviva.com/browse/MOV-

35

Author / Sender (if

applicable)

MovilRed

Version / Date (if

applicable)

1.4 Acronyms, Abbreviations and Conventions

This section provides a list of all Acronyms or Abbreviations and terms required to properly interpret

the document.

1.4.1 Acronyms & Abbreviations

Term

SMS

USSD

MSISDN

PIN

Full Form

Short Message Service

Unstructured Supplementary Service Data

Mobile Subscriber Integrated Services Digital Network Number (i.e. Mobile

Number)

Personal Identification Number


MovilRed_MOV-35

1.4.2 Conventions

Depicts important note

* Depicts mandatory field

Depicts important open item

All USSD messages are depicted in Blue color

1.5 Intended Audience

MovilRed team of product management, product validation group, marketing, operations, project &

program management, change management, documentation and technical (IT) personnel are

responsible for evaluating, architecting, specifying, implementing and operating the Mobiquity system

are the intended audience for this document.

1.6 Limits of the Document

The document describes only the functional details of changes to be made. Technical implementation

details are not covered in this document.


MovilRed_MOV-35

2. Content Purchase – Incomm and

Agent Code

2.1 Requirement

As part of the content purchase request there is a need to send Incomm code and Agent code as part

of content purchase request sent to the third party system

Incomm code and Agent Code is needed for the Incomm system. Incomm system needs this Incomm

and agent code to keep track of number of agents/stores that are doing sales.

The business objective behind this use case is that Agent code is ideally a store code for Incomm

system and its partners internationally like Netflix, Xbox etc. and as per the contract agreement

MovilRed needs to share this info with Incomm systems which will further be shared with their

partners. Additionally, Incomm code is the unique code of parent agent generated and maintained by

the Incomm system used to authorize agents/merchants.

2.2 Proposed Solution

To cater to the above mentioned requirement, the following steps would be followed.

• The Incomm code received from Incomm system can be added in existing non-mandatory

parameter "Channel ID" field at the time of agent creation for new agents.

• For existing agents, the Incomm code can be added at the time of agent modification.

• This parameter “Channel ID” would also be available for “Bulk user Modification” so that

the same can be updated in bulk by MovilRed.

• The Incomm code will be minimum 6 digits numeric number.

• Agent code is the existing agent id available in the Mobiquity system for each individual

agent.

• Incomm code and Agent code will be sent as part of internal request sent to the third party

system.

• Incomm system returns only the Incomm code for parent agents; hence MovilRed will

have to map the same Incomm code for child agents under the parent and accordingly will

have to specify the same under agent profile.

2.3 Important Notes & Assumptions

Incomm code and Agent code is required to be sent as part of internal content purchase

request to third party system.

There will be no change at the API level to include these request input parameters

There will be no Agent/Incomm code maintained for subscriber user.

The change would be applicable only when the content purchase request is initiated by the

Agent/Merchant, not applicable for request initiated by subscriber user.


MovilRed_MOV-35

No changes would be applicable for Agent code, it will be the same agent id currently

available for all agents in Mobiquity system

The change to include Agent and Incomm code is only applicable for content purchase

request no other service is applicable.

Both Incomm and Agent code will be stored and available in Mobiquity DB.

There would be no validations on the Incomm code as it will be generated by Incomm system

and Mobiquity will only provide the provision to add this Incomm code as part of user profile to

be sent internally in content purchase request.

2.4 Dependencies on MovilRed

This section lists all those points, against which inputs are required from the MovilRed team & without

which final delivery cannot be made.

• MovilRed needs to map and specify the Parent Incomm code for child users under him

using the agent registration/modification module of Mobiquity system.

3. Content Purchase PIN

Agent/Merchant – Decrypted form

3.1 Requirement

As part of the content purchase request there is a need to manage content Purchase pin in Mahindra

Mobiquity system which is required to be sent to the agents in decrypted form on successful response

Mahindra Mobiquity system will receive the content purchase PIN as part of successful response sent

by the third party system for every real time content purchase request sent to third party. This content

purchase pin returned in response will be in decrypted form, it is expected to store this PIN in

encrypted form in the Mobiquity database

3.2 Use Case – Content Purchase Agent/Merchant Initiated

Use Case ID

Use Case

Name

Description

Actors

Bearer

Trigger Event

Related Use

Cases

UC_01

Content Purchase – Agent/Merchant Initiated

Using this service, the channel user will be able purchase Content for the customer

in his shop. The Content Provider is assigned a wallet in the system and the money

collected from Merchant for content purchase will get credited in the same.

Channel User (Agent/Merchant)

Mobile App

Clicking “Content Purchase” on mobile app

NA


MovilRed_MOV-35

Pre

Conditions

Post

Conditions

Frequency of

Use

Exceptional

Condition

Flow Of

Events

Validations

Important

Note

1. Channel User must be registered in the mobiquity® system and active.

2. Content pin returned from third party system will be maintained in the

mobiquity system.

3. TCP, Service Charge and Transfer Rule must be defined in the system

4. Channel User should not be barred (sender or both) or suspended in the

system.

5. Integration with third party should be in place for Content provider

1. Content Card is purchased by the Channel User

2. Money is debited from channel user wallet and credited into Content Provider

wallet.

High

NA

Sl.

No.

1.

2

3

4

6

NA

5 NA

User Action

Channel User will click on the

“Content Purchase” on his

mobile app.

Channel User will select the

“Content” he would want to

purchase.

The Channel User will select

the type to purchase, enter the

mobile number of the customer

and click on “Select”

User clicks on Purchase and

authenticate transaction using

MPIN

System Response

Mobiquity will get the content details from the

third party

The mobile app will show the content listing from

the selected content to inform customer the type

of content available for selected service provider

like Netflix, Xbox etc

On the next page, the mobile app will show a

page which will have the details of the content,

amount, reference number, amount and

customer’s mobile number.

Post MPIN authentication, the money

transaction will take place in mobiquity which will

debit the channel user wallet an credit the

Content Provider’s Wallet in Mobiquity

Once transaction is completed, the mobiquity

system will send a purchase request to third

party

In response the third party will send the content

purchase pin, this pin will be returned in realtime

from the third party in decrypted form which

will be encrypted and stored in Mobiquity system

and will be sent to the agents (channel user) in

decrypted form via SMS/Email.

a. Content Purchase PIN will be returned in real time from third party system

for every single request sent for content purchase.

b. The PIN would be maintained in Mobiquity DB in encrypted form


MovilRed_MOV-35

3.3 Sequence Diagram

3.4 Business Rules

• Channel User should be available in the system as active registered entity.

• Channel User should not be barred as sender or both.

• If Content Purchase Payment request response is a failure then the mobiquity system will roll

back the transaction and service charge to the Channel User’s wallet and send a failure

notification

• If Content Purchase request response is ambiguous then the mobiquity system will do a reenquiry.

If on re-enquiry the response is failure then the mobiquity system will roll back the

transaction and service charge to the Channel User’s wallet and send a failure notification.

• If Content Purchase request response is ambiguous then the mobiquity system will do a reenquiry.

If on re-enquiry the response is also a timeout then the system will mark this

transaction Ambiguous for manual reconciliation.

• If SMS/Email has not been sent due to any connectivity/network breakdown then Mobiquity

system will retry basis on the configuration setup in the system.


This section lists all the important points that are assumed to be true & accordingly have proposed the

solution against the requirement.

There will be changes at API level for content purchase to receive the content purchase PIN

from third party system as part of successful response.

The encryption/decryption key to be used is mentioned under the “Appendix” section.


MovilRed_MOV-35

4. Content Purchase PIN

Agent/Merchant – Encrypted form

4.1 Requirement

As part of the content purchase request there is a need to send and manage content Purchase pin in

Mahindra Mobiquity system that is required to be sent to only Mayorista agents in encrypted form in

xml response




encrypted form in the Mobiquity database

4.2 Proposed Solution

To cater to the above mentioned requirement, Mobiquity platform would support this requirement as

explained below.

• Mayorista model agents would be distinguished in the Mobiquity system basis on the

Grade.

• Specific grade would be defined making sure it won’t be applicable for any other agents

• Mayorista model agent when initiates the content purchase request via Mobile App, will

get encrypted content purchase PIN from Mobiquity system as part of xml response if

transaction is successful.

• There will be no SMS/Email notification sent to the Mayorista agents containing the PIN,

as it will be suppressed.




The changes described under section “4.2” will be only applicable for the agent (channel user)

not subscribers.

4.4 Dependencies on MovilRed/Third party system

This section lists all those points, against which inputs are required from the MovilRed team & without

which final delivery cannot be made.

• It will be the responsibility of third party system for agents like Mayorista to further decrypt

the PIN received in encrypted form from Mobiquity platform as part of xml response and


MovilRed_MOV-35

share it with the agent/subscriber user. This is outside the scope and control of Mahindra

Mobiquity system

5. Content Purchase PIN Subscriber –

Decrypted form

5.1 Requirement

As part of the content purchase request there is a need to send and manage content Purchase pin in

Mahindra Mobiquity system that is required to be sent to the subscriber users on successful response




encrypted form in the Mobiquity database.

5.2 Use Case – Content Purchase Subscriber Initiated

Use Case ID

Use Case

Name

Description

Actors

Bearer

Trigger Event

Related Use

Cases

Pre

Conditions

Post

Conditions

Frequency of

Use

Exceptional

Condition

UC_02

Content Purchase – Subscriber Initiated

Using this service, subscriber will be able to purchase the content. The Content

Provider is assigned a wallet in the system and the money collected from subscriber

for content purchase will get credited in the same.

Subscriber/Customer

Mobile App

Clicking “Content Purchase” on mobile app

NA

1. Subscriber must be registered in the Mobiquity® system and active.

2. Content pin returned from third party system will be maintained in the Mobiquity

system.

3. TCP, Service Charge and Transfer Rule must be defined in the system

4. Subscriber should not be barred (sender or both) or suspended in the system.

5. Integration with third party should be in place for Content provider

1. Content Card is purchased by the Subscriber

2. Money is debited from subscriber’s wallet and credited into Content Provider

wallet.

High

NA


MovilRed_MOV-35

Flow

Events

Validations

Important

Note

Of

Sl.

No.

1.

2

3

4

6

NA

5 NA

User Action

Subscriber will click on the

“Content Purchase” on his

mobile app.

Subscriber will select the

“Content” he would want to

purchase.

The Subscriber will select the

type to purchase, enter the

mobile number and click on

“Select”

User clicks on Purchase and

authenticate transaction using

MPIN

System Response

Mobiquity will get the content details from the

third party

The mobile app will show the content listing from

the selected content to inform customer the type

of content available for selected service provider

like Netflix, Xbox etc

On the next page, the mobile app will show a

page which will have the details of the content,

amount, reference number, amount and

customer’s mobile number.

Post MPIN authentication, the money

transaction will take place in Mobiquity which will

debit the subscriber’s wallet and credit the

Content Provider’s Wallet in Mobiquity

Once transaction is completed, the Mobiquity

system will send a purchase request to third

party

In response the third party will send the content

purchase pin, this pin will be returned in realtime

from the third party in decrypted form which

will be encrypted and stored in Mobiquity system

and will be sent to the subscriber in decrypted

form via SMS/Email.

a. Content Purchase PIN will be returned in real time from third party system

for every single request sent for content purchase.

b. The PIN would be maintained in Mobiquity DB in encrypted form

5.3 Business Rules

• Subscriber should be available in the system as active registered entity.

• Subscriber should not be barred as sender or both.

• If Content Purchase Payment request response is a failure then the Mobiquity system will roll

back the transaction and service charge to the Subscriber’s wallet and send a failure

notification

• If Content Purchase request response is ambiguous then the Mobiquity system will do a reenquiry.

If on re-enquiry the response is failure then the Mobiquity system will roll back the

transaction and service charge to the Subscriber’s wallet and send a failure notification.

• If Content Purchase request response is ambiguous then the Mobiquity system will do a reenquiry.

If on re-enquiry the response is also a timeout then the system will mark this

transaction Ambiguous for manual reconciliation.

• If SMS/Email has not been sent due to any connectivity/network breakdown then Mobiquity

system will retry basis on the configuration setup in the system.


MovilRed_MOV-35

5.4 Sequence Diagram




There will be changes at API level for content purchase to receive the content purchase PIN

from third party system as part of successful response.

The encryption/decryption key to be used is mentioned under the “Appendix” section.


MovilRed_MOV-35

6. Appendix

Below document contains the Encryption/Decryption key shared by MovilRed for the content

purchase PIN.

Encryption_Decrypti

on-Key.docx

Sign Off’s

Position Name Signature Date of signature


MovilRed_MOV-35

Disclaimer

Copyright © 2018: Comviva Technologies Ltd, Registered Office at A-26, Info City, Sector 34,

Gurgaon-122001, Haryana, India.

All rights about this document are reserved and shall not be , in whole or in part, copied,

photocopied, reproduced, translated, or reduced to any manner including but not limited to electronic,

mechanical, machine readable ,photographic, optic recording or otherwise without prior consent, in

writing, of Comviva Technologies Ltd (the Company).

The information in this document is subject to changes without notice. This describes only the product

defined in the introduction of this documentation. This document is intended for the use of prospective

customers of the Company Products Solutions and or Services for the sole purpose of the transaction

for which the document is submitted. No part of it may be reproduced or transmitted in any form or

manner whatsoever without the prior written permission of the company. The Customer, who/which

assumes full responsibility for using the document appropriately, the Company, welcomes customer

comments as part of the process of continuous development and improvement.

The Company has made all reasonable efforts to ensure that the information contained in the

document are adequate, sufficient and free of material errors and omissions. The Company will, if

necessary, explain issues, which may not be covered by the document. However, the Company does

not assume any liability of whatsoever nature, for any errors in the document except the responsibility

to provide correct information when any such error is brought to company’s knowledge. The Company

will not be responsible, in any event, for errors in this document or for any damages, incidental or

consequential, including monetary losses that might arise from the use of this document or of the

information contained in it.

This document and the Products, Solutions and Services it describes are intellectual property of the

Company and/or of the respective owners thereof, whether such IPR is registered, registrable,

pending for registration, applied for registration or not.

The only warranties for the Company Products, Solutions and Services are set forth in the express

warranty statements accompanying its products and services. Nothing herein should be construed as

constituting an additional warranty. The Company shall not be liable for technical or editorial errors or

omissions contained herein.

The Company logo is a trademark of the Company. Other products, names, logos mentioned in this

document, if any, may be trademarks of their respective owners.

Copyright © 2018: Comviva Technologies Limited. All rights reserved.


MovilRed_MOV-35

Contact Us

Headquarters

Comviva Technologies Limited

A-26, Info City

Sector 34

Gurgaon 122022

Haryana, India

T: +91-124-4819000

F: +91-124-4819777

Bangalore Office

Comviva Ltd.

Maruti Towers

138, Airport Road

Bangalore – 560 008

INDIA

Tel: +91 80 4030 1550

Fax: +91 80 4115 0552

Mumbai Office

Comviva Ltd.

Unit No.4, 1 st Floor,

Paradigm Tower, B Wing,

Mindspace, Malad (W),

Mumbai – 400064

INDIA

Tel: +91 22 4077 4300

Fax: +91 22 4077 4333

Middle East (Jordan Office)

Comviva Ltd.

Apartment 703, Al Attar Tower

Sheikh Zayed Highway

Dubai

UAE

Tel: +971 43436877, 504544392

Fax: +971 43435448


MComviva_mobiquity_MovilRed_Incomm Code_FSD_v1.0_27092018

Create successful ePaper yourself

Delete template?

Save as template?