1. ELERAP 264 No. of Pages 20, Model 5+
ARTICLE IN PRESS
1 August 2007 Disk Used
1
Electronic Commerce Research and Applications xxx (2007) xxx–xxx
www.elsevier.com/locate/ecra
2 A modeling approach and reference models for the analysis
3 of mobile payment use cases
F
4 Key Pousttchi *
OO
5 Mobile Commerce Working Group (wi-mobile), Business Informatics and Systems Engineering, Business School, University of Augsburg, Germany
6 Received 1 December 2006; received in revised form 1 July 2007; accepted 1 July 2007
7
PR
8 Abstract
9 Mobile payments can be categorized according to their usage in each of the five payment scenarios presented here. The paper proposes
10 the mobile payment modeling approach (MPMA) especially suited for value-based analysis of mobile payment use cases. Based on this
11 approach, the study also develops a set of seven reference models that can classify any given mobile payment use case or mobile payment
ED
12 procedure and analyze it with regard to the business model, the roles of the market participants, and their interrelation from a value-
13 based perspective. An introspective analysis of the mobile payment service provider role and a market constellation analysis which shows
14 the implications of different actors assuming one or more of the respective roles complete the study.
15 Ó 2007 Elsevier B.V. All rights reserved.
CT
16 Keywords: Mobile payments; Mobile payment modeling approach; MPMA; Use case types; Reference models; System analysis; Value exchange diagrams
17
E
18 1. Introduction 2.5G networks by the end of the 1990s made it essential 36
to develop an appropriate form of settlement that possesses 37
RR
19 Since the mid-1990s, serious efforts have been made to the same properties, especially ubiquity, as the mobile 38
20 use mobile phones for business-to-consumer payment offers for which billing occurs. As a result, for the examina- 39
21 transaction processing. This type of processing is referred tion of m-payment procedures, two basic tasks must be dis- 40
22 to as mobile payments or m-payments. For the purposes tinguished. Inside m-commerce, payments for mobile 41
23 of this paper, m-payments are defined as a type of payment services must be implemented in a way that ideally will 42
CO
24 transaction processing in which the payer uses mobile com- be perceived by the user as a seamless part of the system. 43
25 munication techniques in conjunction with mobile devices Outside m-commerce, m-payments become mobile services 44
26 for initiation, authorization, or completion of payment. themselves to provide payment functionality in various sce- 45
27 The first m-payment efforts originated from the fact that narios. These scenarios include payment in stationary 46
28 the mobile phone – due to its specific properties, its wide Internet/e-commerce, payment at vending machines (often 47
UN
29 distribution in the population, and its users’ behavior – is called ‘‘unmanned point-of-sale (POS)’’), payment to a per- 48
30 especially well-suited for payment activities (e.g., [10]). son acting as a merchant or service provider (‘‘manned 49
31 What is more, analysis of mobile banking services shows POS’’, for example, the cashier in a department store, the 50
32 that except for account balance verification, instant pay- pizza delivery person or the taxi driver), and money trans- 51
33 ment is the strongest use case [20]. fer between consumers. As a result, five general payment 52
34 In addition to the attractiveness of the technology, the scenarios can be distinguished (Table 1), a categorization 53
35 appearance of mobile services and mobile commerce with that goes back to Kreyer et al. [12]. 54
The initial stage of this research (MP1), which was based 55
Q1 *
Tel.: +49 8230 700445.
on the preliminary theoretical work by Kreyer et al. [12] 56
E-mail address: key.pousttchi@wiwi.uni-augsburg.de. and Pousttchi et al. [18] and included a survey with 6200 57
1567-4223/$ - see front matter Ó 2007 Elsevier B.V. All rights reserved.
doi:10.1016/j.elerap.2007.07.001
Please cite this article in press as: K. Pousttchi, A modeling approach and reference models for the analysis ..., Electron. Comm. Res.
Appl. (2007), doi:10.1016/j.elerap.2007.07.001

2. 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
www.e3value.com/. Gordijn and Akkermans [6,7]. Use case maps provide a 218
3
MPMA is currently used in the SEMOPS (Secure Mobile Payment
System) project on a pan-European mobile payment system as well as in way of associating the organizational structure of a com- 219
other projects with various industry partners in order to analyze developed plex system with its behavior. This combination enables 220
as well as developing m-payment markets. one to model, not only the structure, but also the process 221
Please cite this article in press as: K. Pousttchi, A modeling approach and reference models for the analysis ..., Electron. Comm. Res.
Appl. (2007), doi:10.1016/j.elerap.2007.07.001

4. 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