Your SlideShare is downloading. ×
2007 10 - science direct - a modeling approach and reference models for the analysis of mobile payment use cases
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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


Published on

Published in: Economy & Finance, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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 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: 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. 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. 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 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  • 15. 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 15 Table 2 or integration of IT systems the strategic element in this 926 Appearance of roles in the Use Case Types process is to acquire a critical mass of market participants 927 Use Case Type role A B C D E F G to accept the payment procedure. As the relevant market 928 MPSP · · · · · · · participants directly depend on the use case type and the 929 Authentication service provider · · · · · · · relative competitive strength of different actors performing 930 Transport service provider · · the MPSP role depends on the relevant market participants 931 Portal Provider · · · Merchant · · · it is possible to specify the relative strength according to the 932 Content Provider · · · use case type: For Use Case Types A, B and C these rele- 933 Site Owner · vant market participants are portal providers in m-com- 934 merce and e-commerce, including any type of digital 935 F merchant. These companies, often small and medium 936 900 mobile payment service provider role in all seven use case enterprises or even startups, have typically closer relation- 937 OO 901 types. Although the prior construction of the use case types ships (and often even existing business connections) to 938 902 was developed from single value activities, the introspective mobile network operators than to traditional payment ser- 939 903 analysis identifies these use case types top-down within the vice providers. Thus, for these three use case type a relative 940 904 role. Their examination allows for different insights into advantage for mobile network operators in the MPSP role 941 905 the associated value flows and reveals the major influence has to be stated. This can easily be seen for virtually any 942 factors on the role itself. For the role of the mobile pay- PR 906 type of mobile service as these are typically billed via the 943 907 ment service provider three primary value activities can mobile phone bill. 944 908 be derived: For Use Case Types D, E and F, the relevant market 945 participants are traditional merchants. These come out of 946 909 – establishment and support of a contractual relationship the brick-and-mortar business. Even if they do e-distribu- 947 910 to merchants or portal providers participating in the tion as in Use Case Type D, these firms have established 948 ED 911 payment procedure, that is accepting the mobile pay- long-term business relationships with the traditional pay- 949 912 ment procedure for payment of their services (acquiring), ment service providers from the banking and credit card 950 913 – establishment and support of a contractual relationship industry. In markets with a well-developed financial infra- 951 914 to customers participating in the payment procedure, structure and market power for these institutions, it is dif- 952 915 that is using the procedure for their payments (issuing), ficult for an MNO to compete with the banks or the credit 953 CT 916 – processing of payment transactions (transaction card companies in the MPSP role in these use case types. 954 917 processing). This is true for strong alliances of MNOs, such as Simpay. 955 This alliance started with the intention to cover Use Case 956 918 These value activities are relevant to any of the use case Types A to F. In the course of its activities and the ensuing 957 E 919 types except for acquiring in Use Case Type G where no competition, Simpay reduced its activities to Use Case 958 920 merchant or portal provider is involved. The resulting Types A, B and C. For Use Case Type G, acquiring is 959 abstract refinement of the mobile payment service provider RR 921 not a relevant factor. Specialized m-payment intermediar- 960 922 role is presented in Fig. 11. ies face a demanding challenge if they are to compete. Their 961 923 Acquiring exchanges the general participation in the major chance is that MNO or financial institutions either 962 924 payment procedure for a basic fee.Although this includes stay inactive or annoy market participants with prohibitive 963 925 a lot of technical elements such as negotiation of contracts conditions. 964 CO Issuing also exchanges the general participation in the 965 payment procedure for a basic fee. This includes techni- 966 cal elements such as customer service or the provision of 967 access to the service, for instance by a Java client or an 968 Unstructured Supplementary Services Data (USSD) pro- 969 UN cedure. USSD is a technique for mobile services in the 970 GSM standard. Analogous to the acquiring process, 971 however, the strategic element in this process is to win 972 a critical mass of customers to issue an m-payment 973 account to them. For issuing, financial institutions as 974 well as MNOs can build on their existing customer base 975 which gives them a major competitive advantage over 976 specialized m-payment intermediaries that have to set 977 up a completely new customer base. The same is true 978 for the brand. Generally, customers in developed markets 979 have clear preferences in the issue which actor should 980 fulfill the MPSP role; these preferences depend on the 981 Fig. 11. Value activities and influence factors on the MPSP role. use case type. Typically, trust and security issues as well 982 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
  • 16. ELERAP 264 No. of Pages 20, Model 5+ ARTICLE IN PRESS 1 August 2007 Disk Used 16 K. Pousttchi / Electronic Commerce Research and Applications xxx (2007) xxx–xxx 983 as existing payment habits lead customers to a preference Transaction Processing generally receives a payment 1030 984 for financial institutions. However, the more the good or amount from the payer and forwards it to the payee. 1031 985 service is related to the mobile market, the more they are For this performance of payment handling, a transaction 1032 986 willing to accept the MNO as mobile payment service fee is exchanged. The type of transaction varies with the 1033 987 provider.9 use case type. For instance, while in Use Case Type A 1034 988 The problem for the MNO is, however, that an m-pay- only the premium fee is routed over the MPSP, the trans- 1035 989 ment procedure which comprises more use case types than action amount in Use Case Type B comprises the data 1036 990 A, B, and C is merely seen as a payment tool than as a transport as well. This difference is of interest when com- 1037 991 mobile service, a fact that clearly favors banks and credit paring the transaction volumes of different MPSPs on the 1038 992 card companies. VISA and MasterCard both show efforts market. Another difference stems from transaction 1039 F 993 to draw benefit out of this. On the other hand, in devel- amounts: Macropayments require a high level of security, 1040 994 oping countries with a high percentage of unbanked cus- including not only strong authentication and protection 1041 OO 995 tomers, MNOs find themselves in an extremely against third party attacks but also creditworthiness check 1042 996 advantageous position. In addition to several individual and fraud management. This is the clear competency of 1043 997 MNO projects, in early 2007 the GSM association10 banks, credit card companies or specialized payment ser- 1044 998 started a major effort in this market segment. The issuing vice providers. To entrust this to MNOs can not really 1045 999 question is especially suited to foster alliances. In some be recommended – neither recommended to the merchants 1046 PR 1000 countries, alliances of banks and MNOs can be found; nor to the MNO itself. What is more, legal or regulatory 1047 1001 a good example is Mobipay in Spain (including all Span- restrictions in many markets prevent MNOs from execut- 1048 1002 ish MNOs and all major Spanish banks), an interesting ing these transactions, especially outside Use Case Types 1049 1003 effort of the European Union to establish a pan-European A, B, or D. That is a major reason for MNOs, for exam- 1050 1004 system open to all banks and MNOs can be seen in the ple in the US, not to offer respective services while other 1051 1005 SEMOPS project (Secure Mobile Payment Service).11 Spe- MNOs such as NTT DoCoMo in Japan are more open to 1052 ED 1006 cialized m-payment intermediaries, due to the fact that m- this. Micropayments require a lower security level but are 1053 1007 payment is their core business, are often perceived as challenging in terms of cost-efficiency. Current transaction 1054 1008 more customer-friendly and technologically progressive systems of banks do often not allow profitable transaction 1055 1009 than MNOs and financial institutions. However, due to processing for micropayments whereas MNOs could be 1056 1010 the above facts their competitive position in issuing is dif- able to do so. The authentication method and the related 1057 CT 1011 ficult in many markets. value flows to the Authentication Service Provider are of 1058 1012 A unique way to a critical mass in issuance can be interest for macropayments. This is not the case for 1059 1013 observed in Austria. One of the most well-known special- micropayments – often resulting in a simple MS ISDN 1060 1014 ized m-payment intermediary brands worldwide, Paybox authentication for these. Although there is no general 1061 E 1015 Austria, came into the ownership of the major MNO, assignment between transaction amounts and use case 1062 1016 Mobilkom. As a second step, Mobilkom founded its own types, we can indicate typical amounts in Use Case Types 1063 RR 1017 banking brand, the A1 bank, for their m-payment activi- A, B, D, and E to be found more likely in the area of 1064 1018 ties. The resulting m-payment procedure is popular in this micropayments and in Use Case Types C, F, and G in 1065 1019 market. In Use Case Types C to G, Mobilkom is generally the area of macropayments. 1066 1020 already able to offer their services to all Austrian custom- Fig. 11 does not show the exchanges between the differ- 1067 1021 ers. The operation is not successful for Use Case Type F. ent value activities within the MPSP role. These would 1068 CO 1022 This use case type outclasses all other use case types in become relevant and should be included if internal offset 1069 1023 terms of revenue, and is the major stronghold of traditional is subject to examination, especially if either the basic fee 1070 1024 payment service providers. Currently, Mobilkom is encour- or the transaction fee is equal to zero. 1071 1025 aging the other MNOs to join its operation, to extend its 1026 offerings in Use Case Types A and B to non-Mobilkom 4.2. Market constellation analysis 1072 UN 1027 customers. This will enable Mobilkom to obtain a strong 1028 issuance position and acquire traditional merchants for The introspective analysis we have conducted started at 1073 1029 Use Case Type F.12 the abstraction level of the reference models and then pro- 1074 ceeded to a lower abstraction level with an in-depth anal- 1075 ysis of the MPSP role. The analysis in this section also 1076 9 Empirical data on customers’ MPSP preferences for different use case starts at the abstraction level of the reference models 1077 types can be found in Eisenmann et al. [5]. but proceeds to a higher level with an analysis of the dif- 1078 10 The GSM association (GSMA) is a global trade association repre- ferent market constellations as instantiations of the use 1079 senting over 700 GSM mobile phone operators across 218 countries case types. 1080 ( The Use Case Types A to G are both disjoint and 1081 11 More information on the SEMOPS and SEMOPS II projects can be found on exhaustive; thus the set of types can categorize any given 1082 12 The current status is that the No. 3 operator, ONE, joined the alliance m-payment use case into strictly one of the types. As a 1083 while the No. 2 operator, T-Mobile, is not involved. result, any given m-payment procedure can be categorized 1084 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
  • 17. 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 17 F OO PR ED Fig. 12. Instances of Use Case Type A with different actor constellations. CT 1085 by stating which use case types it supports. Use cases or The MNO also handles and authenticates payments over 1109 1086 m-payment procedures can then be analyzed using the the network. An example is the purchase of digital content 1110 E 1087 respective reference models. The complexity of such an from a media company over the ‘‘Vodafone live!’’ portal, 1111 1088 analysis is varying: While for a particular m-payment settled via the mobile phone bill. 1112 use case the analysis is limited to the according (i.e., The actor-based analysis for this use case is shown in RR 1089 1113 1090 one single) use case type it may comprise up to all seven Fig. 2, and represents the state of the art in research and 1114 1091 types for an m-payment procedure which covers all pay- practice. This kind of analysis gives the impression that 1115 1092 ment scenarios. the market constellation would be invariable. In contrast 1116 1093 As a major difference to regular e3-value models, the ref- to that, the role-based market constellation analysis relying 1117 CO 1094 erence models use roles instead of actors (with the excep- on the full MPMA approach and the according reference 1118 1095 tion of the customer actor). This abstraction level was model for Type A clearly brings out the actual situation 1119 1096 chosen in accordance with the degrees of freedom granted and makes alternative constellations visible, such as the 1120 1097 by the definition of the MPMA. This is an advantage right model in Fig. 12. 1121 1098 because it allows a lean, exhaustive set of use case types. The effects of the MNO dominance are quite dramatic: 1122 UN 1099 However, to instantiate a use case type for market constel- Exploiting its quasi-monopolistic market position for 1123 1100 lation analysis it is now essential to introduce the actor level transport and payment the MNO is able to dictate fees 1124 1101 above the role level. Two examples for resulting models are for payment handling; a 30–70% premium is typical in 1125 1102 shown in Fig. 12. many markets. As a consequence, a content owner can only 1126 1103 The diagrammed use cases instantiate Use Case Type A. embark on one of three strategies: 1127 1104 The left model represents the dominant charging approach 1105 for mobile content, services and applications in most mar- – generate direct revenues and accept the abovementioned 1128 1106 kets in the MNO-centered constellation.13 Here, the MNO share ratio, 1129 1107 operates the mobile network and provides its own portal – generate only indirect revenues by either selling the con- 1130 1108 with a strong brand to attract customers to its services. tent to the MNO or just relying on advertisement to gen- 1131 erate revenues, 1132 13 This instance is indicative of the actor-based model, if the basic fees are – offer the content completely for free in order to generate 1133 assumed to be equal to 0 here. revenues outside of m-commerce. 1134 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
  • 18. ELERAP 264 No. of Pages 20, Model 5+ ARTICLE IN PRESS 1 August 2007 Disk Used 18 K. Pousttchi / Electronic Commerce Research and Applications xxx (2007) xxx–xxx 1135 The first strategy is only viable for those three types of ser- tion could open up competition and enable more viable 1189 1136 vices where predatory high pricing is tolerated by the cus- business models which will allow content owners to gener- 1190 1137 tomers, for example, logos, ringtones and adult content.14 ate direct revenues from customers. Although the MPSP 1191 1138 The third strategy is viable for companies whose core busi- role is not necessary to be executed by a bank, this is the 1192 1139 ness is outside of m-commerce (e.g., car manufacturers, most promising market participant for this role. Fees for 1193 1140 radio stations or banks); it is rather a mobile marketing payment handling in the right model are typically much 1194 1141 strategy for customer acquisition or retention than a busi- lower, as they are geared to credit card transaction fees. 1195 1142 ness model. Hence, only the second strategy remains an In virtually all developed mobile markets, however, either 1196 1143 option for most providers of mobile content, services and banks do not yet act as MPSPs, or they cooperate with 1197 1144 applications. But as advertisement as a sole revenue model the MNOs and avoid competition in payments for m-com- 1198 F 1145 did not prove to be effective on the mobile channel up to merce. This may be a good chance for specialized m-pay- 1199 1146 now the second strategy is reduced to the sale of services, ment intermediaries, but a successful business model will 1200 OO 1147 content or applications to the MNO who resells it to its be difficult to implement [21]. 1201 1148 customers. This situation is reflected by the left model in As a result, there is no example of a successful MPSP in 1202 1149 Fig. 12. The right model shows a converse solution with the m-commerce scenario outside of the MNO billing pro- 1203 1150 a weak MNO that is reduced to the operation of the mobile cess up to now – and consequentially no realization of the 1204 1151 network. The content offering is affected by the content full revenue potential of m-commerce outside of Korea and 1205 PR 1152 provider’s own portal, and payment is provided by a bank Japan. 1206 1153 which offers an m-payment procedure and customer 1154 authentication. A specific example of this use case could 5. Conclusion 1207 1155 be a TV station offering video downloads for a reality show 1156 or a sports event with exclusive complementary content on This section rounds up the contribution to m-payments 1208 1157 the mobile channel. research and practice. Based on that, the limitations and 1209 ED 1158 As a result of the present situation in many markets the research agenda are shown. The overall objective of this 1210 1159 shown in the left market constellation, two major groups research was to provide a toolset for the analysis of the 1211 1160 of content owners have low or no incentive to provide major reason for m-payments’ failure in most markets up 1212 1161 valuable content on the mobile channel. Large content to now – the interaction of the market participants. 1213 1162 owners, especially media companies such as Time Warner, CT 1163 Disney or Bertelsmann own strong brands with an exist- 5.1. Contribution to m-payments research and practice 1214 1164 ing customer relation. Although attractive, the mobile 1165 channel is just one of many distribution channels for these Following this objective, the aim of the paper was to 1215 1166 companies. If conditions are not favorable and customers develop: (1) a modeling method that could deal with the 1216 E 1167 cannot be addressed directly but only via the MNO por- complexity and particular characteristics of m-payments 1217 1168 tal, the importance of the channel remains low and no and could bring as much rigor as possible to the analysis, 1218 RR 1169 innovative or exclusive mobile content is offered. Small but at the same time could be used by both research and 1219 1170 innovative companies – hence those types of startup com- industry, and (2) a disjoint and exhaustive set of role-based 1220 1171 panies which recognized new customer needs and subse- reference models for m-payment use case types which could 1221 1172 quently revolutionized e-commerce such as Amazon, be applied to any m-payment market. 1222 1173 Google or E-Bay – have no chance to generate direct rev- In response to these requirements, the mobile payment 1223 CO 1174 enues from customers with reasonable business models for modeling approach (MPMA) was proposed as a methodol- 1224 1175 their innovative services or applications. Their only realis- ogy for the modeling of m-payment use cases and of the 1225 1176 tic option is to sell them to the MNO. This is a different economic functionality of m-payment procedures. MPMA 1226 1177 business than selling to consumers, with the consequences applies and modifies techniques from Gordijn’s e3-value 1227 1178 of determining ‘‘who is your customer?’’ It also exposes model and focuses especially on defining, deriving, and 1228 UN 1179 them to a monopsony situation. Additionally, in the mar- analyzing relationships among the various roles, along with 1229 1180 ket, there is the side condition that the development of the the partitioning of these roles in the m-payment value cre- 1230 1181 service and the major capital expenditures have to be ation network. Apart from this, the approach not only 1231 1182 financed before the MNO can decide whether it is willing enables economic analysis but also facilitates the deduction 1232 1183 to buy. of requirements for business processes and system architec- 1233 1184 Thus, the left constellation in Fig. 12 shows an unsatis- tures in the implementation phase of an m-payment proce- 1234 1185 factory situation in m-payment for the m-commerce sce- dure. The payment scenarios were closely investigated with 1235 1186 nario. It also reveals the major reason for low m- regard to concrete use cases; their major variations, distinc- 1236 1187 commerce revenues in most markets by today. A change tions and similarities were analyzed with the dynamic 1237 1188 in the MPSP role as shown in the right market constella- approach of MPMA, using roles and value flows as the 1238 central element of the analysis. A basic set of seven m-pay- 1239 ment use case types was then derived, and a thorough refer- 1240 14 Charging is mostly realized via Premium SMS. ence model for each of these was developed. 1241 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
  • 19. 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 19 1242 The outcome of this work is a toolset consisting of the include the existing banking infrastructure, existing com- 1297 1243 MPMA as a value-based modeling approach especially sui- peting payment methods, payment habits and preferences 1298 1244 ted for analysis of m-payment use cases. This work also of customers, relative market power of financial institu- 1299 1245 provides a set of reference models that can classify any tions and mobile network operators, relative relevance of 1300 1246 m-payment use case or m-payment procedure, and analyze the different use case types, and legal and regulatory 1301 1247 it with regard to business models and market participant issues.15 For such a mobile payment reference model, a 1302 1248 roles, and their interrelationships. It does so from a quantification of the value flows would be extremely bene- 1303 1249 value-based perspective. Illustrative applications of this ficial, following the approach that Gordijn and Akkermans 1304 1250 toolset were shown based on introspective analysis and [8] developed for the power industry.16 1305 1251 market constellation analysis. The reference models represent the current development 1306 F 1252 For researchers, the work provides the further develop- of m-payment markets. More mature markets may show a 1307 1253 ment of the static categorization payment scenarios to the higher level of labor division, following the credit card 1308 OO 1254 dynamic categorization use case types. The role-based set industry, for instance. In the models this could be especially 1309 1255 of reference models is invariant to different basic conditions relevant for the MPSP role and result in a transformation 1310 1256 and thus provides a reference point for any given m-pay- of the value activities in separate roles. Furthermore, the 1311 1257 ment use case or m-payment procedure in any market. This presented reference models are limited to a single m-pay- 1312 1258 enables not only the classification of any given m-payment ment market. A transnational m-payment system would 1313 PR 1259 use case or m-payment procedure but – in conjunction with require additional roles and interchange rules. The refer- 1314 1260 MPMA – also the systematic analysis of roles and value ence models are subject to further development in the 1315 1261 flows over all different environments, using the same base SEMOPS II project. 1316 1262 frame. This allows for structured cross-market comparison A different challenge to the reference models is the 1317 1263 as well as for analysis of correlation between value flows or development of the telecommunication world. Fixed- 1318 1264 market constellations and other influence factors such as mobile convergence of networks could result in a merger 1319 ED 1265 regulation, development of the financial sector or maturity of e-commerce and m-commerce and open up the opportu- 1320 1266 of the mobile market. Moreover, the inclusion of major nity for mobile phones to serve as the major authentication 1321 1267 stakeholders allows examining the influence of m-payment and payment tool in both worlds. A successful introduction 1322 1268 on markets for products or services in the different of the IP Multimedia Subsystem could then enable inte- 1323 1269 environments. grated service charging on the basis of m-payment 1324 CT 1270 For practitioners, the work provides a systematic view mechanisms. 1325 1271 on the different prospective use cases and environments. A major point on the research agenda is business mod- 1326 1272 It fosters the analysis and comparison of competing proce- eling. While the reference models support the development 1327 1273 dures, as well as the purposive construction of m-payment of a revenue model, many other influence factors of the m- 1328 E 1274 procedures, supporting the selection of use cases and the payment business model are out of scope for MPMA. 1329 1275 optimization of the role assignation. Revenue models of However, these issues are addressed by Pousttchi et al. 1330 RR 1276 m-payment service providers can be closely examined with [21], however. A comprehensive approach would be of 1331 1277 regard to the different use case types and the respective great value for practitioners who are planning an m-pay- 1332 1278 market constellations. The implementation phase of an ment procedure from scratch, enabling a unified and com- 1333 1279 m-payment procedure can be supported by a continuation plete top-down approach. 1334 1280 of the aforementioned introspective analysis, resulting in a CO 1281 top-down deduction of requirements for business processes 6. Uncited reference 1335 1282 and system architectures of the m-payment service provider 1283 or other roles in the supported use case types. [2]. Q2 1336 1284 First instances of MPMA and the set of reference mod- 1285 els are currently used by the European Union project on Acknowledgements 1337 UN 1286 Secure Mobile Payment Services (SEMOPS II) and in pro- 1287 ject work of the Mobile Commerce Working Group (wi- The author wishes to thank the E-Commerce Research 1338 1288 mobile) with several market participants. and Applications m-payments special issue editors, Stama- 1339 tis Karnouskos, Rob Kauffman, Elaine Lawrence, and the 1340 1289 5.2. Limitations and research agenda 1290 The approach presented is invariant to different market 15 For the German market the author was assigned to develop an MPRM 1291 conditions and may serve as a basis for a complete mobile by the German Ministry of Economics and Labor. However, the proposed 1292 payment reference model. The latter, however, would optimal solution (a large-scale collaboration model) could not be 1293 require in addition a recommendation component to be tai- implemented as not all MNOs and banks were willing to co-operate with the other market participants. 1294 lored to the basic conditions and particularities of the mar- 16 However, one has to bear in mind that this analysis relies on ex post 1295 ket where the m-payment procedure or system is to be data while the analysis of m-payment markets mostly has to be ex ante up 1296 used. Major factors which would impact this component to now. 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
  • 20. ELERAP 264 No. of Pages 20, Model 5+ ARTICLE IN PRESS 1 August 2007 Disk Used 20 K. Pousttchi / Electronic Commerce Research and Applications xxx (2007) xxx–xxx 1341 anonymous reviewers, for their helpful comments through- [12] N. Kreyer, K. Pousttchi, K. Turowski, Standardized payment 1391 1342 out the development of this article. Key Pousttchi thanks procedures as key enabling factor for mobile commerce, in: K. 1392 Bauknecht, G. Quirchmayr, A.M. Tjoa (Eds.), E-Commerce and 1393 1343 the Mobile Commerce Working Group, especially the m- Web Technologies. Third International Conference EC-Web 2002, 1394 1344 payment experts Dietmar Wiedemann and Laura Goeke, LNCS, 2455, Springer, New York, NY, 2002, pp. 400–409. 1395 1345 for partial support. [13] M. Kruger, K. Leibold, D. Smasal, Internet-Zahlungssysteme aus ¨ 1396 Sicht der Verbraucher. Ergebnisse der Online-Befragung IZV8 1397 1346 References (Internet payment procedures from the customers’ point of view. 1398 Results of the IZV8 online survey), University of Karlsruhe, Institute 1399 of Economic Policy and Economic Research (IWW), Karlsruhe, 1400 1347 [1] Y.A. Au, R.J. Kauffman, The economics of mobile payments: Germany, 2006. 1401 1348 Understanding stakeholder issues for an emerging financial technol- [14] R. Kuhlen, Informationsmarkt: Chancen und Risken der Kommerz- 1402 1349 ogy, Electronic Commerce Research and Applications, this issue. F ialisierung von Wissen (Information market: chances and risks of 1403 1350 [2] B. Bazijanec, K. Pousttchi, K. Turowski, An approach for assessment commercialization of knowledge), Universitatsverlag Konstanz, Kon- ¨ 1404 1351 ´˜ of electronic offers, in: M. Nunez, S. Maamar, K. Pousttchi, F. stanz, Germany, 1995. 1405 OO 1352 Rubio, F.L. Pelayo (Eds.), Applying Formal Methods – Testing, [15] K. Leibold, K. Stroborn, Internet-Zahlungssysteme aus Sicht der 1406 1353 Performance and M-/E-Commerce, FORTE 2004 Workshops The- Verbraucher. Ergebnisse der Online-Befragung IZV 6 (Internet 1407 1354 FormEMC, EPEW, ITM, Toledo, Spain, October 1–2, 2004, LNCS, payment procedures from the customers’ point of view. Results of 1408 1355 3236, Springer, New York, 2004, pp. 44–57. the IZV6 online survey), University of Karlsruhe, Institute of 1409 1356 [3] R.J.A. Buhr, Use case maps as architectural entities for complex Economic Policy and Economic Research (IWW), Karlsruhe, Ger- 1410 1357 systems, IEEE Transactions on Software Engineering 24 (12) (1998) many, 2003. 1411 PR 1358 1131–1155. [16] F. Muller-Veerse, Mobile Commerce Report, Durlacher Research, ¨ 1412 1359 [4] T. Dahlberg, N. Mallat, J. Ondrus, A. Zmijewska, Mobile payments: London, England, 2000. 1413 1360 a review for past, present and future research, Electronic Commerce [17] T. Natsuno, The I-Mode Wireless Ecosystem, Wiley, New York, NY, 1414 1361 Research and Applications, this issue. 2003. 1415 1362 [5] M. Eisenmann, K. Linck, K. Pousttchi, Nutzungsszenarien fur mobile ¨ [18] K. Pousttchi, B. Selk, K. Turowski, Akzeptanzkriterien fur mobile ¨ 1416 1363 Bezahlverfahren. Ergebnisse der Studie MP2 (Use cases for mobile Bezahlverfahren (Acceptance criteria for mobile payment 1417 1364 payment procedures. Results of the MP2 study), in: K. Pousttchi, K. procedures), in: F. Hampe, G. Schwabe (Eds.), Mobile and Collab- 1418 ED 1365 Turowski (Eds.): Mobile Economy: Transaktionen, Prozesse, orative Business 2002, Multikonferenz Wirtschaftsinformatik 2002; 1419 1366 Anwendungen und Dienste, Proceedings, 4th Workshop on Mobile Gesellschaft fur Informatik, LNI P-16, Bonn, Germany, 2002, pp. 51– ¨ 1420 1367 Commerce, Gesellschaft fur Informatik, LNI P-42, Bonn, Germany, ¨ 67. 1421 1368 2004, pp. 50–62. [19] K. Pousttchi, D.G. Wiedemann, Mobile payment and the charging of 1422 1369 [6] J. Gordijn, J.M. Akkermans, Designing and evaluating e-business mobile services, in: D. Taniar (Eds.), Encyclopedia of Mobile 1423 1370 models, IEEE Intelligent Systems 16 (4) (2001) 11–17. CT Computing and Commerce, Idea Group Inc., Clayton, Australia, 1424 1371 [7] J. Gordijn, J.M. Akkermans, Value based requirements engineering: 2006. 1425 1372 exploring innovative e-commerce ideas, Requirements Engineering [20] K. Pousttchi, M. Schurig, Assessment of today’s mobile banking 1426 1373 Journal 8 (2) (2003) 114–134. applications from the view of customer requirements, in: R. Sprague 1427 1374 [8] J. Gordijn, J.M. Akkermans, Business models for distributed gener- (Ed.), Proceedings of the Thirty-Seventh Annual Hawaii Interna- 1428 1375 ation in a liberalized market environment, Electric Power Systems tional Conference on System Sciences, Big Island, HI, January 2004, 1429 E 1376 Research Journal 77 (9) (2007) 1178–1188. IEEE Computing Society Press, Los Alamitos, CA, 2004. 1430 1377 [9] J. Gordijn, J.M. Akkermans, J.C. van Vliet, What’s in an electronic [21] K. Pousttchi, M. Schiessler, D.G. Wiedemann, Analyzing the 1431 1378 business model? in: R. Dieng, O. Corby (Eds.), Knowledge Engi- RR elements of the business model for mobile payment service provi- 1432 1379 neering and Knowledge Management: Methods, Models and Tools, sionProceedings of the 6th International Conference on Mobile 1433 1380 12th International Conference EKAW 2000, Juan-les-Pins, France, Business, Toronto, Canada, July 2007, IEEE Computing Society 1434 1381 LNAI, 1937, Springer, New York, NY, 2000, pp. 257–273. Press, Los Alamitos, CA, 2007. 1435 1382 [10] A. Herzberg, Payments and banking with mobile personal devices, [22] K. Pousttchi, An analysis of the mobile payment problem in Europe, 1436 1383 Communications of the ACM 46 (5) (2003) 53–58. in: C. Branki, R. Unland, G. Wanner (Eds.), Multikonferenz 1437 CO 1384 [11] D. Khodawandi, K. Pousttchi, D.G. Wiedemann, Akzeptanz mobiler Wirtschaftsinformatik (MKWI) 2004, Universitat Duisburg-Essen, ¨ 1438 1385 Bezahlverfahren in Deutschland. Ergebnisse der Studie MP1 (Accep- March 9–11, 2004, vol. 3: Mobile Business Systems, Mobile and 1439 1386 tance of mobile payment procedures in Germany. Results of the MP1 Collaborative Business, Techniques and Applications for Mobile 1440 1387 study), in: K. Pousttchi, K. Turowski (Eds.), Mobile Commerce – Commerce (TAMoCO), Essen, Germany, 2004, pp. 260–268. 1441 1388 Anwendungen und Perspektiven. Proceedings, 3rd Workshop on [23] E.M. Rogers, Diffusion of Innovations, fifth ed., Free Press, New 1442 1389 Mobile Commerce, Gesellschaft fur Informatik, LNI P-25, Bonn, ¨ York, NY, 2003. 1443 UN 1390 Germany, 2003, pp. 42–57. 1444 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