VF - Third Party Charging Version 1.0.pdf

Transcript

1. Third Party Charging Process Version 1.0
2. Third Party Billing Process Copyright © 2011 IMImobile Pvt. Ltd. All Rights Reserved Though every care has been taken to ensure the accuracy of this document, IMImobile cannot accept responsibility for any errors or omissions or for any loss occasioned to any person, whether legal or natural, from acting, or refraining from action, as a result of the information contained herein. Information in this document is subject to change at any time without obligation to notify any person of such changes. IMImobile may have patents or patent pending applications, trademarks copyrights or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give the recipient or reader any license to these patents, trademarks, copyrights or other intellectual property rights. No part of this document may be communicated, distributed, reproduced or transmitted in any form or by any means, electronic, mechanical, or otherwise, for any purpose, without the prior written permission of IMImobile. IMImobile Confidential Page | ii About IMImobile IMImobile is a global technology partner for operators, media companies and enterprises. The IMImobile products and services portfolio is built on a core modular service platform called the DaVinci Evolved Service Platform. The platform provides an integrated and flexible range of CRM, messaging, rich media content and advertising solutions. It also provides a series of interfaces to enable a mobile marketplace and an ecosystem of application developers. With technology designed for rapid deployment and revenue generation, IMImobile is working with leading operators, content owners and media owners including Airtel, Aircel, Vodafone, BSNL, MTN, Reliance, Millicom, Virgin Mobile, Tata, Mobitel, Star TV, Meteor, Reuters, Yahoo, Google, EMI Music, Universal Music, Sony and Warner Music. IMImobile has operations and offices in Asia, Europe, Latin America and the Middle East. The company today serves 80 Operators in 70 countries, manages 330 unique revenue generating services, generates 150 million billing transactions each month and partners with 350 content providers worldwide. For more information, visit: www.imimobile.com For Sales queries, e-mail us at: sales@imimobile.com
3. Third Party Billing Process IMImobile Confidential Page | iii DOCUMENT RELEASE NOTE Knowledge Source : Sridhar Reddy Author(s): Sreechitra.k Reviewer(s): Sumana.v Value Adder: Status (In Draft, In Review, Stable): In Draft Release Date 20-09-2011 Applicable Version 1.0 Approved by: Badrinath.R, Richard Ward REVISION HISTORY Revision No Date of Revision Change Details 1.1 1.2 1.3 1.4
4. Third Party Billing Process IMImobile Confidential Page | iv Table of Contents 1. Document Scope and Audience ........................................................................ 5 2. Third Party Billing Flow .................................................................................... 5 2.1. Mobile Handset – Initiating Action ............................................................. 6 2.2. Vendor Application – Calling useridentify.aspx .......................................... 6 2.3. IMI Charging Application - Creating Transaction ID ................................... 7 2.4. Vendor Application - Transferring Transaction ID ...................................... 9 2.5. IMI Charging Application – Identifying Billing Value ............................... 10 2.6. Vendor Application – Sending Billing Status ............................................ 10 2.7. IMI Charging Application – Redirecting the URL ...................................... 10 3. Prerequisites .................................................................................................. 10
5. Third Party Billing Process IMI/API/Third Party Billing Process/Version1.0 Page | 5 1. Document Scope and Audience The scope of this document is to understand the procedure for charging the mobile users of Vodafone UK. This document is intended for the third party vendors who are not authorized to directly bill the mobile users. 2. Third Party Billing Flow Charging a mobile user for all actions performed while browsing the Mobile Internet Portal through a handset is handled by a Third party/Vendor Application. In case the Vendor is not authorized to directly bill the user, the IMImobile’s Charging Application charges the mobile user. This section describes the Charging flow adopted by the IMImobile charging platform to charge a mobile user on behalf of a third party vendor.
6. Third Party Billing Process IMI/API/Third Party Billing Process/Version1.0 Page | 6 2.1. Mobile Handset – Initiating Action 1. User’s request lands on the Vendor Application. 2.2. Vendor Application – Calling useridentify.aspx 2. The Vendor Application calls useridentify.aspx with parameters. The table below lists the parameters and their definitions (all the parameters are mandatory EXCEPT for the request channel).
7. Third Party Billing Process IMI/API/Third Party Billing Process/Version1.0 Page | 7 Table 1: Table below illustrates the parameters in the useridentify.aspx and their descriptions. Parameters Description auid Unique id (for content type, price code and operator). Ip User host IP address ua Full user agent name from which the user is browsing. Burl Back url provided by vendor to transfer after the billing transaction completed irrespective of billing status. Vid to identify from which vendor the request is coming Vtid Vendor transaction id (to identify the vendor transaction) contenturl actual content url for download reqchnl Request Channel cmode This would be used while testing the charging API, We can set the value as “test” for testing the charging API, By default it would be considered as live. Note: There are two methods to use the service: Directly call .aspx as a parameter. Or Create an object and pass the required parameters. 2.3. IMI Charging Application - Creating Transaction ID 3. The IMI Charging Application creates a Transaction ID irrespective of receiving the user identity parameters. The parameters are then validated and saved irrespective of its status (success/fail). The application then sends the response in the same session in a predefined format to the vendor application.
8. Third Party Billing Process IMI/API/Third Party Billing Process/Version1.0 Page | 8 Below is the request format from vendor: https://<chargingdomain>/ChargingAPI/UserIdentity.aspx?vid=<vendorid>&auid=<authen tication id>&ua=<user agent name>&burl=<back url to transfer>&vtid=<vendor transaction id>&contenturl=<content url> Sample URL: https://<chargingdomain>/ChargingAPI/UserIdentity.aspx?vid=3887175b-81ad-447f-a205- f27b3c73b324&auid=6946e9f0-8038-461d-843a- 7e4a0c457e7c&ua=mozilla&burl=http://imimobile.com&vtid=3887175b-81ad-447f-a205- f27b3c73b324&contenturl=http://imimobile.com Below is the predefined format of the response for success: <response> <transactionid>3887175b-81ad-447f-a205-f27b3c73b321</transactionid> <redirecturl>http://<chagingdomain>/billing.aspx?tid=3887175b-81ad-447f-a205- f27b3c73b321</redirecturl> <status>success</status> <errormessage></errormessage> <errorcode></errorcode> </response> Below is the predefined format of the response for failure: <response> <transactionid>3887175b-81ad-447f-a205-f27b3c73b321</transactionid> <redirecturl></redirecturl> <status>fail</status> <errormessage>Error Message</errormessage> <errorcode>Error Code</errorcode> </response>
9. Third Party Billing Process IMI/API/Third Party Billing Process/Version1.0 Page | 9 Table 2: The following table illustrates error codes and messages that are generated for invalid parameters. Error Code Message Invalid Messages 1001 Invalid billing authentication ID. 1003 Invalid host IP address. 1007 Invalid vendor ID. Missing Messages 1002 Billing authentication id is missing. 1004 Host IP address is missing. 1005 Device name is missing. 1006 Transfer URL is missing. 1008 Vendor ID is missing. 1009 Vendor transaction ID is missing. 1010 Download content URL is missing. 2.4. Vendor Application - Transferring Transaction ID 4. The Vendor Application transfers the redirect URL through the handset to the IMI Charging Application. This enables the Charging Application to receive the Transaction ID (refer step 3) and identifies the mobile number of the handset from the headers. Below is the Redirect url format: http://<chargingdomain>/ChargingAPI/billing.aspx?tid=<transactionidsharedinresponse>
10. Third Party Billing Process IMI/API/Third Party Billing Process/Version1.0 Page | 10 Sample URL: http://<chargingdomain>/ChargingAPI/billing.aspx?tid=dad6ef67-022a-4906-826d- 5c8a6890c7da 2.5. IMI Charging Application – Identifying Billing Value 5. The Charging Application then identifies the billing value based on the transaction ID configurations and calls the IMImobile Charging Application with the parameters. 6. After receiving the billing status, the Charging Application notifies the Vendor Application with the following parameters: a. tid: Refers to the Transaction ID. b. mobileno: Refers to the mobile number of the user. c. status: Refers to the billing status. 2.6. Vendor Application – Sending Billing Status 7. The Vendor Application sends the response as, a. 200 OK: Success b. Fail: Failure 2.7. IMI Charging Application – Redirecting the URL 8. The IMI Charging Application then redirects the url to the burl (specified in table 1 of step 2). 3. Prerequisites 1. Clearing of the Vendor IP address to access the charging API 2. Sharing of Price points for the different content types for charging across different Telcos. 3. Vendor would receive “auid” for charging API post the Vendor IP is cleared 4. Notify URL to notify the status