ELERAP 264                                                                                                            No. ...
ELERAP 264                                                                                                            No. ...
ELERAP 264                                                                                                           No. o...
ELERAP 264                                                                                                       No. of Pa...
ELERAP 264                                                                                                     No. of Page...
ELERAP 264                                                                                                         No. of ...
ELERAP 264                                                                                                     No. of Page...
ELERAP 264                                                                                                     No. of Page...
ELERAP 264                                                                                                     No. of Page...
ELERAP 264                                                                                                         No. of ...
ELERAP 264                                                                                                     No. of Page...
ELERAP 264                                                                                                     No. of Page...
ELERAP 264                                                                                                     No. of Page...
ELERAP 264                                                                                                     No. of Page...
2007 10 - science direct - a modeling approach and reference models for the analysis of mobile payment use cases
2007 10 - science direct - a modeling approach and reference models for the analysis of mobile payment use cases
2007 10 - science direct - a modeling approach and reference models for the analysis of mobile payment use cases
2007 10 - science direct - a modeling approach and reference models for the analysis of mobile payment use cases
2007 10 - science direct - a modeling approach and reference models for the analysis of mobile payment use cases
2007 10 - science direct - a modeling approach and reference models for the analysis of mobile payment use cases
Upcoming SlideShare
Loading in...5
×

2007 10 - science direct - a modeling approach and reference models for the analysis of mobile payment use cases

1,577

Published on

Published in: Economy & Finance, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,577
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

2007 10 - science direct - a modeling approach and reference models for the analysis of mobile payment use cases

  1. 1. ELERAP 264 No. of Pages 20, Model 5+ ARTICLE IN PRESS 1 August 2007 Disk Used 1 Electronic Commerce Research and Applications xxx (2007) xxx–xxx www.elsevier.com/locate/ecra 2 A modeling approach and reference models for the analysis 3 of mobile payment use cases F 4 Key Pousttchi * OO 5 Mobile Commerce Working Group (wi-mobile), Business Informatics and Systems Engineering, Business School, University of Augsburg, Germany 6 Received 1 December 2006; received in revised form 1 July 2007; accepted 1 July 2007 7 PR 8 Abstract 9 Mobile payments can be categorized according to their usage in each of the five payment scenarios presented here. The paper proposes 10 the mobile payment modeling approach (MPMA) especially suited for value-based analysis of mobile payment use cases. Based on this 11 approach, the study also develops a set of seven reference models that can classify any given mobile payment use case or mobile payment ED 12 procedure and analyze it with regard to the business model, the roles of the market participants, and their interrelation from a value- 13 based perspective. An introspective analysis of the mobile payment service provider role and a market constellation analysis which shows 14 the implications of different actors assuming one or more of the respective roles complete the study. 15 Ó 2007 Elsevier B.V. All rights reserved. CT 16 Keywords: Mobile payments; Mobile payment modeling approach; MPMA; Use case types; Reference models; System analysis; Value exchange diagrams 17 E 18 1. Introduction 2.5G networks by the end of the 1990s made it essential 36 to develop an appropriate form of settlement that possesses 37 RR 19 Since the mid-1990s, serious efforts have been made to the same properties, especially ubiquity, as the mobile 38 20 use mobile phones for business-to-consumer payment offers for which billing occurs. As a result, for the examina- 39 21 transaction processing. This type of processing is referred tion of m-payment procedures, two basic tasks must be dis- 40 22 to as mobile payments or m-payments. For the purposes tinguished. Inside m-commerce, payments for mobile 41 23 of this paper, m-payments are defined as a type of payment services must be implemented in a way that ideally will 42 CO 24 transaction processing in which the payer uses mobile com- be perceived by the user as a seamless part of the system. 43 25 munication techniques in conjunction with mobile devices Outside m-commerce, m-payments become mobile services 44 26 for initiation, authorization, or completion of payment. themselves to provide payment functionality in various sce- 45 27 The first m-payment efforts originated from the fact that narios. These scenarios include payment in stationary 46 28 the mobile phone – due to its specific properties, its wide Internet/e-commerce, payment at vending machines (often 47 UN 29 distribution in the population, and its users’ behavior – is called ‘‘unmanned point-of-sale (POS)’’), payment to a per- 48 30 especially well-suited for payment activities (e.g., [10]). son acting as a merchant or service provider (‘‘manned 49 31 What is more, analysis of mobile banking services shows POS’’, for example, the cashier in a department store, the 50 32 that except for account balance verification, instant pay- pizza delivery person or the taxi driver), and money trans- 51 33 ment is the strongest use case [20]. fer between consumers. As a result, five general payment 52 34 In addition to the attractiveness of the technology, the scenarios can be distinguished (Table 1), a categorization 53 35 appearance of mobile services and mobile commerce with that goes back to Kreyer et al. [12]. 54 The initial stage of this research (MP1), which was based 55 Q1 * Tel.: +49 8230 700445. on the preliminary theoretical work by Kreyer et al. [12] 56 E-mail address: key.pousttchi@wiwi.uni-augsburg.de. and Pousttchi et al. [18] and included a survey with 6200 57 1567-4223/$ - see front matter Ó 2007 Elsevier B.V. All rights reserved. doi:10.1016/j.elerap.2007.07.001 Please cite this article in press as: K. Pousttchi, A modeling approach and reference models for the analysis ..., Electron. Comm. Res. Appl. (2007), doi:10.1016/j.elerap.2007.07.001
  2. 2. ELERAP 264 No. of Pages 20, Model 5+ ARTICLE IN PRESS 1 August 2007 Disk Used 2 K. Pousttchi / Electronic Commerce Research and Applications xxx (2007) xxx–xxx Table 1 Payment scenarios Payment scenario Description M-commerce Mobile applications and services, in particular value-added services E-commerce All kinds of business-to-consumer (B2C) e-commerce with the exception of m-commerce, in particular purchase of goods or services over the Internet Stationary Merchant Classic ‘‘bricks and mortar’’ commerce at a physical point of sale, with transactions between a customer and an automat Automat (e.g., a vending machine) as the agent on the merchant side Stationary Merchant Classic ‘‘bricks and mortar’’ commerce at a physical point of sale with transactions between a customer and a person (e.g., a Person cashier) as the agent on the merchant side Customer-to-Customer Money transfer between persons (end-customers, i.e., consumers) F OO 58 respondents, yielded empirical insights into the importance the payment scenarios and a reference model for each of 103 59 and particular characteristics of each of the scenarios [11]. these can be developed. This set provides a reference point 104 60 Analysis of the development of the market, information for any given m-payment use case or m-payment procedure 105 61 exchange with market participants, and further investiga- and thus constitutes a major part of a complete mobile pay- 106 62 tions led to a differentiated concept based on 40 use cases ment reference model (MPRM), which would, to be com- 107 PR 63 (each defined as a 3-tuple of a payment scenario, a payment plete, require an additional recommendation component. 108 64 amount, and a description of an everyday life situation). (As will be discussed later, this component can be devel- 109 65 This concept provided the foundation for the second study oped only with regard to the basic conditions and particu- 110 66 (MP2), which included a survey with 8295 respondents, lar characteristics of a single market or a group of markets 111 67 resulting in data from more than 30,000 use case assess- with identical conditions.) 112 68 ments [5]. A third study (MP3) was conducted in 2006 on The outcome of this paper is the formulation of MPMA 113 ED 69 a smaller scale (including a survey with 1632 respondents) as a value-based modeling approach especially suited for 114 70 in order to expand upon the MP1 and MP2 results, to analysis of m-payment use cases. A related outcome is an 115 71 answer questions that had been raised by the preceding exhaustive set of reference models that can classify any 116 72 studies, and to explore customer acceptance for new issues m-payment use case or m-payment procedure. The refer- 117 73 such as the acceptance of loyalty schemes in m-payment ence models are helpful in analyzing the use cases and m- 118 CT 74 procedures. These empirical results, together with addi- payment procedures with regard to the business models 119 75 tional theoretical insights into market participants and and roles of the market participants, as well as their inter- 120 76 their behavior [22] and into m-payments inside mobile relation from a value-based perspective.1 121 77 commerce and their intersection with mobile billing [19], The paper is organized as follows: in Section 2, the mod- 122 E 78 form part of the research foundation for the current paper. eling approach is presented, including the methodology to 123 79 A major weakness in current business- and market-ori- develop the reference models. Section 3 presents an analysis 124 RR 80 ented m-payment research is a certain lack of rigor and of the various payment scenarios, the derivation of the use 125 81 comparability. This lack has been observed, not only by case types, and reference models for each type. Section 4 126 82 researchers, but also by practitioners, and contributes con- provides examples of model application, and Section 5 out- 127 83 siderably to the confusion in the m-payment market. How- lines the conclusions and limitations. 128 84 ever, this research area, because of its complexity, is not CO 85 well-suited to the use of formal methods. What is required 2. Mobile payment modeling approach (MPMA) 129 86 is a method that deals with the complexity and particular 87 characteristics of m-payments and related issues and brings This section proposes a mobile payment modeling 130 88 as much rigor as possible to the analysis, but at the same approach (MPMA). The aim is to specify m-payment use 131 89 time can be used both by researchers and practitioners. cases from a value-based perspective in order to be able 132 UN 90 In response to these requirements, this paper proposes a to: (1) analyze m-payment business models from different 133 91 mobile payment modeling approach (MPMA) as a semi-for- perspectives, including those of m-payment service provid- 134 92 mal methodology for the modeling of m-payment use cases ers, of merchants considering acceptance of m-payments, 135 93 and the evaluation of the economic functionality of m-pay- and of customers and companies in related fields, such as 136 94 ment procedures. The MPMA relies on techniques from financial institutions or mobile operations, that may be 137 95 the e3-value model [9] and focuses especially on defining, considering entry into the m-payment market; (2) analyze 138 96 deriving, and analyzing relationships among the various the value chain of m-payment service offers and compare 139 97 roles in the model, along with the partition of these roles 98 in the m-payment value creation network. This approach 99 not only makes economic analysis possible, but also facili- 1 In order to avoid excessive redundancy in this special issue, a complete 100 tates the deduction of requirements for business processes literature survey on m-payments has not been included. For a compre- 101 and system architectures. Using the MPMA, a basic set hensive overview, see Dahlberg et al. [4] and Au and Kauffman [1], both in 102 of seven m-payment use case types can be derived from this special issue. Please cite this article in press as: K. Pousttchi, A modeling approach and reference models for the analysis ..., Electron. Comm. Res. Appl. (2007), doi:10.1016/j.elerap.2007.07.001
  3. 3. ELERAP 264 No. of Pages 20, Model 5+ ARTICLE IN PRESS 1 August 2007 Disk Used K. Pousttchi / Electronic Commerce Research and Applications xxx (2007) xxx–xxx 3 140 different offers; and (3) support the derivation and descrip- 141 tion of m-payment use case types. 142 The MPMA uses the conceptual modeling method of 143 the e3-value ontology [9], extended by use case maps 144 according to Buhr [3].2 This innovative method depicts 145 electronic business models with symbols that are adapted 146 from IT systems analysis, resulting in value exchange dia- 147 grams. The general approach is well-suited for our pur- 148 poses, since it focuses completely on value creation 149 architecture and allows for rigorous analysis. However, F 150 the application of this method for analyzing m-payment 151 use cases requires some modifications. In one example OO 152 the e3-value system only distinguishes actors and value 153 activities. Conversely, the m-payment ecosystem is not only 154 characterized by a high interdependency but also by a par- 155 ticular interplay of actors and their roles which need to be 156 carefully distinguished. For the modeling approach this PR 157 could be reflected by using different layers of value activi- 158 ties. Many m-payment use cases – especially within m-com- 159 merce – would result in diagrams without actors but with 160 actor-like roles which would have to be expressed as value Fig. 1. Modeling primitives for value exchange diagram (black) and use 161 activities which again contain value activities of a lower case map (grey). 162 layer (e.g., acquiring, issuing and transaction processing ED 163 in the case of the mobile payment service provider). Due will dispense with the explicit depiction of these activities 188 164 to the clarity and simplicity of the resulting models (which in the interests of model clarity. 189 165 are used in several industry projects3) we refrained from In addition to actors, it is possible to use roles to aggre- 190 166 this and decided to introduce a role concept as explained gate activities undertaken for the completion of a large and 191 167 below. The roles represent the central concept of the refer- complex task. This approach is essential if there is a high 192 CT 168 ence models as they remain stable throughout the use cases degree of interdependency in a market and if significant 193 169 and even relatively stable throughout the use case types roles can be carried out by different actors (possibly in 194 170 while actors and even value activities within the roles differ. addition to other activities or roles of these actors). In this 195 171 All required modeling primitives for MPMA are shown in case, the roles of the mobile payment service provider or 196 E 172 Fig. 1. the authentication provider might satisfy these criteria. 197 173 The modeling requires three steps. Initially, the actors Roles are represented in a diagram only if necessary. If 198 RR 174 (or roles) and value creation activities must be identified. roles are used, activities are no longer directly assigned to 199 175 In the next step, value exchanges and interfaces are identi- an actor, but to a role, and the role is then assigned to 200 176 fied and assigned. The last step is to model the behavior an actor. If analytically appropriate, the use of both roles 201 177 of the system and draw the use case map. and actors in a diagram is allowed, as well as the exclusive 202 178 An actor is an independent economic entity functioning use of roles instead of actors. 203 CO 179 as a market participant. This actor conducts value creation A value exchange is represented by a directed edge that 204 180 activities in order to increase his utility. In turn, these activ- links a value port within a value interface with another port 205 181 ities can be uniquely assigned to actors. In the context of within a different interface (typically belonging to a differ- 206 182 MPMA, value activities are only used for the analysis of ent actor). The edge is labeled with the name of the value 207 183 value creation within actors or roles. In practical applica- object that is exchanged. A value interface is uniquely 208 UN 184 tion of MPMA, this turned out to be especially interesting assigned to a value creation activity within an actor and 209 185 when it comes to concrete realization concepts and the aim comprises one or more value ports where value objects 210 186 of the analysis stays within organizations (which is often are either received or dispensed, and which provide a con- 211 187 the case in consulting projects). In other cases, the model nection with the underlying business processes associated 212 with the activities. Each exchange relation requires a dis- 213 crete value port. 214 2 The combination of use case maps with value exchange diagrams was For the purpose of modeling m-payment use cases, the 215 proposed by Gordijn and Akkermans [6,7]. More information about e3- concept of use case maps, as defined in Buhr [3], is used 216 value and its combination with use case maps can be obtained on http:// here with the value exchange diagrams as proposed by 217 www.e3value.com/. Gordijn and Akkermans [6,7]. Use case maps provide a 218 3 MPMA is currently used in the SEMOPS (Secure Mobile Payment System) project on a pan-European mobile payment system as well as in way of associating the organizational structure of a com- 219 other projects with various industry partners in order to analyze developed plex system with its behavior. This combination enables 220 as well as developing m-payment markets. one to model, not only the structure, but also the process 221 Please cite this article in press as: K. Pousttchi, A modeling approach and reference models for the analysis ..., Electron. Comm. Res. Appl. (2007), doi:10.1016/j.elerap.2007.07.001
  4. 4. ELERAP 264 No. of Pages 20, Model 5+ ARTICLE IN PRESS 1 August 2007 Disk Used 4 K. Pousttchi / Electronic Commerce Research and Applications xxx (2007) xxx–xxx 222 sequence of the use case. Due to its semi-formal nature, services as well as the purchase of non-digital goods or ser- 271 223 the method does not allow a unique specification of the vices via the mobile channel. 272 224 process sequence, but leads to an intuitive understanding The identifying feature of mobile value-added services is 273 225 which has been found to be a very effective and efficient they deliver content of monetary value. Typical examples 274 226 mode of communication with m-payment practitioners. are news, financial information, and entertainment. In 275 227 The modeling of a process sequence begins at the position many cases, these services are context-sensitive, for exam- 276 228 in the value exchange diagram where the initiating event ple, personalized or location-based. A second kind of 277 229 occurs; this event is marked as a start stimulus. Subse- mobile value-added service originates from the further 278 230 quently, one or more segments are determined that follow use of content in the context of multi-channel strategies, 279 231 the value exchanges that were activated. If in this process for example sporting events or TV shows. With the increas- 280 F 232 a value interface is used for the first time, the segment ing bandwidth and features of mobile terminals, multime- 281 233 subtends that value interface (which afterwards is consid- dia-based offerings will become more and more 282 OO 234 ered to be initialized). Segments can be connected with important. Mobile value-added services are the key area 283 235 AND and OR connectors. The end of the process of m-commerce. Whereas the purchase of non-digital 284 236 sequence is marked by a stop stimulus. The trajectory goods or services via the mobile channel is also a common 285 237 between the start and stop stimuli constitutes the scenario option, its attributes for payment purposes resemble those 286 238 path. of purchase of non-digital goods or services in an e-com- 287 PR 239 For the purposes of MPMA, value exchange diagrams merce environment. 288 240 represent the general structure of an m-payment use case. For mobile value-added services, two offer models can 289 241 Optionally (and depending on the intended purpose of be distinguished: the offer by the mobile network operator 290 242 the model), the dynamics of the model are represented by (MNO) and the direct offer by a mobile content provider 291 243 use case maps. Analysis and modeling in development (MCP). 292 244 and application of the reference models in this article use The offer by the MNO is an MNO-centered solution. 293 ED 245 value exchange diagrams according to the above MPMA The MNO produces mobile content or services itself or 294 246 definitions, including use case maps where appropriate. buys them from a MCP (who acts as a supplier) and thus 295 offers a single face to the customer for network and all 296 247 3. Analysis and reference models other services. An explicit payment process is not neces- 297 sary, because typically only data transmission is charged, 298 CT 248 This section includes an analysis of all payment scenar- and consequently mobile billing is applied in a manner 299 249 ios, identification and discussion of typical use cases, and similar to mobile voice services. This model was (and still 300 250 derivation of seven use case types. For each use case type, is) usual in many markets and documents the market 301 251 a reference model is specified with the help of the MPMA. power of the MNO to inhibit the direct relationship 302 E 252 As the use case types constitute a set that is both exhaustive between customers and mobile content providers. How- 303 253 and disjoint, the resulting set of reference models can clas- ever, this poses some problems for the MNO. Procure- 304 RR 254 sify any given m-payment use case or m-payment proce- ment and offers of content are not normally among 305 255 dure (by means of an indication of which of the use case MNO core competencies, and these can be very complex 306 256 types are supported) and analyze it with regard to the busi- activities (especially if successful offers are to be made 307 257 ness model, the roles of the market participants, and their for different target groups). The result of this effort is 308 258 interrelation from a value-based perspective. mostly only an increased data transmission rate and con- 309 CO 259 Within the reference models, roles rather than actors are sequently improved network capacity utilization. Thus, 310 260 used. This approach is essential for analytical reasons, the offer of high-quality content pays off only in the form 311 261 because virtually any role or combination of roles in the of volume-dependent pricing (and not at all if pricing for 312 262 m-payment market can be assumed by different actors.4 data traffic is flat-rate). To counter this, it is possible to 313 263 The exception is the ‘‘customer’’ actor, which in business- demand additional remuneration for high-quality content. 314 UN 264 to-consumer m-payments is always identical to the role of However, the MNO is relatively unlikely to be able to 315 265 the same name. compete with other actors counting content among their 316 core competencies (i.e., branded content providers with 317 266 3.1. M-payments’ basic task 1: m-payments inside m- an existing customer base like media companies or major 318 267 commerce sports clubs, which often already possess an existing cus- 319 tomer relationship outside of m-commerce). 320 268 The m-commerce scenario reflects the billing and pay- For this reason, the model of direct offer by the MCP, 321 269 ment problem for direct, transaction-dependent sales reve- following the i-mode paradigm from Japan, can be 322 270 nues in m-commerce. This includes mobile value-added expected to prevail more and more in an environment 323 of 2.5G and 3G mobile networks [17]. In this model, 324 the MCP has a direct relationship with the customer 325 4 This has to be distinguished from value activities within roles which are and generates direct revenues by service offers. By means 326 enabled by MPMA but not analyzed in this paper. of the content and quality of its services, the MCP pro- 327 Please cite this article in press as: K. Pousttchi, A modeling approach and reference models for the analysis ..., Electron. Comm. Res. Appl. (2007), doi:10.1016/j.elerap.2007.07.001
  5. 5. ELERAP 264 No. of Pages 20, Model 5+ ARTICLE IN PRESS 1 August 2007 Disk Used K. Pousttchi / Electronic Commerce Research and Applications xxx (2007) xxx–xxx 5 328 vides customers with added value that is paid for by them messaging service) are part of the GSM/GPRS communi- 384 329 in addition to the cost of data transmission. In this model, cations standard,5 but the concept can be applied to other 385 330 the MCP is added to the relationship between the MNO kinds of text or multimedia messages over other network 386 331 and the customer as a so-called third party, whose ser- types as well. The fee for sending (or, as common in some 387 332 vices must be charged for in some manner. Typically, markets, also for receiving) a premium message consists of 388 333 B2C value-added services are charged by the MNO within the regular price plus the additional premium fee which 389 334 its existing billing relationship with its customers; this is reflects the value of the content ordered. An example would 390 335 called third-party billing. This approach is not legally be a soccer world championship goal service where the cus- 391 336 problematic in most countries, as these services are con- tomer has to send a message like ‘‘order last goal’’ to a cer- 392 337 sidered to be telecommunication services in the broader tain number to receive a multimedia message back, 393 F 338 sense, because of the integral role of data transmission including a video clip of the goal. The order message would 394 339 in providing these services. As a result, the MNO per- be charged with the regular message price (e.g., $0.10) plus 395 OO 340 forms data transmission and also acts as a payment ser- a premium fee for the content ordered (e.g., $1.39), result- 396 341 vice provider for the MCP. The fee charged includes the ing in a total price (here $1.49). The premium fee concept 397 342 value of the content as well as the cost of its transmission. underlies the revenue sharing arrangement, and the MNO 398 343 This arrangement, however, results from current market forwards the fee after deducting a compensation for pay- 399 344 conditions, and its continuation in the future cannot be ment handling. In the case of services ordered one at a 400 PR 345 taken for granted. time, charging by premium fee is simple and broadly 401 accepted, although other services demand a more complex 402 346 3.1.1. Current charging approaches for third-party billing application. However, apart from these simple messaging 403 347 There are three basic charging approaches for third- services, the existence of a data volume fee causes accep- 404 348 party billing: sponsoring, premium fee charging, and fixed tance problems on the customer side. On the one hand, cus- 405 349 price charging. tomers do not benefit from a larger transmitted volume. On 406 ED 350 In this context, the sponsoring approach plays a partic- the other hand, most customers are not able to imagine 407 351 ular role. Services are free of charge for customers because how much data, for example, one kilobyte is, and therefore 408 352 they are provided at the mobile content provider’s expense. have the impression that they face an unpredictable price 409 353 The MCP may even pay the MNO for data transmission, for the offer – a major reason not to use the services in 410 354 offering not only the content but even the access to it com- question. Most MNOs prefer this charging approach 411 CT 355 pletely for free to the customer. Up to now, sponsoring because it reflects their core business of data transmission 412 356 models have not been common, but they are becoming and simply enhances it with an additional business. Pre- 413 357 more and more relevant (e.g., in modern mobile marketing mium fee charging provides the basis for the first use case 414 358 concepts such as free video download of a commercial for a type within m-commerce (referred to as Use Case Type 415 E 359 new car model). Sponsoring models are also relevant if ‘‘A’’ in the following discussion). Fig. 2 shows the charging 416 360 business models financed by advertisement are applied, or approach and its value exchanges.6 417 RR 361 if the free service targets the usage of a further service offer In the case of fixed price charging, customers pay a fixed 418 362 which is not free. In spite of the increasing importance of price for their usage of the service. This revenue as a whole 419 363 sponsoring models, they cannot constitute a use case type is shared between MNO and MCP according to an agreed 420 364 for m-payments, as they require no specific payment formula. The problem with this solution lies in the fact that 421 365 procedure. ‘‘real’’ revenue sharing is necessary (whereas beforehand, 422 CO 366 This fact distinguishes the sponsoring concept from the transmission and content were paid for separately). Hence, 423 367 other two charging approaches that are both based on the the ratio must include the transmission cost component of 424 368 principle of revenue sharing between MNO and MCP. The the service. This concept is called ‘‘airtime revenue shar- 425 369 MCP benefits directly from the added value it generates; ing’’ and is viewed as extremely unpleasant by the vast 426 370 the MNO acts as a service provider for the MCP, effecting majority of MNOs, since they hope to compensate for 427 UN 371 data transport and payment handling and being rewarded declining voice revenues with data revenues and thus 428 372 for these services. The structure of this model is similar defend their margins strongly. This can be seen as a 429 373 to wholesaler-to-client sale at the retailer’s request in the short-sighted approach, since the MNOs do not seem to 430 374 retail industry. realize that they are preventing major MCPs such as media 431 375 In the case of premium fee charging, customers pay a companies from providing highly valuable content and for 432 376 data volume fee for transmission (as usual) and addition- 377 ally a so-called premium fee for the value of the content 5 378 or service. The MNO as payee gets the data volume fee More precisely, MMS was specified by the 3GPP/3GPP2 and has been 379 and transfers the premium fee to the MCP after deducting deployed on GSM/GPRS and CDMA networks. SMS on the other hand 380 a compensation for its costs. The simplest example of pre- was part of the original GSM specification. Nowadays SMS has evolved and can be realized over CDMA/AMPS/Satellite and even fixed-line nets. 381 mium fee charging is charging for services by premium 6 Although Figs. 2 and 3 formally use MPMA they stay with actor- 382 SMS or premium MMS, which are very popular in Europe. based analysis in contrast to the role-based approach shown in the 383 SMS (short messaging service) and MMS (multimedia reference models. Please cite this article in press as: K. Pousttchi, A modeling approach and reference models for the analysis ..., Electron. Comm. Res. Appl. (2007), doi:10.1016/j.elerap.2007.07.001
  6. 6. ELERAP 264 No. of Pages 20, Model 5+ ARTICLE IN PRESS 1 August 2007 Disk Used 6 K. Pousttchi / Electronic Commerce Research and Applications xxx (2007) xxx–xxx the MCP (role: mobile payment service provider, or MPSP) 458 have already been identified. Implicitly, these functions 459 also include the task of customer authentication (role: 460 authentication service provider). Furthermore, the service 461 is typically accessed through the portal of the MNO (which 462 is one major basis for the MNO’s strong market power 463 with respect to mobile services). For this reason, the role 464 of furnishing portal access (role: portal provider) must be 465 separated out. 466 By aggregating this actor decomposition with the charg- 467 F ing approaches described above, one can derive the basic 468 structure of the two Use Case Types A and B. 469 OO Use Case Type A represents the purchase or use of digital 470 Fig. 2. Premium fee charging in an actor-based analysis. goods or services in m-commerce with the use of premium fee 471 charging through an m-payment procedure. This requires 472 consideration of the following roles and value exchanges 473 433 these reasons are also discouraging customers from using to define the first reference model: 474 434 these services. From the perspective of MCPs and consum- PR 435 ers alike, the preferred concept is fixed price charging. The – The customer pays a transport fee to the transport ser- 475 436 fixed price charging approach provides the basis for the vice provider and a premium fee to the MPSP. In addi- 476 437 second of the two use case types within m-commerce tion, he pays a basic fee to the MPSP for participation in 477 438 (referred to as Use Case Type ‘‘B’’ in the following discus- the m-payment procedure; typically this fee is paid on an 478 439 sion). Fig. 3 shows the charging approach and its value annual basis (if at all). 479 440 exchanges. ED – The MPSP provides the payment procedure to the cus- 480 tomer as well as to the portal provider. In the course 481 441 3.1.2. Derivation of use case types A and B of payment transaction processing, he provides this ser- 482 442 These two actor-based models arise from market obser- vice to the portal provider and forwards the premium 483 443 vation and constitute the two Use Case Types A and B that fee to the same (the latter service should be kept separate 484 CT 444 exist purely inside m-commerce. However, these models are for analytical reasons). He pays an authentication fee to 485 445 not suitable as a basis for an exhaustive analysis though, the authentication service provider. 486 446 because they include one major hidden assumption: that – The authentication service provider, in turn, provides the 487 447 the MNO ‘‘owns’’ the customer. This means that the rela- verified customer identity to the MPSP. 488 448 tionship between the MNO and the mobile customer is E – The transport service provider provides data transport to 489 449 substantially stronger than the relationship between any the customer and thereby forwards the product to the 490 450 other actor and the customer. Whereas this may (but does RR customer (the latter service should be kept separate for 491 451 not need to) be true in traditional telecommunication busi- analytical reasons). 492 452 nesses, it cannot be taken for granted for mobile value- – The portal provider pays a basic fee to the MPSP for par- 493 453 added services. As a result, the position of the MNO must ticipation in the m-payment procedure; typically this fee 494 454 be decomposed and analyzed with regard to the distinct is paid on a monthly basis. He delivers the product to 495 455 roles which are played. The core competence of the CO the transport provider and pays compensation for pay- 496 456 MNO in providing data transport (role: transport service ment handling to the MPSP, typically as a transaction 497 457 provider) and its additional role in handling payments for fee. He pays compensation to the content provider. 498 – The content provider, in turn, provides the produced and 499 processed7 content to the portal provider. 500 UN Use Case Type A reflects the state-of-the-art in billing of 501 mobile value-added services which are typically ordered 502 by premium SMS and delivered either by one or more 503 SMS or MMS – (which could for instance contain financial 504 news offered by a market-leading journal, pictures or vid- 505 eos of the Super Bowl, adult entertainment content) or 506 by a temporary link for download of a Java application. 507 7 It would be possible, in addition, to separate the role of content aggregator (as proposed by Mueller-Veerse [16]) which aggregates and preprocesses content for use on the mobile channel, but this distinction is Fig. 3. Fixed price charging in an actor-based analysis. neither essential nor beneficial for m-payment analysis. Please cite this article in press as: K. Pousttchi, A modeling approach and reference models for the analysis ..., Electron. Comm. Res. Appl. (2007), doi:10.1016/j.elerap.2007.07.001
  7. 7. ELERAP 264 No. of Pages 20, Model 5+ ARTICLE IN PRESS 1 August 2007 Disk Used K. Pousttchi / Electronic Commerce Research and Applications xxx (2007) xxx–xxx 7 508 The retrieval from mobile websites can also be billed of the participants. The following value exchanges need to 520 509 according to their content (depending on the capabilities be modified: 521 510 of MNO’s billing system). In any case, the price for data 511 transmission is to be paid additionally by the customer. – The customer, instead of paying a premium fee to the 522 512 The complete reference model for Use Case Type A is MPSP and a transport fee to the transport service pro- 523 513 shown in the MPMA diagram in Fig. 4. vider, simply pays a fixed fee to the MPSP and no longer 524 514 Use Case Type B represents the purchase or use of digital receives a specific service called ‘‘data transport’’. 525 515 goods or services in m-commerce with the use of fixed price (Although the purpose of the data transport, to deliver 526 516 charging through an m-payment procedure. The reference the product to the customer, still exists, the transport 527 517 model for this Use Case Type is closely related to that service provider no longer provides this service to the 528 F 518 for Type A. The replacement of the premium fee concept customer, but to the portal provider, because the latter 529 519 by the fixed price concept requires no changes in the roles pays for the data transport). 530 OO PR ED E CT RR CO UN Fig. 4. Reference model for m-payment Use Case Type A. Please cite this article in press as: K. Pousttchi, A modeling approach and reference models for the analysis ..., Electron. Comm. Res. Appl. (2007), doi:10.1016/j.elerap.2007.07.001
  8. 8. ELERAP 264 No. of Pages 20, Model 5+ ARTICLE IN PRESS 1 August 2007 Disk Used 8 K. Pousttchi / Electronic Commerce Research and Applications xxx (2007) xxx–xxx 531 – The MPSP receives, instead of just the premium fee, the payment scenarios (see Table 1). There are a number of 585 532 full fixed fee from the customer and forwards the same m-payment procedures – particularly those with a user 586 533 to the portal provider. interface based on interactive voice response – which are 587 534 – The portal provider, in addition to its existing value specifically targeted to these scenarios and have little or 588 535 exchanges, receives the ‘‘data transport’’ service from no applicability to m-commerce. 589 536 the transport service provider and compensates him. Generally, the analysis of m-payment use cases outside 590 of m-commerce is less complex. One reason in most of 591 537 Use Case Type B reflects a concept which is rarely seen the following use case types is the lower number of roles 592 538 on markets up to now because MNOs have the ability involved. This reason is outranked in importance, however, 593 539 for market access control and use this in order to block by another one that will become evident only in the practi- 594 F 540 any negotiations on fixed price charging (which would cal application of the reference models – the lesser degree 595 541 include airtime revenue sharing). At a first glance this of interdependency of the roles. As for the relevance of 596 OO 542 seems to be a good move as it maintains their margins. the different payment scenarios outside m-commerce, Sta- 597 543 A closer look, however, reveals that this market behavior tionary Merchant Automat clearly outranks all other sce- 598 544 results in damaging the MNOs’ long-term business model. narios from the customer viewpoint, and customer-to- 599 545 It prevents major content providers from considerable customer is least accepted. However, acceptance depends 600 546 investments and small innovative providers of mobile ser- on the particular use case [5]. 601 PR 547 vices from market entry. An additional issue is that the 548 billing of mobile services apart from premium SMS 3.2.1. Payment scenario: e-commerce 602 549 approach is very complex or even not possible with many Compared with m-commerce, e-commerce currently 603 550 operators’ current mobile billing systems. This will only yields higher revenues. However, despite the steadily 604 551 change with the introduction of the IP Multimedia Sub- increasing economic importance of digital goods such as 605 552 system (IMS) as an extension of 3G networks. In any downloadable software or music, the great majority of e- 606 ED 553 case, it can easily be seen how Type B simplifies the model commerce revenue is still obtained from non-digital goods 607 554 for the customer: provided that he already participates in and services such as books or travel [13]. 608 555 an m-payment procedure, he needs only one interface The relative advantage of m-payment usage is recogniz- 609 556 with two ports to use a service – one to receive the prod- able. While m-payment centered studies may be biased on 610 557 uct and one to pay the fee for it. The complete reference this subject, similar results have been obtained in e-pay- 611 CT 558 model for Use Case Type B is shown in the MPMA dia- ment studies. For instance, already in 2003 the IZV6 study, 612 559 gram shown in Fig. 5. ‘‘Payment over the Internet’’, reported very high accep- 613 560 The offer by the MNO model can be regarded as a spe- tance rates [15]: 47.3% of the customers accepted m-pay- 614 561 cial case of Use Case Type A, where all roles except that ments for this purpose, a higher percentage than for 615 E 562 of the customer and the content provider are executed by classic e-payment procedures such as scratch cards 616 563 the MNO as actor. The premium fee, like all basic fees (37.2%) or collection/billing procedures (33.0%). M-pay- 617 RR 564 and the authentication fee, is zero. ments even narrowly outperformed credit cards (47.1%); 618 565 The following discussion examines the payment scenar- a simple e-payment procedure based on online banking 619 566 ios which occur outside the m-commerce environment, and integration received a higher preference rating (64.8%). 620 567 which result in another five use case types. These results were supported by the responses related to 621 purchase amounts: for purchases up to 50€, the study 622 CO 568 3.2. M-payments’ basic task 2: m-payments outside m- found 71.2% acceptance of m-payments; up to 200€, 623 569 commerce 42.1%; and above 200€, still 23.0%. As a result, the accep- 624 tance rates for m-payments in the e-commerce scenario (in 625 570 Outside m-commerce, an m-payment procedure is itself a target group that does not show an inherent m-payment 626 571 a mobile service which provides payment functionality in affinity as those in the MP1–MP3 studies do) must be con- 627 UN 572 different scenarios. In contrast to the m-commerce sce- sidered as extremely high. It can therefore be concluded, 628 573 nario, in its role of providing payment functionality, m- not only that m-payments are relevant to e-commerce, 629 574 payments compete directly against other payment systems but also that the e-commerce scenario is extremely relevant 630 575 such as e-payment, credit/debit card, or cash. According to m-payment procedures. 631 576 to the Rogers diffusion theory [23], the adoption of m-pay- From a value-based perspective, the e-commerce sce- 632 577 ment procedures depends on the availability of a relative nario shows differences for digital and non-digital execu- 633 578 advantage for the respective use case. For a mobile service, tions. In the case of digital execution, value exchanges 634 579 this relative advantage consists of informational value- are related to those in digital executions in the m-commerce 635 580 added ([4] as an extension of Kuhlen [14]), especially scenario, but for non-digital executions (of both the e- and 636 581 through effectiveness or efficiency advantages. m-commerce varieties), value exchanges are close to those 637 582 The basic m-payments’ task outside m-commerce com- in the stationary merchant scenarios. Since the value 638 583 prises the e-commerce, Stationary Merchant Automat, Sta- exchanges no longer differ within the two areas, the conclu- 639 584 tionary Merchant Person, and customer-to-customer sion is that the corresponding use case types are indeed 640 Please cite this article in press as: K. Pousttchi, A modeling approach and reference models for the analysis ..., Electron. Comm. Res. Appl. (2007), doi:10.1016/j.elerap.2007.07.001
  9. 9. ELERAP 264 No. of Pages 20, Model 5+ ARTICLE IN PRESS 1 August 2007 Disk Used K. Pousttchi / Electronic Commerce Research and Applications xxx (2007) xxx–xxx 9 F OO PR ED E CT RR CO Fig. 5. Reference model for m-payment Use Case Type B. UN 641 atomic entities. As a result, Use Case Types C and D can pays a basic fee to the MPSP for participation in the 653 642 now be derived. m-payment procedure; typically this fee is paid on an 654 643 Use Case Type C represents the purchase or use of digital annual basis (if at all). 655 644 goods or services in e-commerce with the related use of an m- – The MPSP provides the payment procedure to the cus- 656 645 payment procedure. The necessary roles in the model are tomer as well as to the portal provider. In the course of 657 646 identical to those for Types A and B, although the under- payment transaction processing, he provides this service 658 647 standing of their characteristics (including the much lower to the portal provider and forwards the price to the 659 648 interdependency) must be aligned to e-commerce, and the same. He pays an authentication fee to the authentica- 660 649 value exchanges also must be adapted: tion service provider. 661 – The authentication service provider, in turn, provides the 662 650 – The customer pays a transport fee to the transport ser- verified customer identity to the MPSP. Use of a built-in 663 651 vice provider and a product price to the MPSP. Addi- authentication procedure, as in m-commerce, is no 664 652 tionally, and similarly to all other use case types, he longer possible in e-commerce. 665 Please cite this article in press as: K. Pousttchi, A modeling approach and reference models for the analysis ..., Electron. Comm. Res. Appl. (2007), doi:10.1016/j.elerap.2007.07.001
  10. 10. ELERAP 264 No. of Pages 20, Model 5+ ARTICLE IN PRESS 1 August 2007 Disk Used 10 K. Pousttchi / Electronic Commerce Research and Applications xxx (2007) xxx–xxx 666 – The role of transport service provider must be under- complete reference model for Use Case Type D is shown 717 667 stood as that of an Internet service provider (ISP) for in the MPMA diagram in Fig. 7. 718 668 the customer, who provides solely data transport and 669 thereby forwards the product to the customer. This 3.2.2. Payment scenario: Stationary Merchant Automat 719 670 function can be carried out by anyone having stationary The Stationary Merchant Automat payment scenario is 720 671 Internet access, including even wireless access techniques highly relevant to m-payments as in this scenario it is easy 721 672 such as WiFi/WiMAX if no mobile device is involved, to achieve advantages relative to other payment methods. 722 673 and therefore e-commerce characteristics apply instead This is especially true for cash payment, but still valid when 723 674 of m-commerce. For instance, in this context, a laptop the automat accepts credit or debit cards. Empirical studies 724 675 computer is not considered to be a mobile device. of customer preferences indicate Stationary Merchant 725 F 676 – The role of portal provider is not limited to specialized Automat to be generally the highest-ranked payment sce- 726 677 portal providers such as Yahoo! in the stationary Inter- nario [5,11]. The market for automats is usually classified 727 OO 678 net. For the purposes of this work, it is defined by the into three groups according to machine type. Entertainment 728 679 function of an intermediary in the purchase of digital machines provide leisure activities and various kinds of 729 680 goods and services, so that it can be a company website entertainment. This category includes all kinds of sports 730 681 as well.8 This portal provider pays a basic fee to the machines, pinball machines, and gambling machines. Ser- 731 682 MPSP for participation in the m-payment procedure; vice machines offer diverse kinds of services and non-tangi- 732 PR 683 typically this fee is paid on a monthly basis. He delivers ble goods like parking tickets or admission control. 733 684 the product to the transport provider and pays compen- Vending machines sell all kinds of tangible goods like food, 734 685 sation for payment handling to the MPSP, typically as a cigarettes, or other kinds of everyday consumer goods. 735 686 transaction fee. He also pays compensation to the con- However, these three machine types do not exhibit differ- 736 687 tent provider. ences when it comes to value exchanges. At most, they 737 688 – The content provider, like his equivalent in m-commerce, can be differentiated by operating mode. On the one hand, 738 ED 689 provides the produced content to the portal provider. this would require a detailed analysis of the details of the 739 vending machine industry. On the other, some of these 740 690 A typical example for Use Case Type C is the download of details were examined in depth and they do not appear 741 691 music or software from the Internet. The customer uses an to impose essential restrictions on the model. As a result, 742 692 m-payment procedure to pay the product price to the shop one single use case type can represent this payment 743 CT 693 owner plus the data transport (which could also be scenario. 744 694 included in a flat fee) directly to his Internet service pro- Use Case Type E represents the purchase of goods or ser- 745 695 vider. The complete reference model for Use Case Type vices at a physical point of sale – in the case that an automat 746 696 C is shown in the MPMA diagram in Fig. 6. acts as agent on the merchant side – with the use of an m- 747 E 697 Use Case Type D represents the purchase of non-digital payment procedure. The roles include not only the mer- 748 698 goods or services in e-commerce or m-commerce, with the chant, but also another major role required exclusively in 749 RR 699 use of an m-payment procedure. the vending industry, the site owner, who provides the site 750 700 Non-digital goods were excluded previously due to the for the automat and usually gets a revenue share in 751 701 similarity of m-commerce and e-commerce in this case. exchange (or sometimes a fixed site rent). As the vending 752 702 As the execution is non-digital and thus occurs outside machine business is often low-margin, this revenue share 753 703 the model, neither transport service (if necessary at all) can be essential to the economic feasibility for the mer- 754 CO 704 nor procurement is part of the analysis. The remaining chant to apply an m-payment procedure. Additionally, 755 705 roles, including that of merchant, interact in an easily com- the site owner may limit the usage of certain mobile com- 756 706 prehensible manner. munication techniques, which would result in the infeasibil- 757 707 A typical example for Use Case Type D would be the ity of m-payment procedures relying on them. 758 708 ordering of books or CDs via e- or m-commerce. The latter Typical examples for Use Case Type E are ticket 759 UN 709 could be a mobile viral marketing campaign with a click- machines, parking meters, cigarette machines, safe deposit 760 710 to-order option, a mobile game with the option to order boxes and all other kinds of automatic vending machines 761 711 the music CD, or a mobile handset enabled with near-field where the use of cash is awkward for the customer and 762 712 communication that allows for ordering via just touching costly to the merchant. In developed markets, these appli- 763 713 an advertising poster. In e-commerce as well it is often con- cations show very high acceptance rates with customers. In 764 714 venient to use m-payments, especially when the customers other markets, sometimes only m-payments will enable the 765 715 orders from an unknown merchant or uses public Internet vending machine business. An example for this is Egypt, 766 716 access and don’t want to enter his credit card details. The where the value of coins is too low to use them in vending 767 machines. In addition, most banknotes are so old and 768 8 creased that they cannot be recognized automatically. Also 769 For purposes of this paper, any function of intermediary or direct vendor of digital goods and services in m- or e-commerce is called a portal the penetration of bank cards is very low. The complete ref- 770 provider and any intermediary or direct vendor of non-digital goods and erence model for Use Case Type E is shown in the MPMA 771 services a merchant. diagram in Fig. 8. 772 Please cite this article in press as: K. Pousttchi, A modeling approach and reference models for the analysis ..., Electron. Comm. Res. Appl. (2007), doi:10.1016/j.elerap.2007.07.001
  11. 11. ELERAP 264 No. of Pages 20, Model 5+ ARTICLE IN PRESS 1 August 2007 Disk Used K. Pousttchi / Electronic Commerce Research and Applications xxx (2007) xxx–xxx 11 F OO PR ED E CT RR CO Fig. 6. Reference model for m-payment Use Case Type C. UN 773 3.2.3. Payment scenario: Stationary Merchant Person times will be considered. Within the payment scenario 786 774 With respect to revenue potential, the Stationary Mer- itself, there are no major differences from the value-based 787 775 chant Person payment scenario is far ahead of the other view. As a result, this payment scenario may also be repre- 788 776 payment scenarios. However, one must note the existence sented by one single use case type. 789 777 of well-established payment systems like cash or credit/ Use Case Type F represents the purchase of goods or ser- 790 778 debit cards, which poses a major difficulty for m-payment vices at a physical point of sale – in the case that a person 791 779 procedures to achieve a sufficient relative advantage. An acts as agent on the merchant side – with the use of an m- 792 780 additional consideration which is essential for a merchant’s payment procedure. Type F exhibits a clear similarity to 793 781 acceptance of a point-of-sale payment system is the dura- Type E. The exception is that the role of site owner is not 794 782 tion of a payment transaction. Especially for merchants required here, and the absence of the limitations this role 795 783 concentrating on mass market sales (such as large depart- brought into the Type E model. The role of merchant can 796 784 ment stores or supermarkets, in particular discounters) be fulfilled by any merchant or service provider who acts 797 785 only m-payment procedures with extremely low response in physical contact with the customer. Typical examples 798 Please cite this article in press as: K. Pousttchi, A modeling approach and reference models for the analysis ..., Electron. Comm. Res. Appl. (2007), doi:10.1016/j.elerap.2007.07.001
  12. 12. ELERAP 264 No. of Pages 20, Model 5+ ARTICLE IN PRESS 1 August 2007 Disk Used 12 K. Pousttchi / Electronic Commerce Research and Applications xxx (2007) xxx–xxx F OO PR ED CT Fig. 7. Reference model for m-payment Use Case Type D. 799 for Use Case Type F are m-payments in filling stations or In any event, a separate use case type is required here in 824 E 800 supermarkets. In developed markets this is a relatively order to make the set of use case types exhaustive. 825 801 weak use case as there are custom payment systems in place Use Case Type G represents the transfer of money 826 RR 802 such as debit or credit cards which are already perceived to between consumers with the use of an m-payment procedure. 827 803 be convenient by the user. However, it is often a customer The Type G model is entirely different from all the other 828 804 requirement to provide an m-payment system which is models, as it requires only the customer (and more than 829 805 usable for all scenarios alike. Furthermore, the significance one is involved in a transaction, which we implied by the 830 806 of Use Case Type F totally changes when it comes to devel- repeated drawing of the actor) and the roles of MPSP 831 CO 807 oping markets without a high-level banking infrastructure. and authentication service provider. For a number of m- 832 808 The complete reference model for Use Case Type F is payment procedures, the latter two roles can even be car- 833 809 shown in the MPMA diagram in Fig. 9. ried out by the same actor, which again would simplify 834 the model. A prominent example for Use Case Type G 835 810 3.2.4. Payment scenario: customer-to-customer was the well-known m-payment procedure Paybox in Ger- 836 UN 811 In developed markets, customers often attach the lowest many which was broadly used for the payment of E-Bay 837 812 importance to the customer-to-customer scenario [5,11]. transactions between consumers, a less well-known (but 838 813 There are a few scenarios in which m-payment usage very typical one for developing markets) is the GXchange 839 814 achieves a sufficient relative advantage and therefore a rea- m-payment procedure on the Philippines. The complete 840 815 sonable acceptance level; this is not always the case for reference model for Use Case Type G is shown in the 841 816 innovative forms of technology application [5]. In addition, MPMA diagram in Fig. 10. 842 817 some MPSPs do not offer customer-to-customer payments Use Case Type G completes the set. In summary, the 843 818 due to the particular characteristics of the scenario, espe- importance of m-payments outside m-commerce is lower 844 819 cially if consumers’ willingness to pay a fee is low (as, than that within m-commerce. However, the outlook for 845 820 e.g., in Germany). Here again, the lack of importance of m-payment adoption is promising wherever it can achieve 846 821 the scenario highly depends on the existence of a high-level relative advantages in comparison with traditional pay- 847 822 banking infrastructure in a market (i.e., the percentage of ment systems. This is almost universally true in the Station- 848 823 the population owning a current account with a bank). ary Merchant Automat scenario, true in broad parts of the 849 Please cite this article in press as: K. Pousttchi, A modeling approach and reference models for the analysis ..., Electron. Comm. Res. Appl. (2007), doi:10.1016/j.elerap.2007.07.001
  13. 13. ELERAP 264 No. of Pages 20, Model 5+ ARTICLE IN PRESS 1 August 2007 Disk Used K. Pousttchi / Electronic Commerce Research and Applications xxx (2007) xxx–xxx 13 F OO PR ED E CT Fig. 8. Reference model for m-payment Use Case Type E. RR 850 e-commerce scenario, and still true in some use cases of the bound to their native environment. As a result of this gen- 869 851 Stationary Merchant Person and customer-to-customer eric applicability in entirely different environments, it can 870 852 scenarios. Use Case Types C to G were derived from these be noticed that only those two roles are necessary through- 871 853 payment scenarios. In the following section, the use case out all use cases which are directly involved in the process- 872 854 types and their reference models will be employed for ing of the m-payment. Besides the mobile payment service 873 CO 855 analysis. provider and the authentication service provider, the whole 874 environment is changing. 875 856 4. Application of the reference models The transport service provider is only to be considered if 876 transport of the product occurs on the same channel as the 877 857 In this section, the use case types and their reference m-payment information (i.e., if the product is mobile digi- 878 UN 858 models will be employed for two types of analysis. One is tal content). The portal provider, including any type of dig- 879 859 an introspective analysis of the central role of the mobile ital merchant, as well as the content provider is to be 880 860 payment service provider. The other is a market constella- considered only if the product is digital; if not, a traditional 881 861 tion analysis which shows the implications of different merchant is to be considered. For Use Case Type G, both 882 862 actors assuming one or more of the respective roles. It also are unnecessary. Use Case Type E requires the site owner 883 863 explores different concentrations of market power to the as an additional role. A survey of the appearance of the 884 864 mobile payment market. roles is given in Table 2. 885 On the one hand, this may be one explanation why a 886 865 4.1. Introspective analysis successful m-payment is so difficult to realize and requires 887 an amount of research that other types of payment do not. 888 866 A major characteristic of m-payments is that they are On the other hand, this makes the role of the mobile pay- 889 867 uniquely qualified to be used in all existing payment scenar- ment service provider the most important one in the refer- 890 868 ios whereas all other types of payment are more or less ence models (as the authentication service provider role is 891 Please cite this article in press as: K. Pousttchi, A modeling approach and reference models for the analysis ..., Electron. Comm. Res. Appl. (2007), doi:10.1016/j.elerap.2007.07.001
  14. 14. ELERAP 264 No. of Pages 20, Model 5+ ARTICLE IN PRESS 1 August 2007 Disk Used 14 K. Pousttchi / Electronic Commerce Research and Applications xxx (2007) xxx–xxx F OO PR ED Fig. 9. Reference model for m-payment Use Case Type F. E CT RR CO UN Fig. 10. Reference model for m-payment Use Case Type G. 892 often hardly-fought between financial institutions and The analytic strength of the MPMA role concept and 896 893 MNO but anyhow remains subordinated). Thus, an intro- the according reference models provides stability of the 897 894 spective analysis of the mobile payment service provider is roles and their value ports throughout all use case types 898 895 of particular interest. they appear in. This allows for unitary analysis of the 899 Please cite this article in press as: K. Pousttchi, A modeling approach and reference models for the analysis ..., Electron. Comm. Res. Appl. (2007), doi:10.1016/j.elerap.2007.07.001

×