ELECTRONIC RETAIL PAYMENTS AT PUBLIC EVENTS · ELECTRONIC RETAIL PAYMENTS AT PUBLIC EVENTS An exploratory study into the feasibility of various electronic payment systems at public

ELECTRONIC RETAIL PAYMENTS AT PUBLIC EVENTS

An exploratory study into the feasibility of various

electronic payment systems at public events

MASTER THESIS

Business Information Technology University of Twente Merijn Boot September 2011

1

Master Thesis Title: Electronic retail payments at public events: An exploratory study into the

feasibility of various electronic payment systems at public events Date: September 23th, 2011 Author: Merijn N.S. Boot Student number: 0091006 E-mail: m.n.s.boot@student.utwente.nl Institution: University of Twente, Enschede, The Netherlands Faculty: School of Management and Governance Master: Business Information Technology

Graduation Committee Supervisor: Dr. Ir. A.A.M. (Ton) Spil Institution: University of Twente, Enschede, The Netherlands Faculty: School of Management and Governance Research group: Information Systems and Change Management Supervisor: Dr. N. (Klaas) Sikkel Institution: University of Twente, Enschede, The Netherlands Faculty: Faculty of Electrical Engineering, Mathematics and Computer Science Research group: Information Systems External Supervisor Supervisor: R. (Roland) Wassink Company: LOC7000

2

Acknowledgements Thanks to my extra-curricular activities at the Vestingbar, which included active involvement in the

organization of some large-scale events public events at the University, I’ve built up quite an affinity

and interest to public events. When the possibility arose to conduct my final project for LOC7000

PaySystems, I jumped at the opportunity and I’ve enjoyed conducting this research assignment.

While my prior knowledge of the event market helped me understand the stakeholders and their

interests, I always had to watch out that it didn’t blind me and keep an open mind. Klaas Sikkel and

Ton Spil, my supervisors from the University helped me do that by providing important feedback to

my work, which on various occasions helped me to look at a problem from a different perspective.

They were always prepared to help out when I got stuck somewhere and for that, I want to thank

them.

Another person I’d like to thank is Roland Wassink, my supervisor at LOC7000, who not only

introduced me to the company and the problem facing PaySystems, but also allowed me to attend

meetings of the internal project group working on electronic payment. These meetings helped me

understand the problem better and get some important feedback on my initial ideas.

I’d also like to express my thanks to all PaySystems employees for taking the time to talk with me

about the current payment system and the difficulties facing PaySystems, and to the Dutchband

employees, which whom I’ve often exchanged insights regarding potential new payment systems,

and finally to Gert Holsbeeke from ABN-AMRO, who helped me immensely by answering important

questions regarding the functionality of many payment systems offered by banks.

This thesis is the result of not only a half year’s worth of research, but the end-result of my entire

study-program, which took me a good seven years. I’ve had a great time during those years, but I

needed some motivation at times. Therefore, I want to first thank my parents, who always were

available for advice, support and sometimes tough love. And last, but certainly not least, I’d like to

thank my beautiful wife, Marleen, who helped me get through the tough times, when I was in over

my head with work, and she provided motivation when I needed it.

Merijn Boot

Enschede, September 2011

3

Management summary This thesis explores the possibilities for PaySystems to leverage new electronic payment technologies

for payments made by visitors during large-scale public events. PaySystems, one of the labels of

LOC7000, currently deploys a payment system based on plastic tokens, which can be bought at

vending machines or manned sales-booths. These tokens are then used for payments at food and

beverage vendors. Event-organizers choose this payment system because it is very fast, reliable,

offers good financial control and it increases the sales revenue, which is an important source of

income for them.

The payment market is experiencing a lot of changes at the moment, mostly caused by new emerging

technologies, which open possibilities for new electronic payment systems, of which the first

examples are being deployed at this time. These new payment systems are expected to significantly

change the payment landscape: The use of cash is expected to drop in the coming years and

innovative companies, such as Google, are entering the payment market, which up until now was the

domain of banks and specialized payment providers.

It is unclear what these changes in the market will have on the market position of the current

payment system that PaySystems deploys and whether PaySystems can benefit from leveraging

these technologies to improve upon their current system. This research therefore investigates what

the possibilities for PaySystems are to introduce electronic payment technology at public events.

First the payment market and some of the technologies driving changes in this market are presented.

The business model of PaySystems is then analyzed to gain a proper understanding of what aspects

of the current payment system are of value to event-organizers and other stakeholders in the event

market and to assess the sustainability of the current system in the future. The four most important

aspects are: Increased sales revenue, reliable payment system, speed at the point-of-sale and

financial control, including support of revenue sharing between event-organizer and vendors. These

four factors therefore form the basis of the requirements for a new electronic payment system.

Maximizing the sales revenue is one of the business goals for the new system, while the other three

are the most important requirements by which a system must function. There are three additional

business goals, which are not necessary to sustain the current business model, but are ambitions that

PaySystems has: Minimizing the costs of operating the payment system, expanding the market to

include smaller events and fixed venues and achieving a high visitor satisfaction concerning payment.

There are two primary avenues for electronic payment considered in this thesis. The first is building a

proprietary prepaid payment system, which functions as independently as possible, much like the

current system, but in an electronic form. The visitor buys credit first and can use this credit to make

purchases at a vendor. The other option is to leverage one or more of the payment instruments

offered by financial institutions, such as debit or credit card payments, and use their infrastructure to

perform the transactions at the point-of-sale in real-time.

Every real-time system has a set payment process and thus a set performance on the four critical

factors: They either are able to meet the required targets or they’re not and there is very limited

room for PaySystems to adapt the system and improve in this regard. Building a proprietary prepaid

system will allow PaySystems to keep the four critical factors in mind in every decision that is being

made and this will most likely allow them to meet the targets. While this is a serious complication for

4

real-time payment systems, such a system would make it easier for PaySystems to reach its business

goals, especially expanding the market and minimizing their costs, since it is easier to operate and

more scalable. A prepaid system is also the costlier option to implement, because a lot of effort must

be spent not only in the four critical factors, but also in other aspects, such as integrity, security and

fraud prevention, while these are all covered by the financial institution in the real-time system.

A prepaid system offers little value over the current payment system: There is a possible reduction in

operational costs and there are opportunities to enhance the visitors’ satisfaction. The prospects for

market expansion do not look much better with a prepaid system and food and beverage sales are

not expected to increase. However, visitor satisfaction with the current system is adequate and the

high costs and risks to implements a prepaid system do not justify a change.

At this moment, a real-time system is not feasible since there are some implementation barriers

which first need to be overcome, such as transaction speed and offline transactions. Therefore,

PaySystems is advised to keep the current system for now, while they work to overcome these

implementation barriers. When these barriers are overcome, PaySystems can implement this real-

time system, since it offers excellent value, especially since the high scalability allows for market

expansion.

It is therefore recommended that they conduct quantitative research regarding the requirements on

the transaction speed of the system, since insufficient transaction speed is the primary barrier

regarding a real-time system and at the moment the target for speed is only an assumption. Further,

PaySystems needs to do solid market research to accurately assess the opportunities of the real-time

system in fixed venues, since this is the main source of value from the implementation of such a

system. Accurately predicting how much of this market can be captured at what price is important in

assessing the economic viability of such a system.

When PaySystems has made a more concrete choice on which system to pursue, it is important that

the business case which is used to support this decision makes sense not only to PaySystems, but

also to the event-organizers. One of the main reasons that event-organizers pay a high price for the

current system is that it makes financial sense, mainly due to the increased sales. Should another

system make less sense for them financially, they may refrain from hiring PaySystems. Finally it is

important to build a solid implementation plan. The balance between implementation cost and risk is

a fine line, especially with a system which is highly critical, but has as one of its goals to reduce costs.

The main theoretical contribution of this thesis lies in the relation between the business modeling

and the requirements engineering and all the decisions which follow from this. The business model is

used to uncover the four most critical characteristics of PaySystems: Transaction speed, reliability,

increased sales and financial control. These aspects form the basis of the requirements and guide all

decisions taken in the subsequent chapters, completed with the ambitions that PaySystems has for

the future. This ensures that the decision process is transparent and argumentation is consistent and

easy-to-follow during the entire research. It is therefore recommended that PaySystems keeps these

four aspects in focus during the subsequent phases of research and development.

5

Table of Contents Acknowledgements ................................................................................................................................. 2

Management summary ........................................................................................................................... 3

1 Introduction ..................................................................................................................................... 8

1.1 Research objective .................................................................................................................. 9

1.1.1 Scope ............................................................................................................................. 10

1.2 Research approach ................................................................................................................ 10

1.3 Impact & Relevance ............................................................................................................... 10

1.4 PaySystems & Partners .......................................................................................................... 11

1.4.1 PaySystems .................................................................................................................... 11

1.4.2 Event-organizers ............................................................................................................ 12

1.4.3 Caterers ......................................................................................................................... 12

1.4.4 Visitors ........................................................................................................................... 12

2 Literature Review .......................................................................................................................... 13

2.1 Payments at the retail point-of-sale ...................................................................................... 13

2.1.1 Retail payments in the Netherlands .............................................................................. 13

2.1.2 The payment market ..................................................................................................... 14

2.1.3 Payment time ................................................................................................................ 15

2.2 Developments in retail payment systems ............................................................................. 17

2.2.1 2D Barcoding ................................................................................................................. 17

2.2.2 Contactless payments ................................................................................................... 18

2.2.3 Mobile NFC payment ..................................................................................................... 19

2.3 Payments at public events .................................................................................................... 20

2.3.1 Characteristics of food and beverage payments ........................................................... 20

2.3.2 A comparable situation: Public Transportation............................................................. 21

3 Business Model .............................................................................................................................. 23

3.1 Business modeling ................................................................................................................. 23

3.1.1 Business Model Functions ............................................................................................. 24

3.1.2 Elements of a business model ....................................................................................... 26

3.1.3 Discussion of business modeling ................................................................................... 27

3.2 Business Model PaySystems .................................................................................................. 28

3.2.1 Value proposition .......................................................................................................... 28

3.2.2 Customer interface ........................................................................................................ 29

3.2.3 Value architecture ......................................................................................................... 29

6

3.2.4 Value network ............................................................................................................... 29

3.2.5 Finance .......................................................................................................................... 30

3.3 Business model evaluation .................................................................................................... 30

4 Requirements Specification ........................................................................................................... 33

4.1 Introduction ........................................................................................................................... 33

4.2 e3 value model ...................................................................................................................... 34

4.3 Payment system requirements ............................................................................................. 36

4.3.1 Business Goals ............................................................................................................... 36

4.3.2 User Tasks ...................................................................................................................... 37

4.3.3 Quality requirements .................................................................................................... 38

4.4 Discussion on requirements elicitation ................................................................................. 41

5 Constructing a shortlist ................................................................................................................. 43

5.1 Real-time payment system .................................................................................................... 43

5.2 Prepaid mobile wallet system ............................................................................................... 44

5.3 Postpaid settlement system .................................................................................................. 45

5.4 Automatic reload system ...................................................................................................... 46

5.5 Keep the current system ....................................................................................................... 47

5.6 Shortlist ................................................................................................................................. 48

6 Analyzing the shortlist options ...................................................................................................... 50

6.1 Outline of the systems........................................................................................................... 50

6.1.1 Real-time system ........................................................................................................... 50

6.1.2 Prepaid wallet ................................................................................................................ 52

6.2 Achievement of business goals ............................................................................................. 55

6.2.1 Goal 1: Maximize food and beverage sales volume at customers’ events ................... 55

6.2.2 Goal 2: Minimize operational costs ............................................................................... 56

6.2.3 Goal 3: Expand market to include smaller events and fixed venues ............................. 57

6.2.4 Goal 4: Achieve high visitors’ satisfaction with payment at events .............................. 58

6.2.5 Overall business goal performance ............................................................................... 59

6.3 Compliance with quality requirements ................................................................................. 59

6.3.1 Integrity and security ..................................................................................................... 60

6.3.2 Correctness .................................................................................................................... 60

6.3.3 Reliability and availability .............................................................................................. 61

6.3.4 Usability ......................................................................................................................... 62

6.3.5 Efficiency ....................................................................................................................... 62

7

6.4 Implementation costs and barriers ....................................................................................... 63

6.4.1 Real-time system ........................................................................................................... 63

6.4.2 Prepaid wallet ................................................................................................................ 65

6.5 Conclusion ............................................................................................................................. 67

6.5.1 Market considerations .................................................................................................. 67

6.5.2 Advice ............................................................................................................................ 68

6.5.3 Future research ............................................................................................................. 68

7 Discussion and conclusion ............................................................................................................. 69

7.1 Answers to the research questions ....................................................................................... 69

7.2 Discussion .............................................................................................................................. 72

7.2.1 Theoretical implications ................................................................................................ 72

7.2.2 Limitations ..................................................................................................................... 72

8 Recommendations......................................................................................................................... 74

References ............................................................................................................................................. 76

List of tables .......................................................................................................................................... 80

List of figures ......................................................................................................................................... 81

Appendix A: Business Model Elements ................................................................................................. 82

Appendix B: Current Business Model PaySystems ................................................................................ 83

Value Proposition .......................................................................................................................... 83

Customer Interface ........................................................................................................................ 85

Value Architecture ......................................................................................................................... 87

Value Network ............................................................................................................................... 89

Finance .......................................................................................................................................... 90

8

1 Introduction PaySystems, one of the three labels of public event-organizer LOC7000 (LOC7000 2011), is the

leading payment solution provider for retail payments at food and beverage vendors at large-scale

public events in the Netherlands. Their system, based on physical payment tokens, is widely used

both at outdoor events as in stadiums across the country. The system offers important benefits to

event-organizers, vendors and visitors: it offers quick and reliable payment at the point-of-sale and

has shown to substantially increase food and beverage sales during events.

Although the current system is widely considered successful, there are some notable drawbacks. First

of all, the token-based system has an extensive logistics chain which leads to a high operational cost:

tokens need to be bought, stored, distributed to events, sold with (semi)automatic vending machines

and counted, weighed and disposed after events. Second, the token-based system can be

cumbersome for visitors of the event: They can only buy tokens in certain amounts and need to

decide beforehand how many tokens they want. Too many and they need to exchange them at the

end of the event, too few and they need to go back to a vending machine during the event. Finally,

although event-organizers are satisfied with the token-based system, it is considered old-fashioned

and this makes expansion to new customers difficult, especially to other European countries. This is

compounded by the poor scalability of the current system.

New technological possibilities, such as Radio Frequency Identification (RFID)(ISO/IEC 2008) and

Near-Field Communication (NFC)(ISO/IEC 2010) along with the widespread customer adoption of

electronic devices such as smart mobile phones, have begun to drastically change the payment

landscape. (Carr 2008; Crowe, Rysman et al. 2010) They could enable digital payment methods for

customers in a variety of ways and lead to significant changes in the payment market and

PaySystems’ positioning in it.

PaySystems intends to maintain their leading position for payment solutions in the public event

market and this research will look at how PaySystems can leverage these new technologies to

improve upon their current payment system. By being an early adopter and tailoring electronic

payment system specifically to the needs of event-organizers, vendors and visitors, PaySystems

believes it can strengthen and possibly expand its market position.

In this thesis the possibilities for PaySystems to introduce electronic payment at public events will be

explored by first taking stock of the payment market and which (emerging) technologies are

expected to impact this market in the near future. Then the position that PaySystems takes in the

public event payment market is analyzed thoroughly to get a sound understanding of what key

elements of the current business model need to be preserved in a new, electronic payment system.

These elements, together with the aspirations that PaySystems has for the future, will form the

foundation for the requirements a new system should fulfill. In the last part of the thesis, some

options for electronic payment systems will be presented and an analysis will be made in order to

assess which of these fit the requirements best and whether they are feasible.

In this chapter, attention will be given to the research objectives of this thesis and the scope it covers

in section 1.1, the approach that will be used to reach these objectives in section 1.2. Section 1.3 will

present the impact and relevance of the research and, to gain a better understanding of the context,

a quick overview of PaySystems and other stakeholders will be presented in section 1.4.

9

1.1 Research objective The aim of this thesis is to explore the possibilities for the move from the physical token payment

system to a fully electronic payment system to process transactions at the vendors’ points-of-sale.

The research objective therefore reads as follows:

What are the possibilities for PaySystems to introduce electronic payment technology at public

events?

Several possibilities to introduce electronic payment will be presented and their feasibility and their

fit with the goals of PaySystems and with the quite specific event situation will be assessed. To reach

this objective the following research questions will be answered in the coming chapters.

1. What technological developments are currently influencing the retail payment landscape?

In chapter 2 the current retail payment market and the emerging technologies which drive change in

this market will be analyzed by answering questions such as: What are the characteristics of retail

payments, in general and at events? What stakeholders are involved in retail payments? And which

technologies are currently being used in novel payment system?

2. Is the current business model of PaySystems sustainable in the future?

The third chapter will analyze the place that PaySystems takes in the event payment market and how

it operates its payment system in great detail using business modeling as a tool. This will help capture

the elements of PaySystems’ system which are of great value to its customers and the other

stakeholders, and it helps to more accurately assess the impact of the changing payment landscape

on PaySystems.

3. What are the business goals and requirements for an electronic payment system at public

events?

The next step will be to take the first step toward an electronic payment system and define the

business goals that PaySystems wants to achieve in part by implementing an electronic system and

elicit the most important requirements. These of course will be based in large part on the findings

from the business modeling, since elements which are of value to their customers are most likely

important to retain.

4. Which alternatives for payment systems are viable for PaySystems?

The next step will be to build a shortlist of possible alternatives for payment systems at events. By

looking at varying business processes which can be used for point-of-sale payments, alternatives are

selecting and a shortlist is build which can be used for further analysis.

5. How do these alternatives fit with the business goals and requirements for electronic

payment at public events?

In chapter 6 the fit of these alternatives to the specific situation of PaySystems will be analyzed by

comparing the potential of each alternative to the business goals, the performance and feasibility of

an alternative by looking at quality requirements and a financial analysis and a small organizational

analysis by means of looking at changes that are required in the business model.

10

1.1.1 Scope

This main focus of this thesis is to make a preliminary analysis of which possibilities are available for

PaySystems to change to an electronic payment system and present recommendations how to

pursue this further. This is done by first getting a good overview of the payment market, both in

general and specific to public events, and the place PaySystems has in these. From there, high-level

requirements for the system to be developed will be presented, which can be used to compare

different options to one another and come up with the advice.

This will be done from a top-down, focusing on stakeholders and their desires, and bottom-up

approach, focusing on the available technologies and their possibilities and limitations. In the end, an

advice will be drafted which should help PaySystems move into the future payment landscape.

This thesis will limit itself to specific solutions for the public event market and only for payments at

vendors, mainly caterers, during the event. Ticketing is thus not considered. Due to the particular

constraints and requirements it will be difficult to generalize these results to other sectors. However,

the method by which this thesis is constructed could very well be used in other sectors, which have

their own constraints and requirements.

Many issues will be covered in this thesis, from the current system of PaySystems and their position

in the payment market, to the requirements for a new system and a comparison of different, high-

level options. The downside of this broad scope is that there is no opportunity to go into detail on

specific but critical issues, such as quantifying the effect that the current system and the new

alternatives have on the sales volume.

1.2 Research approach This research will bring the theoretical concepts of digital payment systems, which are widely

discussed in literature, to the context of the event and leisure market. Since there is limited

experience in this market with digital payment system, the first part of this study will mainly consist

of a thorough market analysis, mostly by analyzing the stakeholders and observing the critical

aspects of the current payment system, with the objective to uncover the most important criteria a

digital payment system should fulfill.

Although there is limited literature available specific to the event market, there are industries which

have similar concerns and are studied more thoroughly. Public transport is an example of a market in

which throughput is similarly important and in which digital payment systems are already prevalent

and well researched. Literature on digital payment in such markets will be a valuable source.

In the second part of this thesis, the knowledge gained will be used to draft the most important

business goals and functional and quality requirements for a new payment system. These elements

can later on be used to compare various alternative electronic payment systems. Combined with a

overview of the payment landscape and the outlook on the expected implementation issues and

costs, this will form a solid basis for the final advice for PaySystems.

1.3 Impact & Relevance For PaySystems, it is of primary importance to maintain their competitive edge over the more generic

payment solution providers. The success of their current system is that it is specifically suited to the

unique needs of both event-organizers and caterers in terms of transaction speed, reliability and

11

robustness. To remain an attractive partner in the future, the digital payment system of PaySystems

will need to outperform current and future payment solutions offered by more generic payment

providers, including banks.

This thesis will specifically focus on how to arrange the digital payment process and the supporting

system in a way that performance on these specific criteria is optimized and thus should help

position PaySystems favorably in the event-market for years to come. Further, a successful digital

payment system may reduce the operational costs, since handling of tokens will become obsolete. In

should be noted though, that cost savings are not a primary concern: investments and maintenance

costs in for example payment terminals and connectivity are expected to be substantial. A positive

business case is thus not a requirement for the chosen solution.

From a scientific point-of-view, this thesis uses business modeling of the current situation of

PaySystems to uncover the most important elements of the current payment system, which need to

be preserved in a electronic system. These elements for the basis for the requirements specification

of PaySystems. Such a use of business models is not mentioned in most business modeling ontologies

used in this thesis, except for the e3 value ontology by Gordijn (2004) which tries to bridge the gap

between business models and requirements. This thesis tries to give another insight in what the

relation between business models and requirements truly entails. Further issues that are of scientific

value include the question of how to successfully come up with a shortlist of alternatives and an

attempt to bring a little bit more clarity to the field of business modeling.

1.4 PaySystems & Partners To provide a brief overview of the current market in which PaySystems operates and the challenges

this presents, this section will give a short description of PaySystems itself and the most important

stakeholders in the public event market.

1.4.1 PaySystems

LOC7000 is the biggest public event facilitator in the Netherlands, which can deliver various services

to organizers of public events, either outdoors or in stadiums. At this moment, the customers of

LOC7000 are mainly domestic, but expansion to other European countries is a focus for the coming

period. LOC7000 operates under three separate labels, which can jointly or separately serve an

event-organizer:

Food And Beverage (FAB) arranges and exploits catering services.

PaySystems (PS) provides payment solutions for caterers and other vendors at events.

LOC7000 Event Management (LEM) provides various facilities, such as security, mobility,

event production, sanitary services and power.

There are some events in which LOC7000 serves as the event-organizer itself in combination with a

partner which takes care of bookings of artists and ticketing. During these events all three labels are

deployed and the bottom-line of these events is split between partners. For the purpose of this

research, the distinction between these two ways of working is not important, since PaySystems can

be seen as a facilitator in both cases and the customer can either be an external event-organizer or

LOC7000 itself.

12

The current payment solution utilized by PaySystems is a semi-automated token-based system.

Visitors of the event can buy tokens at automated vending machines, which accept either cash or

debit cards, or at manned sales booths, which also accepts cash and debit cards. These tokens are

then used to buy food, beverages or other products at vendors on the event grounds or in the

stadium. Unused tokens can sometimes be redeemed for cash at a manned point-of-sale.

The main advantage of the tokens is the speed at the point-of-sale. A transaction, either with a debit

card or with cash, at the point-of-sale would take far longer than the exchange of tokens. This is very

important to most stakeholders, since most public events have high peak hours, especially concerts

and football matches.

1.4.2 Event-organizers

Event-organizers are the customers of PaySystems; they hire the payment solution service from

PaySystems. One of the main sources of income of any event is a share of the catering sales.

Maximizing the sales of food and beverages is therefore very important. Another concern is the

satisfaction of the visitors, which are the customers of the event-organizers. A lot of public events

have high customer retention, especially in the case of football stadiums, where a lot of visitors have

season-tickets or multi-game ticket plans. Waiting in line, either to buy tokens or at the caterer to

buy food or drinks, is bad for customer satisfaction and therefore may hurt both sales and customer

retention.

1.4.3 Caterers

Caterers present the primary group of vendors who accept payment with the payment system. They

are signed on by the event-organizer and obliged to use the payment system utilized at the event.

The caterers are the main benefactors of sales during the event, so their main concern is increasing

the sales at their point-of-sale, while minimizing personnel costs. A payment system which is easy-to-

use and fast at the point-of-sale is therefore a primary concern.

1.4.4 Visitors

The visitors of the event are the users of the payment system. Because the current system is mainly

tailored to the needs of the caterers and the event-organizers, the user-friendliness is less-than-ideal:

buying tokens adds an additional step in the process of buying something at a vendor and with the

current system the visitors can only buy tokens in certain amounts. Further, the visitors need to

decide beforehand how many tokens to buy and often needs to re-buy after some time and/or

redeem cash for their unused tokens. The current system also has its advantages: visitors can easily

see how many tokens they have left and payment at caterers is very quick and easy.

13

2 Literature Review The relevant literature regarding the topics covered by this thesis will be briefly addressed in this

chapter. The goal is to build a sound theoretical foundation on the issues that are important in this

field, the solutions that are presented in other cases and the challenges facing electronic payment at

public events.

The topics discussed here include retail payments in general, electronic payment systems and the

current state of (electronic) payments in especially the Dutch/European market. Finally, payments at

(public) events and their characteristics will be described and based on these a comparable case

regarding payment is discovered and briefly discussed to get a more thorough understanding of

payment in challenging environments.

Topics specific to one of the upcoming chapters in this thesis, such as literature on business modeling

and requirements engineering will be presented at the beginning of their respective chapters and

thus will be excluded from this section. This chapter contains three sections. The first one will look at

retail payment in general, the second will focus on expected future developments in retail payment

and the last section will zoom in on the public event payment market, the niche in which PaySystems

operates.

2.1 Payments at the retail point-of-sale This first section of this literature review will take a look at retail payment in general, focused on the

Dutch and European context. It will explain what payment at the point-of-sale is, which stakeholders

are involved and what payment forms are currently available for retail purchases.

This thesis will be focused on payments at the retail point-of-sale, meaning a payment at the

vendor’s physical sales location, from a customer to the vendor in return for a product or service

delivered by the vendor. (Kemppainen 2003) Typical examples include stores, ticketing scenario’s, for

example in public transportation or at museums, or bars and restaurants. Other payment scenarios

are excluded, since PaySystems supports only retail point-of-sale payments. Examples of these other

scenarios include remote payments in e-commerce settings and bills paid by customers from their

home, which currently often happens via internet banking.

2.1.1 Retail payments in the Netherlands

Most vendors try to offer multiple payment methods at their point-of-sale to their customers, so

they can choose they want to use, since there is a wide variety of customer preferences. (Brits and

Winder 2005; Borzekowski and Kiser 2006) A second reason is built-in redundancy: Should one

system be unavailable, either because the customer isn’t able to use it or due to a disruption in

service, the customer can still pay using a different payment method. (Rochet and Tirole 2002;

Garcia-Swartz, Hahn et al. 2006) This is important because if the customer is unable to pay, the

purchase cannot be made and the vendor misses out on a sale.

There are instances however in which there is only one payment method offered to customers, due

to cost and/or practical concerns. Examples of this are vending machines, which are often outfitted

as simple as possible to minimize errors in the machine and enhance usability and small boutiques

which only accept cash due to the high costs of supporting multiple payment systems with their

typical low transaction volume.

14

Most methods for payment at the retail point-of-sale are generic payment systems offered to the

entire population, vendors and customers, by financial institutions, such as (central) banks. Although

there can be conditions on the eligibility of prospective users of the system, especially with systems

based on credit, in principle everyone has access to these systems. The most common examples of

these generic payment systems are cash, debit cards, credit cards, pre-paid electronic purses (such as

the Dutch ‘Chipknip’) and cheques, (Brits and Winder 2005) although the cheque has all but

disappeared in the Netherlands over the last decade. Cash remains the most common retail payment

method, especially for small purchases, although the electronic payment alternative are becoming

increasingly popular. (Brits and Winder 2005; Bolt and Chakravorti 2010)

These methods have been researched quite thoroughly, especially regarding the adoption of (new)

payment systems (Plouffe, Vandenbosch et al. 2000; Crowe, Rysman et al. 2010), security and risk

issues of current and new systems (Mulliner 2009; Chan, Fan et al. 2011) and the customer choice of

which payment system to use in which situation. (Brits and Winder 2005; Borzekowski and Kiser

2006) These are important issues, since payment costs are substantial. In the Netherlands, “the

overall costs involved in POS payments amount to 0.65% of gdp or, equivalently, EUR 0.35 per

transaction.” (Brits and Winder 2005) It is therefore important for both banks and vendors to

investigate what payment methods to offer and how new, lower costs alternatives can be optimally

implemented.

2.1.2 The payment market

There are three types of stakeholders directly involved in a payment at the retail point-of-sale:

customers, vendors and payment service providers. Customers pay for their purchase at a vendors

point-of-sale using the payment system offered by the payment service provider. In terms of

payment systems: the customer has a payment tool, which is used to conduct the payment.

Examples of such ‘tools’ are cash, debit/credit cards or, in the current system of PaySystems,

payment tokens. For the customer to be able to use the payment tool at a point-of-sale, the vendor

needs to be connected to the payment service provider as an acceptant of the payment system. How

this is done highly depends on the payment system. To accept cash, the vendor simply needs change,

so the customer is able to pay the proper amount. But to accept debit cards, the vendor needs a

business bank account as well as a debit card terminal, which is connected to their bank.

But the connection between payment service provider and vendor can also be intangible.

PaySystems fulfills the role of payment service provider at events and the vendors there can accept

payment tokens only if they’re part of the event, which they can become on invitation by the event-

organizer. They also need to accept the conditions on revenue sharing between the stakeholders in

the event and other regulations regarding the use of payment tokens, such as the exclusivity of

payment tokens as payment system at events.

Adoption of point-of-sale payment methods is a good example of the influence of a two-sided

market. (Garcia-Swartz, Hahn et al. 2006) This means that the more customers adopt a system, the

more benefit there is for the other side, the vendors, to adopt the system as well and vice-versa.

Competition is limited as a result and it is hard to introduce new systems, since at first there is little

benefit to both customers and vendors to change to the new system or add it to their range of

possibilities. (Eisenmann, Parker et al. 2006) This is less of a problem in the context of public events,

since the event-organizer has the power to enforce which payment system(s) is used at events.

15

An aspect on which far less research is available are vendors which do not accept any of the generic

payment methods offered by banks at their point-of-sale, but instead deploy a payment method

specific to their needs. Such a method can be deployed by the vendor himself, in which case he takes

on the role of payment service provider, or the method can be provided by a specialized

intermediary An example of the latter are event-organizers which employ PaySystems to run their

token-based payment system at the points-of-sale of their event, instead of one or more of the

generic payment systems. Although these systems aren’t very popular, both in practice and in

research, they’re important for this thesis, since such a system represents the current situation at

PaySystems.

The main reason for this lack of popularity is that many studies regarding customer choice of

payment instruments lists ease of use as an important criteria. (Brits and Winder 2005; Borzekowski

and Kiser 2006) Specific payment methods will require the customer to acquire a payment medium,

the tokens in PaySystems’ case, and this extra process step hampers usability from the customers

point-of-view. In situations where there is competition between vendors and a choice of which

options to offer to their customers, they will use the best methods from the customers point-of-view

to gain an advantage over their competition. In a closed environment, such as the public-events and

stadiums that PaySystems serves, this can be negated by forcing certain payment instruments upon

vendors.

2.1.3 Payment time

The payment time defines when the actual funds are transferred from the visitor to PaySystems

compared to when the purchase occurs. There are three possible scenarios for payment time: (1)

real-time payment, where the funds are transferred at the same time as the purchase, (2) prepaid

payment, when the customer buys the right to consume a product or service in advance or (3)

postpaid payment where the consumer pays after the consumption of the good or service. (Patrick

and Park 2006) The payment time is such an important design choice in payment systems since it has

a profound impact on the order of the steps in a typical payment business process. The three options

and their characteristics will be shortly discussed in this section.

Real-time payment When the actual payment coincides with the purchase of the good or service, it can be characterized

as real-time settlement. The primary characteristic is that money changes hands from payer to payee

at the moment the sale is done. This can either be cash, which physically changes hands, or a bank-

transaction, which directly transfers the amount due from the customer’s to the vendor’s bank

account. The latter can be done by debit card or some forms of internet payment, such as iDeal.

(iDeal 2011) The payment systems in this category are exclusively existing payment methods offered

by banks and financial institutions. Most points-of-sale which utilize real-time payment offer multiple

methods to accommodate their customers. These often include cash, debit/credit cards and chipknip

(Chipknip 2011). This is the most common option in retail situations, with high popularity of cash and

debit cards. (Brits and Winder 2005)

Prepaid payment Prepaid settlement includes every system in which the customer buys some form of credit in

advance, which he can use to purchase goods or services. Such a credit is often called a quasi-good.

(Van der Ven 1996) A quasi-good is an object of value that is bought in advance by the customer and

can be redeemed for a good or service at a later moment. The most important advantage of a quasi-

16

good is that at the moment when the good or services is redeemed, no payment has to occur. The

quasi-good only needs to be invalidated, either by exchanging the quasi-good for the product or

service, by physically invalidating it, for example by ripping a piece of with entry-tickets, or even

disabling the unique code by which a quasi-good can be registered in a central system. The latter

option is more and more used in ticketing, where each ticked is fitted with a barcode, which is also

saved by the seller. Each distributed barcode allows for one entry, so if the customer copies his

tickets, only one of the tickets can be used to enter.

In PaySystems’ current system, the tokens are the quasi good used. The invalidation of the tokens,

which is done by handing the tokens over to the vendor, takes very little time and it is very reliable

and robust, since no payment system needs to be functioning at the point-of-sale. These are two of

the main characteristics of public event payment and makes quasi-goods such a success in these

situations. Further, quasi-goods can increase sales due to the fact that it is no given that all sold

tickets or tokens will ever be redeemed.

A notable complication is the risk of fraud and falsification. Especially since the quasi-goods are

collected but not destroyed or invalidated in PaySystems’ case, the flow of tokens needs to be

controlled quite strictly to prevent collected tokens from returning to circulation, since this would

lead to sales without income. This can be quite costly, since much of this control needs to be done by

supervising personnel. Another cause of this is falsification, where customers are able to duplicate

the quasi-good well enough for it to be accepted at the point-of-sale. There are several ways to

prevent this. First off, by barcoding the quasi-good, duplicate uses can be prevented, but it is also

possible to simply make it very hard to duplicate the good by using watermarked paper.

Quasi-goods can also be digital, for example when store loyalty programs or public transportation

tickets are kept on a magnetic card. These digital quasi-goods must also be resistant to fraud and

falsification, just like their physical counterparts.

Postpaid payment Payment can also happen after the good or service is delivered, which is called postpaid payment.

After the good or service is delivered, the costs are in some form billed to the customers, either by a

direct debit authorization signed by the customer before or during the purchase or an actual bill sent

to the customer. A major risk in all postpaid systems is that the bill is not paid by the customer and

the vendor needs to undertake major effort to collect his payment. Postpaid payments most

commonly occur in consumer-services, such as the telephone bill and house-rents direct debits, as

well as in many business-to-business transactions for either goods or services: Situation where a

customer relation is built, because this prevents the risk of defaulting, because the customer can

easily be tracked down or service can be terminated.

In the Netherlands, direct debiting is a popular tool for postpaid payment in most business-to-

customer settings. The visitor fills out a direct debit authorization, which contains his bank account

plus his signature and by this empowers the vendor to subtract the amount due from his bank

account. After this sign-up the debit of the visitor is tracked, so either periodically or after the

delivery of goods or services, the payment is requested from the visitor’s bank account. Should this

fail, most commonly due to a too low account balance, the visitor becomes a debtor of the vendor

and the amount needs to be billed. The visitor needs a to identify himself at the point-of-sale, so the

debit can be processed properly.

17

2.2 Developments in retail payment systems Now that the most common characteristics of payment systems at the retail point-of-sale and the

current payment market are briefly discussed, attention will be given to the developments in this

field and the prospects for new payment systems and new stakeholders in the payment market. The

payment system market is fast-developing, mainly due to a push of new technologies which are on

the rise. One of the main reasons is that electronic payments are generally found to be less costly

than non-electronic payments, such as cash and cheque payments. (Brits and Winder 2005) Other

drivers are new collaborations between countries in the Eurozone, such as SEPA, (Currence, DNB et

al. 2008) which remove the geographical boundaries for electronic payment in Europe, much the

same way the Euro removed these boundaries for cash payments.

Since development is pushed by new technological possibilities, this chapter is organized around

research on the most important technologies facilitating new payment systems at the point-of-sale.

Three of the most promising technologies will be shortly discussed here: 2D barcoding, contactless

payment and NFC payment. Some examples will be included in which these technologies are already

used, either in pilots or in fully functioning payment systems.

2.2.1 2D Barcoding

The traditional 1D barcode has been around for decades as a way to visually store information that is

readable by a machine. It is a fast and inexpensive way to encode and read information in for

example logistic chains and retail stores. (Gao, Prakash et al. 2007) Its main applications are

identification of a certain product or product group. For example, at many retail points-of-sale the

barcode of a product is scanned to identify the product. The checkout terminal uses the code to

retrieve the proper information about the product, such as the prize. Barcodes can also be used to

identify customer accounts. Many customer loyalty programs use plastic cards with a barcode which

allows the customer to identify himself at the point-of-sale.

Textbox 2.1: Starbucks Card Mobile App

The Starbucks Card has existed for some time in its plastic form: A pre-paid card by which

customer could pay for their purchase at Starbucks stores. It contains a barcode which is

scanned at the point-of-sale. The account balance is then checked from a central database and

the proper amount deducted.

After a successful pilot, it is now possible to load the pre-paid Starbucks Card on the mobile

phone of the customer using the Starbucks Card Mobile App. (Starbucks 2011) The barcode is

then saved on the mobile phone and customer can use it to pay at Starbucks in much the same

way they could use the card. However, the app includes features to view the remaining account

balance on the Starbucks Card account and reload new credit onto the account. One of the

strong aspects of such a system is that the plastic card and phone app are compatible: they both

are coupled to the same account, so should a customer have a dead battery for example, he can

still use his card to pay from his account. This is a good example of a specific payment system,

which is only usable at Starbucks and due to the relative high amount of effort required to use it

only fit for frequent customers. But since it offers some important benefits tailored to this

customer segment via a reward program, it is compatible with the plastic Starbucks Card and is

not the only possible payment instrument for customers it has a good chance of successful

adoption.

18

With the advent of Smartphones and the multitude of apps developed for them, a

new generation of 2D barcodes has arisen, such as the QR-Code of which an

example can be seen in Figure 2.1. A common application of these barcodes is in

mobile-marketing, where an app on a phone is able to read the information in the

barcode and direct the user to the webpage of the advertiser. The main

advantage of 2D barcodes is that they are able to store much more information

than the conventional barcodes and are thus more widely usable. (Arendarenko 2009)

These barcodes, along with the rise in mobile (smart)phone adoption, have already been successful

in retail payment scenarios. The worldwide operating Starbucks Coffee Company has leveraged

these possibilities into a payment system (Starbucks 2011), which is currently being deployed in the

United States after a successful pilot. Textbox 2.1 provides some additional information on this

system.

2.2.2 Contactless payments

Contact smart cards are already used as payment instrument in the Netherlands for some time, the

most notable example is the Chipknip, an electronic purse which is kept on a chip on Dutch debit

cards. (Chipknip 2011) A customer can load credit on his card at special reload stations and then can

pay be inserting the card at the point-of-sale terminal and pressing an ‘OK’-button. Adoption has

lagged however, since there is little benefit compared to using the debit card itself. The main

difference at the point-of-sale is that the customer does not have to enter his Personal Identification

Number (PIN). The extra process step of loading credit onto the card is not worth the trouble to most

customers, even when they already use the Chipknip in scenarios where it is the only (electronic)

payment solution, such as vending machines or parking meters, since this would require them to

reload more often. (CardTech 2000)

Contactless chips, which work by the Radio Frequency Identification (RFID) standard (ISO/IEC 2008),

offer more substantial benefits for customers and vendors compared to traditional payment

instruments and therefore stand a better chance of widespread adoption. Contactless chips can store

information, which can be read and (re)written by a RFID-reader, which communicates with the chip

on the card via an antenna. (ISO/IEC 2008)

A payment with a contactless chip can be done by simply holding the device containing the chip in

close proximity to the card-reader. The reader either reads the chip’s ID and deducts the amount

from the corresponding account in a central database or deducts the amount from the balance on

the chip itself. The main benefit is that such a transaction at the point-of-sale is faster and easier

than with a contact card, since the customer does not have to insert his card in the terminal or

confirm his transaction: he can simply tap the device containing the chip against the reader and the

transaction is conducted. Another advantage is that in contrast to a contact card, the chip need not

be build into a card, it can also be in the form of a key-fob, included in a wristband or a RFID chip

from a mobile phone can be used. An important note is that these chips work passively: They get

their power from the electromagnetic field, so they need to be close by the antenna to function.

MasterCard’s PayPass (MasterCard 2011) is a contactless extension on the normal credit/debit card

infrastructure offered by MasterCard and issuing banks. Textbox 2.2 provides more information on

the MasterCard PayPass system.

Figure 2.1: QR-Code

19

The OV-Chipkaart (Teepe 2008), briefly described in the previous section, is an example of a payment

system which is specific to several vendors, in this case Dutch public transportation, and also uses the

contactless chip on the card to store the account balance and additional travel products, such as

discount plans. These examples show the wide range of possibilities for payment with contactless

technology.

2.2.3 Mobile NFC payment

An extension to the contactless chip technology described in the previous section is Near Field

Communication (NFC). (ISO/IEC 2010) NFC chips use the same radio frequency communication

standard as the contactless chip, but they are able to function in two ways: both as a reader and as a

sender of data. This makes (payment) applications possible with more functionality than just the

contactless chip, an example of which could be customer-to-customer transfers between users of the

payment system themselves. (Balan, Ramasubbu et al. 2009)

Contrary to contactless chips, the NFC chip does require power, so it is not usable as stand-alone

device like a contactless chip, but needs to be integrated into a device with a power source, most

commonly a mobile smart phone. (Alliance 2007; Van Damme, Wouters et al. 2009) This currently is

a problem in adoption of NFC based applications. Although expectations for the future in the

medium to long-term are quite good, there are currently only a few smart phones on the market

with an NFC chip. (Crowe, Rysman et al. 2010)

However, because the same RF-technology is used as contactless chips, there is compatibility

between the two. This allows for the implementation of a system compatible with both technologies.

The basic functionality will need to be possible for all users, whether they’ve got an NFC enabled

device or a contactless chip. Additional functionality can then be available for NFC users, who will

probably grow in number over the years and once NFC chips are a commonality, the contactless

option becomes deprecated. A common implementation of this is a contactless chip inside a sticker

that can be attached to for example a mobile phone without NFC to enable these phones to also

process payments like their NFC enabled counterparts. Rabobank is currently conducting pilots with

such stickers. (News 2010)

Textbox 2.2: MasterCard PayPass

MasterCard PayPass uses the conventional credit card infrastructure. Customers with a

credit card can request their card to be outfitted with a contactless chip or obtain a key-fob

or mobile phone app by which they can pay contactless at vendors which have PayPass

contactless payment terminals by tapping their device (card, fob or phone) against the

terminal. The payment will then be processed in the same way as a regular MasterCard

payment. The compatibility with the credit card infrastructure and multi-platform

applicability makes PayPass a system with good future prospects. (McGrath 2006)

The PayPass system is a good example of how the contactless technology is used as generic

payment system, usable at every vendor who connects to this infrastructure. In this case the

contactless chip is used to identify the customer and the payment is conducted at the central

payment system of MasterCard.

20

Due to the adoption issues, NFC based payment systems are still in their development and trial

phases. Google is one company actively pursuing NFC payment in their Google Wallet application,

more on which can be read in textbox 2.3.

2.3 Payments at public events A quick look at typical payment scenarios and systems at public events and in stadiums will be taken

here. Some important characteristics for these payment scenarios will be uncovered here. It is

important to note that there is little literature specific to public events, due to the limited size of the

market and the specific characteristics. There are however other markets which have similar

payment characteristics as public events. These will be important studies to look at when designing a

payment system for public events and thus will also be shortly discussed here.

There are three primary payment scenarios at public events: Payment for tickets at the front door,

payment for food and beverages and other retail payments, such as merchandising. The focus in this

entire thesis is on food and beverage payment, since these are the payments in which PaySystems

currently specializes. This is because the food and beverage sales are the only scenario in which

generic payment is not fast enough. Most of the tickets are paid in advance and merchandising

purchases occur much less frequent than food and beverage payments. The rest of this section will

therefore focus on payments for food and beverages.

2.3.1 Characteristics of food and beverage payments

This paragraph will discuss the most important characteristics specific to food and beverage

payments at public events and in stadiums, based on interviews with PaySystems as well as a case

study on a payment system in the Portuguese football stadium Alvalade XXI. (O'Callaghan 2007) In

Alvalade XXI, a system with prepaid cards was implemented. Visitors could buy a card for a certain

amount with a barcode on it which was linked to a credit account which held that amount. During a

point-of-sale payment, the barcode is scanned and the amount due is deducted from the credit

account.

Efficiency Most token purchases in the current payment system of PaySystems are made with cash. So, why not

pay directly with cash at the retail point-of-sale? The main answer is that cash is cumbersome and

transactions are relatively slow. (Balan, Ramasubbu et al. 2009; Polasik, Górka et al. 2011) Due to the

large transaction volume and often high peak moments, for example at half-time during sporting

events or between acts at festivals, it is critical to have a high efficiency at the point-of-sale for the

Textbox 2.3: Google Wallet

Google already has NFC enabled phones on the market, such as the Nexus S, (Google 2011) and

are developing the Google Wallet, which connects to the MasterCard PayPass infrastructure,

discussed in the previous section on contactless payment. In addition to the basic retail

payment functionality, the users with an Android phone with Google Wallet can also receive

mobile-marketing offers on their phone, such as advertisements and loyalty programs, (Google

2011) and there are improved security options, such as blocking the use of the wallet with a

passcode.

21

sales volume. A low efficiency is also costly due to the added personnel requirement for vendors.

This was also one of the main considerations in the choice for the system at Alvalade XXI:

“The system was meant to avoid the use of cash thereby shortening the time it took to execute

payment transactions. For clients, this meant shorter queues at the bars. For Casa XXI, it meant

more productivity of their bar personnel, faster turnaround, and more sales at peak times. In

addition, it reduced the need for controlling cash registers and bartenders” (O'Callaghan 2007)

Parties like PaySystems and Alvalade come up with their own system, because as is clearly visible in

Polasik, Górka et al. (2011), the performance of the most common current electronic payment

systems on the efficiency aspect is even worse compared to cash. The new technologies discussed in

the previous section, such as contactless and NFC payment are more promising. (Polasik, Górka et al.

2011)

Robustness The sale of food and beverages is a critical part of operation of every public event, whether it is an

outdoor music festival or a match in a soccer stadium. The reason is twofold: A good deal of the sales

revenue is used to fund the event and loss of sales is thus a serious threat not only to vendors, but

also to event-organizers. Second, customers will be very dissatisfied if they cannot buy food and

drinks.

Events also take place in often unpredictable environments and temporary locations. It is therefore

not only extremely important that the system is reliable and robust, but the conditions are very

difficult. The Alvalade XXI stadium case (O'Callaghan 2007) shows what happens when a system does

not function properly: People gets upset, revenue is lost and there is almost no control over money

at the point-of-sale. One of the reasons that the system did not function properly was the weather,

which can be even more of a factor at outdoor events than in a stadium.

Revenue Sharing Another important aspect to consider is that at many events there are revenue sharing agreements

between the food and beverage vendors and the event-organizer. This mostly means that a

percentage share of the revenue goes to the event-organizer, which uses it as funding for the event.

A good system for controlling the financial flows at the event is therefore important. Cash payments

at the point-of-sale cannot be tracked by the event-organizer and thus it’d be easy for vendors to

suppress their sales numbers. This is added incentive to employ a payment system which makes it

easy for event-organizers to control financial flows. In the token-based system of PaySystems this is

done by diverting all revenue to PaySystems during the event. Afterwards, the event-organizers and

vendors are each given their share of the revenue.

2.3.2 A comparable situation: Public Transportation

One of the other sectors that has similar characteristics is the public transportation market.

Efficiency, robustness and revenue sharing are important concerns there as well. There are many

people using public transportation and speedy processing when they want to enter a bus or train is

very important for their convenience and thus the overall success of the transportation system.

There are similar concerns on robustness: When for example the terminals fail to process

transactions, commuters can travel without payment, which of course cuts into the revenue. Public

transportation is also a sector in which revenue sharing is common. In fact, it was the primary reason

22

quasi-goods, tickets, are used almost exclusively in this sector and currently, for the introduction of

the ‘OV-Chipkaart’ in the Netherlands. (Teepe 2008)

The public transportation market has always been a sector in which many specialized payment

instruments were used, such as ticket plans, long-term subscriptions, multi-day unlimited travel

tickets etc. Over the last years there has been a move to new electronic payment instruments, such

as contactless solutions, for payments in public transportation. Not only can these contactless cards

contain an account balance by which commuters can pay fares, they can also contain ticket plans or

subscriptions. Examples are the OV-Chipkaart in the Netherlands (Teepe 2008) and SmarTrip in

Washington D.C. (WMATA 2011) Due to the many similarities with the event market, these systems

will frequently be used for reference in this thesis.

23

3 Business Model In this chapter the current business model of PaySystems will be described. The purpose of this

analysis is to gain more insight in how PaySystems creates value for its customers and how it

captures value to make profit. It also explicates the most important strategic choices on which

PaySystems operates. This will allow for a good insight in what business goals and requirements are

important and for a thorough evaluation of the business implications of the different options for an

electronic payment system proposed in this thesis.

For all the considered electronic payment systems, the business model of the current situation at

PaySystems can be used as a baseline to uncover the business implications that the change to the

new system brings along. Some payment systems may require PaySystems to collaborate with

additional partners to enable the creation or operation of the system or the cost structure associated

with the operation of the payment system may change. A new payment system may also lead to new

possibilities. For example, other customer segments may become interested in utilizing the payment

system deployed by PaySystems or additional revenue streams may present themselves.

First off, a short introduction into business modeling is given and then the framework which is used

to model the current situation at PaySystems is presented. There are many business modeling

approaches, which all offer different characteristics and therefore supplementing ones will be

integrated to cover all aspects of the business model of PaySystems.

The business model will then be filled in for the current situation of PaySystems. This will be done in

collaboration with employees of PaySystems themselves and by observation of all activities before,

during and after events. the model will be validated together with PaySystems. This should give a

clear, in-depth overview of PaySystems, which can be used later on to evaluate the business

consequences of each option for electronic payment.

3.1 Business modeling Business modeling has played an increasingly important role in many organizations over the last

years. A business model is a conceptual tool used to help understand, explicate and communicate

the way an organization creates and captures value. (Osterwalder, Pigneur et al. 2005) To create a

good understanding about what a business model is, it is important to consider its position compared

to other methods to describe an organization. Al-Debei and Avison (2010) makes this positioning

quite explicit in their comprehensive review of business modeling. According to Al-Debei and Avison

(2010) a business model is a link between the strategy and the (IS-enabled) business processes of the

organization. It explicates the strategic choices that an organization makes and describes how the

organization is going to execute its strategy in terms both business and technology stakeholders can

understand.

Business modeling is a relatively young field of research. In the 1990s the term rose to prominence

and was especially used by high-tech companies, who used business models to pitch their proposals

to other stakeholders, mainly potential investors. (Shafer, Smith et al. 2005) These companies were

able to explicate and communicate quite easily to these investors how they were going to create

value for their customers and capture this value into a solid revenue stream. Investors on the other

hand were able to assert the (economic) viability of the business plan of the company by testing the

assumptions on which the model is based. This showed the power of the business model approach

24

and nowadays, business models are used in a much wider context by all kinds of different

organizations.

A lot of research on business models has been done already, especially in the first years of the

millennium, when a lot of different ontologies and frameworks regarding business modeling were

presented in literature, such as the ‘Business Model Ontology’ by Osterwalder (2004) and the ‘e3

Value ontology’ by Gordijn (2004) which added to the already existent, but less comprehensive

models, such as Porter’s ‘Five Competitive Forces’ (Porter 1979) and the ‘Resource-Based View’

(Wernerfelt 1984).

Each one of these frameworks for business modeling has arisen from a different area and with

different original purposes in mind. The e3 Value framework (Gordijn 2004) for example is very much

focused on value exchanges between different actors and has less emphasis on the internal

capabilities of the firm it is modeling. This leads not only to different models, but also to differences

in the definition and functions of business modeling. (Shafer, Smith et al. 2005) This means that the

business model concept remained vague, was described as ‘murky’ (Porter 2001) and that knowledge

about business modeling was fragmented.(Al-Debei and Avison 2010)

Over the last years, there has been a movement by quite some researches with the goal to expand

the applicability of these ontologies to other areas (Weigand, Johannesson et al. 2006; Sheenan and

Stabell 2007) and even to create reference ontologies (Morris, Schindehutte et al. 2005; Andersson,

Bergholtz et al. 2006; Al-Debei and Avison 2010) for business modeling. These reference ontologies

try to clear up the concept of business modeling by reviewing widely known and used literature on

business models and present a clear definition of elements, functions and other aspects of business

modeling, with the goal to capture the different viewpoints into a single framework. These efforts

have created a bit more consensus and the elements of these reference ontologies will therefore

form the basis for the analysis done in this thesis.

In the coming sections some attention will be given to the different functions that business modeling

has and to how these relate to the overall goal of this document, which is evaluating the impact of

potential electronic payment systems on PaySystems from a business point-of-view. Then the

elements of business models, which are defined in the reference ontologies will be described. Finally

the elements which will be used for the analysis of the business model of PaySystems will be given.

3.1.1 Business Model Functions

Business modeling ontologies, such as Gordijn (2004) and Osterwalder (2004) have emerged from

different areas and with different goals in mind. Therefore, the functions for which they are used

vary somewhat. Al-Debei and Avison (2010) identifies three primary functions of business modeling

from their extensive literature review on business modeling: (1) alignment between business and IT,

(2) interceding framework between technology and attainment of strategic goals, and (3) explicate

strategic-oriented knowledge in the organization. These will be briefly discussed here in order to

explain why the use of business models is deemed useful for analyzing the different digital payment

options for PaySystems.

Alignment between business and IT One of the most important issues in information technology over the last decades is proper

alignment between business and IT. (Henderson and Venkatraman 1993) An organization is said to

25

have a good alignment between business and IT if the IT department and IT enabled business

processes are in line with the strategic objectives of the organization. (Luftman 2000) This enables

the creation of business value from IT initiatives and helps to maintain a high effectiveness of the IT

enabled business processes.

Business models are typically situated between the business strategy and the business processes of

an organization. (Al-Debei and Avison 2010) They argue that the gap between business strategy and

business processes is becoming increasingly large, due to the more dynamic business environment

and high level of uncertainty in the technology-driven digital business. The business model is a tool

which explicates the business logic and strategic choices of the organization and therefore can be

used to align the IT enabled business processes to the strategy of the organization. (Osterwalder,

Pigneur et al. 2005; Al-Debei and Avison 2010)

Over the last few years there have some quantitative studies that found a positive relation between

organizational performance and business-IT alignment. (Papp 1999; Sphilberg, Berez et al. 2007) A

good alignment is therefore important to many organizations. When designing the digital payment

system, some changes will occur to the primary business process of PaySystems. The business model

can be a useful tool to ensure a proper alignment between the electronic payment process and the

strategy of PaySystems.

Interceding framework between technology and strategic goals Business models can also serve as an interceding framework between technology and the attainment

of strategic goals. In this way, a business model is used to show how value for the organization is

created and captured by a technological innovation or artifact. (Chesbrough and Rosenbloom 2002;

Al-Debei and Avison 2010) This was the most popular initial use of business models, when dotcom

initiatives where pitched to potential investors using business models. (Shafer, Smith et al. 2005)

It forces technology stakeholders to think not only about the potential of their initiative, but also

about the market characteristics they will encounter and how they will use their technological

initiative to make money in this market. (Chesbrough and Rosenbloom 2002) On the other side, it

allows business stakeholders to understand what the possibilities of the initiative are in a fast and

easy way. (Osterwalder, Pigneur et al. 2005)

The main difference between the interceding framework function and the alignment function of

business models is that alignment is top-down, while the interceding framework is a bottom-up

approach. When a business model is used primarily for alignment purposes, the business strategy of

the organization is the starting point from which a business model is constructed. It is then used as

input when designing the business processes. When a business model is used as interceding

framework, the technology forms the basis on which it is constructed, along with the strategic

choices of the organization and market concerns. This business model can then be used to validate

the value creation and capturing potential and the fit it has with the business strategy of the

organization.

This is the main function for which business modeling will be employed for PaySystems. The market

and organizational characteristics will be modeled in this current business model. Along with the

requirements for a new system, different options for the realization of this new system can be

evaluated.

26

Explicate strategic oriented knowledge The knowledge which is captured in a business model, on the core logic on value creation and

capturing and the strategic choices of the organization, is very important for strategic decision

making functions. (Al-Debei and Avison 2010) Explicating this knowledge in a business model helps

business managers maintain a uniform view on these matters. This knowledge is always at least

tacitly available, since it is the foundation on which an organization operates. But in organizations in

which no business model is explicated, different managers can have different views on the strategic

choices of the organization (Osterwalder, Pigneur et al. 2005) or in large organizations, managers can

have trouble maintaining a high-level overview of how value is created and captured. (Shafer, Smith

et al. 2005)

For any organization it is a good thing to have this knowledge explicit, since it helps employees to

understand their organization more thoroughly and share views with other employees. (Osterwalder,

Pigneur et al. 2005) Since PaySystems is looking to change its primary business processes by

implementing a form of electronic payment, it is important that all involved employees can share

their knowledge about PaySystems and make more informed decisions.

3.1.2 Elements of a business model

Now that the goals of business modeling are clear as well as how the business model will actually

help to achieve these goals, it is time to look at what aspects of the business will be a part of the

business model analysis. As well as different functions, each ontology has its own set of elements,

which differs slightly from the other ontologies. This is due to the different backgrounds of the

researchers and the intended goals for the business model ontology. Both Osterwalder, Pigneur et al.

(2005) and Shafer, Smith et al. (2005) offer extended comparisons of the elements mentioned in

different business modeling studies. These studies and Al-Debei and Avison (2010) offer ontologies

which incorporate all elements found in their literature review.

All three ontologies categorize elements into four main categories, but they are not quite the same.

When combining the elements of all three studies, five categories seems a better fit. This

categorization is given in Table 3.1 below. The category ‘value-network’ (Shafer, Smith et al. 2005; Al-

Debei and Avison 2010), is combined with ‘value-architecture’(Al-Debei and Avison 2010) / ‘Create

value’ (Shafer, Smith et al. 2005) to form ‘Infrastructure Management’ (Osterwalder 2004). In turn,

Osterwalder (2004) has a separate category ‘Customer Interface’, while these concerns are discussed

in a lesser degree in the other ontologies and therefore included in ‘Strategic Choices’ (Shafer, Smith

et al. 2005) and ‘Value proposition.’(Al-Debei and Avison 2010)

Al-Debei et al., 2010 Osterwalder, 2004 Shafer et al., 2005

Value proposition Value-proposition Value proposition Strategic choices

Value architecture Value-architecture Infrastructure management Create value

Value network Value-network Infrastructure management Value network

Finance Value-finance Financial aspects Capture value

Customer interface Value-proposition Customer interface Strategic choices Table 3.1: Business model element categories

Every element from these three ontologies is categorized in one of these categories. A complete

table of the categories and their elements can be found in Appendix A. These elements will form the

basis on which the business model of PaySystems will be analyzed in the following chapter. To help

27

cover all important aspects regarding payment within these categories, a more industry specific

business model framework will be used as well.

Pousttchi, Schiessler et al. (2009) proposes a framework for mobile payment business models, which

is based on the Business Model Ontology of Osterwalder (2004). In this framework, for every of the

nine business model building blocks of the Business Model Ontology the main characteristics for

mobile payment are discussed and the main strategic choices are given. To ensure that the business

model is as complete as possible, all characteristics of Pousttchi, Schiessler et al. (2009) will be

incorporated in addition to all elements from appendix A. This should allow for a more complete

analysis on the impact of the change to a digital payment system.

3.1.3 Discussion of business modeling

In this section the practical issues encountered during the description of PaySystems’ business model

are shortly discussed. Further, the interaction and differences between the general ontologies and a

more specialized approach, in this case the Pousttchi, Schiessler et al. (2009) framework for mobile

payment, will be discussed.

Business modeling issues The Pousttchi, Schiessler et al. (2009) framework for mobile payment business models is directly

based on the business model building blocks by Osterwalder (2004). As noted in the previous section,

this is only one of many business model ontologies. The direct consequence of this is that in the

tables from Pousttchi, Schiessler et al. (2009), used in the next section to fill in the business model,

some important aspects from the other business model ontologies are omitted. This is mitigated in

part by checking off that all elements described in these ontologies, organized in appendix A, are

discussed in the accompanying text. Good examples of these are external market factors, such as

competition, and the ways in which the organization differentiates itself. While it could be argued

that external factors are strictly not part of a business model, it is very important towards assessing

the profitability and sustainability of a business model in a market.

While the elements offered by the different ontologies present the most important aspects which

need to be discussed, these elements are on a fairly high level. It is very hard to ensure that in a

specific situation all important aspects are covered just by following these elements. This is the

primary reason that the Pousttchi, Schiessler et al. (2009) framework is used: it explicates the specific

concerns regarding (mobile) payment for each business model element. But every situation remains

different and there is little research on how to achieve completeness.

Since the field of business modeling still lacks an underlying theoretical basis (Pateli and Giaglis 2003;

Al-Debei and Avison 2010) it is very difficult to demonstrate that a described business model is

correct and complete. The construction of a business model therefore remains a ‘best-effort’ activity:

by using a wide array of ontologies and validating the outcomes with people from in- and outside the

organization, one can strive for an as good as possible model.

Threat considerations The final building block that is considered by Pousttchi, Schiessler et al. (2009), but not by any of the

used reference ontologies, is the ‘threat model’. It describes potential threats to the success of the

business model in question. Although it is not considered in the other ontologies, it frequently

features in other, more strategy oriented tools, such as Porter’s ‘Five Competitive Forces’ (Porter

28

1979) and the ‘SWOT-analysis’. (Piercy and Giles 1993) The description offered by Pousttchi,

Schiessler et al. (2009); ‘potential and profound threats to the economic success of an m-payment

business model’, implies that it is not a part of the business model itself, but a criterion which can be

used to evaluate a business model.

One of the functions of business models according to Pateli and Giaglis (2003) is to identify the risks

for a firm pursuing innovation. In the same way that the financial aspects of the business model

evaluate the profit potential of a business model, risks to the short- and long-term feasibility of the

business model can be analyzed. The reason that financial aspects are a part of all business model

ontologies and the threat model is not, is that the organization has options when it comes to cost

structures, for example make-or-buy decisions, and revenue streams, such as pricing mechanisms,

while threats are part of the environment.

While these threats and risks can be mitigated, this is mostly done by adapting elements of the

business model itself. It therefore can be argued that for each business model in each environment

an analysis can be made to find possible threats. If after this analysis the business model is changed

to mitigate these threats, for example by setting up a key partnership, a new threat analysis can

uncover entirely new threats, such as the reliance on this new partner.

To recap, threat considerations are important to assess the viability of a business model, therefore

they are featured in many strategic tools. They are not featured in the business model, because

unlike financial aspects, the organization has no choice in them. Rather, threats are a consequence of

the business model and the environment in which it will be deployed. Mitigation of threats is done

by adapting the business model. In the subsequent analysis, the threat model is therefore not

considered part of the business model. Threats will be handled in the evaluation of PaySystems’

business model in section 3 of this chapter.

3.2 Business Model PaySystems In this section the current business model by which PaySystems operates will be analyzed. This will

be done by dividing the business model into the five categories described in the previous paragraph

and tackling all the elements which need to be addressed in these categories. See Appendix A for an

overview of the categories and their elements. Since the goal of this analysis is to create a solid

reference on which to draw conclusions about the impact of the change to various electronic

payment systems on PaySystems, the elements from the more industry specific business model

framework of Pousttchi, Schiessler et al. (2009) are used as well. The complete business model of

PaySystems, including the elements from the Pousttchi, Schiessler et al. (2009) framework, is

presented in Appendix B, in this section the most important elements going forward are highlighted

one category at a time.

3.2.1 Value proposition

PaySystems offers event-organizers a reliable and efficient payment solution for food and beverage

sales at public events, which increases sales revenue and allows close financial monitoring of the

financial flow at the event. They provide this system on a full-service basis at the event, so the event-

organizer, the customer of PaySystems, doesn’t have to concern himself with payment. This is

especially important, since most events are in part funded by food and beverage sales.

29

This value proposition covers the three main characteristics of retail public event payments

presented in the previous chapter: efficient payment due to the use of the tokens at the point-of-

sale, reliability since there is no electronics involved because the real-time payment is done at the

vending of the tokens and supporting the revenue share by keeping strict control on the financial

flows at the event. The increase in sales revenue, the fourth important element of the value

proposition is not covered in these characteristics, because it is not a characteristic of the payment

itself, but a goal of the most important stakeholders: event-organizers and vendors. Together these

four aspects form the core of the payment system and performance on these issues is the main

reason why customers choose PaySystems.

The market of PaySystems is currently quite limited, since the price is quite high. This means a lot of

event organizers are not interested in PaySystems, especially when there is no revenue share or

when they do not profit from increase in sales revenue.

3.2.2 Customer interface

The acquisition of new customers is a time consuming process, since it most often includes an active

sales force and the price is often negotiated in contracts. This is further complicated by the fact that

the event market is quite volatile. New events and event-organizers enter the market quite

frequently, while other events are discontinued. Therefore it is important for PaySystems to

negotiate as much long-term commitments as possible to ensure a stable income.

3.2.3 Value architecture

The current system is not easily scalable due to the heavy use of both tangible and human resources,

which already leads to capacity problems at the moment. There are three primary reasons for this:

First, the planning before and handling after the event is labor-intensive, so the number of events

that can be serviced in a certain period is limited. Second the most important infrastructure used

during operation of the event, such as vending machines and token-dispensers, is limited in number.

Finally, there is limited personnel available to run the system during the event, especially specialized

personnel, such as supervisors and technical staff.

An important intangible resource of PaySystems is its excellent reputation in the event market. Once

you hire PaySystems that they will take care of everything involving payment and finances, and that

it is done right.

3.2.4 Value network

PaySystems has two key partnerships. The first is Food and Beverage (FAB), another label of LOC7000

which organizes food and beverage sales for event-organizers. They run beverage sales themselves

and recruit food vendors to sell at events where they’re hired. They always work in combination with

PaySystems. Together they can arrange the entire catering at an event and take away these concerns

for the event organizer, while maximizing his income from catering.

The second important partnership is with Dutchband B.V., a company which supplies tokens to

PaySystems, but is also highly involved in especially the technical development of the payment

system, from improving the vending machines to leveraging new connection possibilities, such as

satellite uplinks for the payment system and wireless connectivity at events.

30

3.2.5 Finance

There are two main cost pillars of the current system: The infrastructure costs, since there is a lot of

hardware involved in the payment system, such as vending machines, token dispensers and IT

equipment. The large costs are the operational costs of the system, which consist of the costs of the

tokens themselves, the transaction costs of the sales of tokens, both change for cash transactions

and the fees for debit/credit card transactions, and finally the personnel costs. This last aspect is the

largest, since there is a lot of sales staff, technical staff and labor hours before and after the event.

PaySystems is paid a previously negotiated fee for deploying the system. This fee can be dependent

on the food and beverage sales or it can be a fixed fee, based on the incurred costs plus a mark-up.

3.3 Business model evaluation In this section the business model of PaySystems will be evaluated. The purpose of this is to analyze

whether the business model is profitable and what the key factors are which determine the

profitability. Further, the long-term sustainability of the business model will be discussed, using an

analysis of possible threats to the success of the business model.

Pateli and Giaglis (2003) asserts that the evaluation of business models is one of the least mature

areas of business model research. This study uncovers four primary evaluation functions:

Comparison with competitors,

Assessment of alternative Business Models,

Identification of risks and potential pressure areas,

Evaluation of in terms of feasibility and profitability.

For the purpose of evaluating the current business model of PaySystems, described in the previous

section, the second function is less relevant, since the current business model is firmly entrenched

and thus there is only one business model to consider. In the definition of business models given by

Osterwalder, Pigneur et al. (2005), the last phrase reads “… to generate profitable and sustainable

revenue streams.” These two factors, profitability and sustainability, feature frequently in other

papers, such as Stewart and Zhao (2000) and Morris, Schindehutte et al. (2005), and they will be used

here to evaluate PaySystems’ business model. In the evaluation of the sustainability current and

future competition will play an important role.

Profitability PaySystems has proven itself to be quite profitable. The last years have proven that the business

model can be executed profitable and the prospects for the future remain positive in this regard. The

event market in the Netherlands is growing rapidly, especially the weekend-long festivals.

(Taalwaardig 2011) While the market is volatile and many events discontinue from year-to-year, they

are replaced by many more inaugural editions. An additional benefit is that this causes greater

competition between event-organizers, which puts pressure on their financial results. Improvement

of food and beverage sales and the stricter financial control PaySystems offers becomes increasingly

important in the market. This is further compounded by the fact that subsidies from the government

are becoming increasingly harder to come by, which forces events to become financially

independent.

The downside of the market volatility is that these new events must be acquired as customers by

PaySystems. To remain profitable, it is important for PaySystems to maintain a high utilization of its

31

capital, especially the token vending machines. They are costly to acquire, but do save on operational

costs. With fewer events, it’ll become harder to recoup the investment. So, it’s important to service

as many events as possible and to actively pursue the many new events. PaySystems is focusing on

long-term commitments with customers which have many events, such as stadium operators and big

event-organizers with multiple events a year, to ensure revenue streams over a long period.

Research and development is also focused on these customers, with new ‘venue machines’ which are

meant to be permanently deployed at venues with many events, such as stadia and big music and

event venues.

Sustainability To assess the sustainability of PaySystems’ business model going forward, an overview of the most

important competition that PaySystems faces will first be given, since this a very important

consideration when assessing sustainability. There are two types of competition which are

considered: Direct competition on the niche-market in which PaySystems operates and competition

from payment providers operating in the broader payment market.

PaySystems currently has little competition in the event payment market. While there are other

providers of payment solutions, they mostly deliver only elements of a payment system instead of a

full-service approach. An example of this is Dutchband, which not only provides tokens to

PaySystems, but also to event-organizers, sometimes coupled with hardware, such as debit card

terminals or token dispensers. But these event-organizers need to deploy the system themselves.

While the possibility is of course there for new entrants in the market to develop a payment system

specific to the event market, this is not considered likely, since the niche is quite small and

PaySystems has a solid hold on the market with their partnership with FAB and their long-term

contracts. This makes it an unattractive niche market to enter.

There is however more of a threat in the future from payment providers which service the entire

payment market. PaySystems’ business model may be enveloped by their more generic payment

systems. Enveloping means that an offering for a more generic market negates the competitive

advantage that a firm has in a niche market and thus makes it obsolete. (Eisenmann, Parker et al.

2006)

The payment system of PaySystems is specifically tailored to the event market and therefore

outperforms generic payment methods offered by banks, such as debit/credit card payment and cash

payments. Many firms, banks and other organizations, are however pursuing new payment methods,

which can have a profound effect on the payment market as a whole. Some examples are PayPal

(PayPal 2011), a digital wallet which allows for internet transactions, but also cashless payments at

the retail point-of-sale, such as MasterCard’s PayPass (MasterCard 2011). But also the OV-Chipkaart

(Teepe 2008), which is primarily used for public transport ticketing and payment, can be used to pay

at some station shops and expansion can’t be ruled out.

These payment options may close the performance gap with PaySystems’ payment solution and can

become a serious alternative for the customers of PaySystems. To negate this risk it is important for

PaySystems to stay ahead of the curve and take the first steps towards improving its business model,

leveraging the new possibilities offered by technological innovation. This is already being done, for

example by developing new ‘venue vending machines’, which are stationary vending machines,

meant to be permanently placed at venues which have a lot of events, such as football stadiums.

32

Looking for alternative digital payment systems, which is done in this thesis, is another step in this

direction.

33

4 Requirements Specification In this chapter the most important requirements regarding a digital payment system for use at public

events will be described. However, since there are many design choices which still need to be made,

the functional requirements are high-level in nature and capture only essential functions and tasks

which any system will need to be able to fulfill. For example, the payment time (prepaid, real-time or

postpaid), dictates many of the functions the system will need to include. Increasing an account

balance is only a necessary part of the system in the case of a pre-paid money account.

Further, there is an emphasis on the business goals this system needs to help achieve and quality

requirements and constraints, since these can be used to weigh different options against each other.

When there is a more thorough overview of what the system is going to look like, more elaboration

on the functional requirements can be given and the quality requirements can at that point be

quantified more accurately.

This section first introduces requirements engineering and explains the concepts that will be used to

elicit and formulate the requirements for the digital payment system. The requirements will then be

given in a structured way, starting up top with the business goals and working down to system

functions and quality requirements.

4.1 Introduction “A requirements specification is a document that describes what a system should do.” (Lauesen

2002) Making this document is referred to as specifying requirements or requirements engineering.

Requirements specifications are used for many things during system development, including serving

as a contract between the customer and the supplier of a system, describing everything the system

should do and how it performs. Later on, the requirements specification is used as input by the

designer of the system. Since in this phase the system is built with the goal to fulfill all requirements

from the specification, it is vital that they accurately match the actual demands of the customer.

Should this not be the case, the customer may end up with a system, which does not help him reach

his business goals, while it does fulfill all requirements and hence complies with the contract

between customer and supplier. (Lauesen 2002)

It is therefore easy to see that for an information system to be successful, the requirements should

accurately fit with the business goals the system should help achieve. This makes requirements

engineering a critical step in the overall process of designing an information system. But it is also a

difficult step. Requirements originate from stakeholders of a system, including the customer,

prospective users and business partners. These stakeholders all have demands about what the new

system should be able to do and often even about how it should do it. Eliciting the demands is a

difficult process, since stakeholders often don’t know what their real need is, or can’t express it

properly, they can have conflicting demands or priorities. Stakeholders can also have a difficult time

imagining a new way of doing things or understanding the potential of new technologies. (Lauesen

2002)

It is therefore the task of a requirements engineer to elicit the requirements for a new system,

organize and prioritize them and validate, together with the customer, that the requirements

accurately reflect the actual needs the customer has. Further, the requirements specification needs

to be feasible and understandable for the system designers, so that the system they’re going to build

34

will accurately reflect the requirements specification and thus will help the customer reach his

business goals.

As a guideline for the requirements engineering approach, Lauesen (2002) is used. This book, used in

many courses on requirements engineering, lists many methods of describing requirements and a

multitude of elicitation techniques. Second, the e3-Value methodology (Gordijn 2002) will also be

used to ensure all critical steps of the business model regarding payment are considered. The e3-

Value methodology is in nature a business modeling technique, which focuses on value exchanges

between the actors in the domain. These value exchanges give us a sound overview of transactions

that occur between the actors and thus a starting point when eliciting which tasks occur in the

domain, which may or may not be supported by the future system.

The e3 value approach focuses on the ‘use of a requirements engineering and conceptual modeling

approach to articulate, analyze and validate a value proposition more thoroughly.’ (Gordijn 2002)

Thus it is a suitable tool to validate to what extent there is a fit between the requirements which are

elicited and the value proposition, and the accompanying business model of PaySystems, which is

described in the previous section. Since any digital payment system will bring about at least some

changes compared to the current situation, it is unlikely that the fit between the requirements and

the business model of the current situation will be entirely preserved. If this is the case, this will

mean that implementation of the system according to the requirements specification will require

changes to the business model to restore the fit between the two. In this way, the e3 value

methodology will be used as an intermediating construct between requirements and business model

to assert the organizational consequences stemming from design choices, which are reflected in the

requirements specification.

4.2 e3 value model e3 value models describe the value exchanges between different actors in a business model. (Gordijn

2002) A transaction is modeled using four elements: the value port, value object, value interface and

value exchange. A value object is the offering, either tangible or intangible, that is being transferred

and it is modeled by a textual description of this object. A value port is used to either provide or

request a value-object by the actor. It is where the value exchange, the actual transfer of the value

object, connects to the actor. Value ports which belong to a single value exchange are grouped

together in a value interface, which models economic reciprocity. See Gordijn (2002) for more

information on e3 value models.

In Figure 4.1 the e3 value model of PaySystems is given. It gives an insight in the value transactions

that take place during the execution of the business model of PaySystems. This particular e3 value

model uses an actor-based view, meaning that focus is especially on the value exchanges between

the focal actor, PaySystems in this case, has with others. The exchanges between these other parties

are only globally modeled to ensure understanding of the model, but aren’t discussed in detail. The

path between value exchange shows how they are connected: Before a visitor can buy products from

vendors, they need to buy tokens at PaySystems. After the event is over, the vendors hand in their

tokens at PaySystems, the sales revenue is given to the event-organizer and the vendors receive their

revenue share.

35

Figure 4.1: e3 value model

This e3 value model gives some insight in the most important transactions that occur in the domain,

which a payment system could support. The primary transaction is the sale of products from vendor

to visitor. Of note is that PaySystems is not directly involved in this transaction and is therefore not a

necessity at an event. The role of PaySystems is that it improves the ease of this transaction by selling

tokens to the visitor, which are a far easier payment method at the vendor’s point-of-sale than

traditional payment methods, such as cash or debit cards.

The role PaySystems fulfills in the revenue sharing between event-organizers and vendors is also

important. It gives insight to both parties in the revenues and allows for strict control of the financial

flows. Should for example cash be accepted at vendors, it is very hard for event-organizers to

maintain control over the food and beverage revenues of the event.

While the manner in which tokens are sold and collected by the vendors is quite similar at all events,

the value exchange between event-organizer, PaySystems and the vendor considering with the

payout and revenue sharing can be very different depending on the deals made between vendors

and event-organizer. For example, at events when the catering is the responsibility of Food and

Beverage, vendors are paid-out directly from LOC7000 and the event-organizer only receives his

share of the revenue. This need to be reflected in the system: The task should be designed with

flexibility in mind.

It should be noted that only the most critical value exchanges are modeled in Figure 4.1. The other

value exchanges, such as the possibility for visitors to exchange tokens for cash at the end of the

event, aren’t modeled for two reasons: They are specific to the current system and may not be

needed in a future system and it keeps the model simple and readable. One could argue that the sale

of tokens also fits this category, since there are other ways in which PaySystems could enhance the

transaction between visitor and vendor, without exchanging value with the visitor. Without this

transaction however, the role PaySystems fulfills and the way the current system works becomes

unclear.

36

A final note is on the relation between transactions supported by the system and the business model

of PaySystems. Since PaySystems is not a part of the central transaction between visitor and vendor,

PaySystems must look at its role in the model when designing a new system. If PaySystems remains a

vital actor in enabling the transaction between visitor and vendor, revenue sharing or both, this e3

value model remains viable in the new situation. If this is not the case, the continuation of this model

is at risk, since the other stakeholders aren’t dependent on the value PaySystems offers. Of course, it

would be possible to change the model, in which for example the system can be rented, sold or

licensed to event-organizers. This will have serious implications for the entire business model of

PaySystems.

4.3 Payment system requirements In this section the requirements for the new payment system will be described. There will be three

sub-sections: first the intended business goals for digital payment will be described, which can be

used to validate the requirements against. Then the most important user tasks, those that are

relevant to each possible payment system, will be shortly described using the ‘tasks & support’ style

(Lauesen 2002) and finally, the most important quality requirements will be described.

The elicitation of these requirements was mainly done by observing the strengths and weaknesses of

the current system and conducting an analysis of the different stakeholders in the domain. The

outcomes where validated and further elicitation was conducted by regular meetings of a focus

group concerned with digital payment and interviews. The focus in this requirement analysis lies at

the critical characteristics of payment at public events uncovered in chapter 2: Robustness, efficiency

and revenue sharing feature prominently in the requirements. Further, the e3 value model of the

previous section is used to gain an additional overview of the tasks of the system. This was especially

helpful in gaining a full understanding of the financial settlement procedure.

4.3.1 Business Goals

Each business goal will get a short explanation along with a short indication for whom the goal is

important and how it relates to the other goals stated, since many are related to each other.

G1: Maximize food and beverage sales volume at customers’ events.

One of the most important parts of the value proposition of the current payment system is

that it improves the food and beverage sales at events. This is a major source of income for

the event-organizer and, of course, the vendors themselves. The bigger the improvement is,

the more attractive a system becomes to the event-organizer. A drop compared to the

current system will likely cause severe adoption issues, since a change would be against the

most important interest of these stakeholders.

G2: Minimize operational costs.

The costs of running the current payment system are high, since the system is quite labor-

intensive to run, especially since a lot of the token sale is done at manned vending-booths

and the vending machines also require a lot of time and effort to install and run. PaySystems

currently has a high price level, for a large part because these costs need to be covered.

Should these costs be reduced, PaySystems can improve their margins and may become

more attractive to event-organizers which currently are deterred by the price.

37

G3: Expand market to include smaller events and fixed venues.

Discotheques, clubs and other public venues as well as the smaller events have similar issues

as large-scale events. Many of them have their own payment system to use at the bars,

which commonly use some form of tokens, to increase sales and throughput at the bars. The

current payment system is not suitable for them, since it is focused on temporary

deployment at an event by PaySystems staff and not continuous operation at a venue which

has 100+ ‘events’ a year, such as a club. Should a new system be able to fit the needs of

these venues, for example by licensed operation by the venue themselves, the market

potential of PaySystems would increase dramatically. This is also tightly coupled to the

reduction in operational costs, since the financial constraints in these settings are tighter due

to the smaller number of visitors and thus sales.

G4: Achieve high visitors’ satisfaction with payment at events.

One of the most important interests of the event-organizers is the visitors’ satisfaction with

the event, including how it is organized. Negative experiences, such as waiting lines at the

bar or token-vending, may not only hamper sales, but it may also deter visitors from coming

back another time. The happiness of the visitors of the event is very important to the event-

organizer, since that is a primary reason visitors pay to go to the event. A payment system

which is found easy, fast and reliable is therefore important for the event-organizer. When

PaySystems’ system is disliked by the visitors, they may push the organizers to look at

alternatives.

4.3.2 User Tasks

The chosen style for describing the functional requirements of the digital payment system is ‘tasks &

support’. This method is developed by Lauesen and Mathiassen (1999) and has the advantage that

the customer can describe some problems and possible solutions he sees, without actually asking for

features he might not need. In traditional task descriptions, the customer of a system may feel that

he has little influence in what the system is going to look like, so he may be tempted to include

feature requirements , which specify how the system should help in conducting the task.

In Tasks & Support, the tasks and sub-tasks of the domain are described. In addition, there is room

for the customer to lists the potential problems the organization encounters with these tasks and

which variants may occur. Further, he can list some example solutions, so that he can give the

designer some insight what direction he’d looks for a solution. Of course, the designer can propose

his own solutions and discuss them with the customer. (Lauesen 2002)

Tasks & Support is used because it can be traced to the business goals of the customer. Another

reason is that it works quite good with tenders, since the suppliers can show the customer how they

solve their problems and how critical issues are handled. (Lauesen 2002) While this thesis is no

tender situation, there is an important similar issue. In this thesis, several quite different systems will

be compared to each other, and for each one, it needs to be assessed how the user tasks are

supported and the problems are solved. This is similar to a tender case, where different suppliers

send their proposals to the customer, who then has to choose the proposal which he thinks is the

best.

The two primary tasks for the digital payment system are presented in the two tables below. The

two tasks directly relate to the transactions in the e3 value model. The third transaction, sale of

38

tokens to visitors, is not presented since it is not part of every possible system. These and other user

tasks and functional requirements will emerge at a later stage of the development process, since

they depend on the chosen solution.

Task1: Vendor sells product to visitor

Purpose: Vendor sells a product to a visitor, sale is registered

Frequency: Very high

Sub-tasks: Example solutions:

1. Take order from visitor (Done manually, no system involvement)

2. Insert order into system Simple, robust keypad Problem: Needs to be fast Only 2-3 buttons required to enter amount Problem: Order changes after this step Adding additional amount should be easy

3. Fulfill order (Done manually, no system involvement)

4. Process payment Quick payment protocol: check balance, update visitor's balance and register sale for vendor

Problem: No connection with system Buffering of transactions at point-of-sale Problem: Customer out-of-funds Send customer to service desk; downside is angry

customer;

5. Payment confirmation Light signal clearly visible to vendor and visitor

Task2: Providing financial overview for organizers and vendors

Purpose: Controlling finances, determining revenue shares, making invoices

Frequency: Once, after the event

Sub-tasks: Example solutions:

1. Generate financial overview PaySystems income report; vendors' sales report

2. Determine payout of all parties Business rules reflecting agreements between vendors, event-organizers and PaySystems

Problem: Hard to foresee all possible agreements

3. Making invoices Automatic generation with information from sub-task 2; leave it the responsibility of vendors/organizers

4. Transfer money to event-organizers/vendor

Automated in the system; manual according to the produced invoices

4.3.3 Quality requirements

Quality requirements specify how well a system should perform its functions, which are specified in

the functional requirements above. There are many factors by which performance can be measured,

such as response time, usability, security and maintainability. But not all of them are equally

important in every system. A system which is only used by a handful of expert users has different

demands on usability than a system with which everyone comes in contact with, including people

with little experience with IT.

Therefore, first a ‘quality grid’ will be presented. (Lauesen 2002) A quality grid presents the most

common quality requirement categories and their importance in this particular case is assessed. This

quality grid is filled out together with PaySystems, since their wishes regarding quality factors need

39

to be fulfilled. A quality grid is important because improving upon one quality aspect will often have

an impact on the system’s performance in other aspects. Increased security, for example, often

entails a higher data load and thus can hamper the response time of a system. Second, resources are

often limited and therefore it is not realistic to achieve high performance in all quality factors. By

letting the customer decide which quality factors have priority, the resources can be divided

appropriately.

The list of quality factors is derived from McCall and Matsumoto (1980), which is still widely used as

the primary list for quality factors including in Lauesen (2002). It also formed the basis of the ISO/IEC

9126 standard for quality requirements. Additional quality factors, for example from these other

lists, can be added to the quality grid if deemed relevant by either requirements engineer or

customer.

Quality Factors for payment system Critical Important As usual Unimportant Ignore

Op

era

tio

n

Integrity/security

x Correctness

x

Reliability/availability x Usability

x

Efficiency x

Re

visi

on

Maintainability

x Testability

x

Flexibility

x

x

Tran

siti

on

Portability

x Interoperability

x

x

Reusability

x Table 4.1: Quality Grid

The quality grid for the digital payment system is given in Table 4.1. At first glance it is clear from the

table that the focus lies on the operational quality factors. This does not come as a surprise, since the

payment system that is being replaced is built specifically around most of these qualities and, as

explained in the business goals, maintaining a good performance on these factors is essential for user

adoption. This list of important criteria is quite similar to what was found by Ondrus and Pigneur

(2009) in a study comparing different payment technologies for the Swiss payment market.

The important quality factors will be shortly described next and for all one or more quality

requirements will be derived. An important note is that not all requirements contain targets. This is

on purpose, since the purpose of the requirements at this time is to compare different system

options on these and other criteria.

Integrity/security: Integrity and security define how good the system must be able to safeguard itself

from external threats, such as disasters, connection losses or power outages and of course malicious

attempts. (Lauesen 2002) Since a payment system directly influences the bottom-line of an event

and that there are strict regulations to protect the visitors this is an important concern.

40

Q1: It should not be possible for a visitor to authenticate himself at the point-of-sale as

someone else.

Q2: The system will comply with laws and regulations regarding electronic payment.

Q3: The system will be protected from attack by hackers and viruses.

Q4: The system will be safeguarded against tampering with transactions.

Q5: In the event of a failure, database integrity needs to be ensured.

Correctness: Correctness specifies how many errors there are in a system (Lauesen 2002). Since

money is at stake, correctness is quite important and transactions which are processed with errors in

the database are not acceptable. Further, the failure of an entire transaction, where at the point-of-

sale the vendor and visitor are notified of this, is bad, since the sale cannot be completed then and

efficiency is negatively affected.

Q6: To ensure database correctness, transactions will adhere to ACID-principles.

Q7: To prevent input errors, both visitor and vendor are able to see system input.

Q8: Authentication of visitor need to be done correctly at all times.

Reliability/Availability: The availability of the system to handle transactions at the point-of-sale is

critical to all stakeholders, since it is the only accepted payment method at the point-of-sale. In most

payment contexts, there are multiple payment methods available from which the customer can

choose. Since this is not the case here, availability in any circumstance needs to be ensured.

Q9: Payment at the vendor’s point-of-sale should be possible during the entire event.

Q10: In the event of a connection loss to the underlying system, sales at the point-of-sale

should remain possible.

Q11: The system should be robust, so it can handle bad conditions at especially the outdoor

events.

Usability: The usability is concerned with how easy the system is to learn and use for the users. Each

system needs to be usable, but in this case usability is an important concern, since speed at the

point-of-sale is important. The easier a system is to learn and use by both visitor and vendor, the

faster payments can be handled. Further, at an event the system is new to most visitors and they

may be hampered in their ability to use the system later on when they’ve had a few alcoholic drinks.

Q12: A minimum amount of button presses should be required for order input.

Q13: Visitor can confirm payment with one action.

Q14: Authentication of the visitor is as lightweight as possible with regard to security

concerns.

Q15: Visitors and vendors need to have a clear sign when a transaction is completed.

41

Efficiency: Transaction speed at the point-of-sale is a critical quality factor, since that is a primary

part of the value offered to the event-organizers and vendors. Further, since at a lot of events

connectivity needs to be set up specifically for the event, data transmission between the point-of-

sale and underlying system is expensive. This is compounded by scalability. At very big events, there

are upwards of 500 points-of-sale that need to be functional and there may be multiple events at the

same time

Q16: The underlying system needs to handle many terminals (minimum 1000 terminals)

Q17: A transaction should take less than 4 seconds. This is based on the time it takes to

retrieve the products of an order for the customer.

Q18: Bandwidth used for a transaction should be limited. However, correctness and security

needs to be considered.

Flexibility/Interoperability: These quality factors are both listed at important and unimportant. This

is because it highly depends on the system chosen. In the case where the underlying system is

(partly) existing infrastructure from financial institutions, for example the debit card infrastructure, it

is important that the system is interoperable and flexible, so that it works well together and is easy

to adapt to future changes in this infrastructure. The more independent the chosen system operates,

the lower the importance of flexibility and interoperability becomes.

4.4 Discussion on requirements elicitation An important part of requirement engineering is validating the requirements. This means checking

that the requirements accurately meet the expectations that the customer has of the system. Since

currently there are still a lot of uncertainties regarding the user tasks and features of the system, the

requirements can’t be validated to much effect. In many validating techniques both functional and

non-functional requirements need to be present. An example of this is goal-domain tracing, (Lauesen

2002) in which business goals are traced to both user tasks and quality requirements and vice-versa.

In Table 4.2 above, a goal-domain trace is conducted for the partial requirements specification

presented above. All quality requirements except Q2, Q3 and Q6 relate to at least one business goal.

The former two regard constraints about security and legal issues, and these constraints are not

goals themselves. The latter one lists a solution technique to help achieve correctness. It is therefore

not directly traceable to a goal. Correctness itself can be related to a business goal, for instance the

T1 T2 Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8

G1: Maximize Sales x x x

G2: Minimize operational costs x x

x

G3: Expand to other venues x x

x

G4: High visitor satisfaction x x x X

Q9 Q10 Q11 Q12 Q13 Q14 Q15 Q16 Q17 Q18 G1: Maximize Sales x x x x x x x x G2: Minimize operational costs

x

G3: Expand to other venues

x

x

G4: High visitor satisfaction x x x x x x Table 4.2: Goal-domain trace

42

customer experience or operational cost reduction, but how correctness is reached is of little interest

to the business partners. While a solid trace is possible for the quality requirements, the user tasks

are currently too high level and generic in nature to conduct an effective trace. They will need to be

specified in greater detail to accurately assess if the business goals are truly supported.

Another way in which validation on the task requirements is attempted in this specification is by

means of the e3 value model presented in section 4.2. The e3 value model describes the value

exchanges between the actors in the business model. The two user tasks in the requirements

specification can be directly linked to the value exchanges in the e3 value model. At a later stage,

when more details on the payment process become clear, they can be included in the e3 value model

and from there, the user tasks of a system can be seen. A pre-paid system in which leftover tokens

can be reimbursed, includes two new value exchanges: sale of pre-paid credit and the

reimbursement of this credit. These exchanges will need to be supported by the system and thus also

depict at least two new user tasks.

Currently, the e3 value model and the user tasks are quite simple, but the link between the two is

easily seen. This means that in more complex environments, where there are many value exchanges

between many actors, it may be very useful to check that all value exchanges are considered when

eliciting the system requirements. However, it is never a comprehensive technique which can be

used to elicit all user tasks, since it is not possible to describe user tasks in e3 value which do not

occur between more than one actor and tasks in which there is no value object.

The link between the characteristics of the public events retail payments uncovered in chapter 2 is

very much reflected in the requirements elicited. The two critical quality factors are two of these

characteristics: Efficiency and reliability, while revenue sharing is reflected in the second task of the

system. This is because these characteristics form important pillars of the value proposition that is

offered to the customers of PaySystems and thus will need to be present in a new system. Therefore,

they play an important role in the requirements for such a system.

43

5 Constructing a shortlist Now that the business model of PaySystems is clear and the requirements for a payment system are

specified it is time to take a look at what viable alternatives are available. A shortlist of system

options will be presented in this chapter. These options will be compared to one another in the

subsequent section on how they meet the requirements specification, what the impact on the

business model will be, to what extent the business goals can be met and a financial assessment.

Based on this comparison and the future expectations of the payment market, an advice will be

presented to PaySystems.

To come up with a shortlist of alternatives, the payment time variable presented in section 2.1.3 is

used, since the order of the steps in the process model depends on this choice. Therefore, a high-

level business process model will be presented for each option to more thoroughly show the

characteristics of the option. The first three alternatives follow directly from these payment time

options, while a fourth option will be presented that is a combination of a prepaid and postpaid

system. Continuing the current system will be the fifth and final possibility presented. These

alternatives will be shortly described along with their business process and their advantages and

disadvantages. The most important challenges that PaySystems faces when the option is chosen will

also shortly be addressed.

This short analysis of the five alternatives clearly shows why this is such a challenging problem: there

is no single option superior to the others and a compromise will have to be made. Postpaid systems

carry a lot of risk and costs regarding the collection of the money from visitors. Prepaid payment

methods carry a lot of the same disadvantages that the current payment system has and it’s doubtful

the business goals can be reached by keeping this as the basis. Real-time payments have the

disadvantage that there is a heavy reliance on financial institutions. These five options cover the

range of possibilities that PaySystems has regarding electronic payment systems and therefore will

form the basis on which the comparison of alternatives is made in the rest of this thesis.

5.1 Real-time payment system The first option is to implement a real-time payment system at the point-of-sale. This would mean

using one or more payment methods offered by financial institutions, which are already known and

available to the visitors of the events, to directly make a transaction from the visitor’s bank account

when food or drinks are purchased. The primary real-time systems under consideration are debit and

credit cards, since they are the only ones with sufficient customer adoption in the Netherlands, save

for cash payment. (Brits and Winder 2005) (DNB 2010)

The process model of real time payment can be seen below in Figure 5.1. It is from the visitor’s point

of view the most simple form of payment. Since existing payment infrastructure is used, they already

have their payment tool(s) available and can use them at the point-of-sale. However, the ‘Pay’ step in

the process cannot be filled in by PaySystems themselves, but is dictated by the payment

infrastructure from the financial institution that the visitor uses. The implementation of this process

step may or may not fit the specific quality criteria regarding payment which are critical for

PaySystems and there is limited leeway to improve the performance on these criteria.

44

Figure 5.1: Business process real-time payment

The first advantage of a real-time system is that the payment infrastructure from the financial

institutions is used and that the investment for PaySystems will be relatively low, since it doesn’t

have to build its own infrastructure. Further, the system will be flexible for the future: Once new

payment instruments are adopted, PaySystems can switch to these methods quite easily. The

downside of this is that the operational costs associated with using this infrastructure may be higher

than with other systems, since there are more transactions and that the system is highly dependent

on the reliability of the payment infrastructure offered by the financial institution. Another

advantage is that there is a minimal number of steps in the entire payment process for the visitor:

There is no need to register visitors, sell credit to them or manage their debts.

The main challenge for PaySystems will be to adapt these systems in such a manner that the quality

requirements for payment at the point-of-sale are met. The payment infrastructure offered by the

financial institutions has a certain performance on most quality factors. While these performance is

sufficient for many quality factors, such as correctness and security, there are also factors for which

the quality requirements are not met by the offered real-time payment system. This is most common

with the critical quality factors, since performance demands are highest here. There is little leeway to

improve performance of real-time systems. Therefore, it will be up to PaySystems assess whether

standard performance is acceptable or if there is some way to improve performance on these

aspects to acceptable levels.

5.2 Prepaid mobile wallet system The second payment system option is thus to give each visitor a digital wallet, in which they can load

credit which in turn can be used to purchase food and drinks at the point-of-sale. This system shows

many similarities with the current system with physical tokens, in the sense that the process from the

visitor’s side has the same basic steps of buying credit, purchasing food or drinks and possible

reimbursement of excess credit at the end of the event.

Prepaid systems can be implemented in two ways. There are prepaid systems in which credit is kept

by the payer, for example the payment tokens used in the current payment system of PaySystems, or

prepaid cards with a credit amount, such as the payment cards in the Alvalade stadium (O'Callaghan

2007) or the OV-Chipkaart. (Teepe 2008) The other option is to keep the credit of a payer in a central

system. The payer then needs to identify himself before the amount due can be deducted from his

balance or credit can be added. This identification can be done in a multitude of ways, for example

with a RFID-chip or by a login/password combination. A good example of this is PayPal: Credit is

45

stored on the account kept by PayPal and can be accessed from any computer, once the identity of

the user is verified with a login. (PayPal 2011)

Figure 5.2: Business process prepaid payment

The business process model for prepaid payment can be seen in Figure 5.2 above. This business

process model contains two phases: The payment at the point-of-sale using the credit account of the

customer and the (re)loading of the credit balance by the customer. One important difference is that

PaySystems is actively involved, while in the business process model of the real-time system this is

not the case.

An advantage of such a system is that the transaction at the point-of-sale does not require a third

party, since the credit is either available on the payer or identification and deduction is done at the

central system of PaySystems. Further, the authentication and deduction combo can be tailored to

the quality requirements that are specifically important in this situation, such as availability and

efficiency. The most glaring weakness is that the payer needs to buy credit, so it adds an additional

step to his process. Finally, customers can be out-of-credit when they want to make a purchase.

These occasions hamper sales, transaction speed and are negative experiences for the customer,

since he needs to reload before he can make a purchase.

The main challenge is designing a system which successfully fulfills all the quality requirements. This

includes the security and integrity concerns, which are covered by the payment provider of a real-

time payment system. This could make development and operation of the system quite expensive. As

a final note, a prepaid system relies on a payment tool by which the visitor identifies himself at the

point-of-sale so the amount can be deducted from his account on a central system or which contains

the credit balance itself. This payment tool will need to be made available and usable for all visitors

of the event, whether it is an app for a phone, a RFID-tag or something else.

5.3 Postpaid settlement system The third system option is a postpaid settlement system, where all purchases of a visitor are

registered on a debit account of the visitor and there is a single payment conducted after the event.

The most common method used for such payments is a direct debit. In direct debits, the customer

46

signs a authorization before consuming the product or service. At a later stage the amount due is

deducted from the customer’s bank account. These transactions are offered by the payee to his bank

in batch, which then processes the transactions. The payee is notified whether the transaction is

successful.

The business process model for a postpaid payment in given below in Figure 5.3. In this process there

are three stages: Set up account, Payment at point-of-sale and collecting payment. The payment at

the point-of-sale is very similar to a prepaid payment process model, with the difference that instead

of deducting each time a purchase is made, the purchase is stored in the system on a debit account.

The advantage of this is that there can be no out-of-credit situation. After the event, the purchases

are aggregated into one payment from the customer’s bank account. To successfully store and

process this payment, the customer first needs to sign-up, so he can be authenticated at the point-

of-sale and the payment can be processed correctly after the event.

Figure 5.3: Business process postpaid payment

An advantage is that the process at the point-of-sale is the simplest one of the presented options. All

that needs to be done is add the purchase to the proper debit account, so there is no third party

required at the point-of-sale. An additional advantage is that there is only one bank transaction per

visitor per event, minimizing transaction costs. The main drawback of the system is the risk that the

payment from the visitor’s bank account fails. Information from ‘De Nederlandse Bank’ lists that

about 2% of payment authorizations aren’t processed properly. 90% of those because the account

balance of the debtor is too low and thus the transaction cannot be processed, and 10% because the

debtor pulls the transaction back after it is processed. (DNB 2007)

The main challenge when designing such a system is ensuring that the customer actually pays their

debts. How to handle failed or rolled-back payment authorizations is a key question that needs

answering before such a system can become reality. The other challenges are similar to the prepaid

system: Designing a system from scratch which meets all quality requirements, regarding

performance, availability and security and providing the visitors with a tool to identify themselves at

the point-of-sale.

5.4 Automatic reload system A variant of the postpaid system, with the goal to reduce the debtor risk, is an automatic reload

system. It works similar to a postpaid system, only instead of a debit account the visitor gets a credit

47

account which is automatically reloaded when the credit balance falls beneath a pre-set threshold.

When that happens, a direct debit request is send to the visitor’s bank and the credit is reloaded.

Should a payment get rejected, PaySystems can disable the credit account of the visitor and thus

debt risk is minimized. The typical business process of an automatic reload system is given in Figure

5.4. From the visitors’ perspective, it is identical to the postpaid system, with the difference that

there will be multiple small deductions from his bank account rather than one large one.

Automatic reload systems are currently utilized in several sectors in the Netherlands, for example by

Trans Link Systems, which exploits the ‘OV-Chipkaart’, (Teepe 2008; OV-chipkaart 2011) a payment

system for all public transport, and by Simyo (Simyo 2011), a prepaid mobile phone provider, which

has an automatic reload function for prepaid minutes. In both systems automatic reload is used in

combination with a prepaid system, since they’re both credit-based. Users of the prepaid system

who’d like to, can sign a direct debit authorization and activate the automatic reload, while other

users buy credit manually.

Figure 5.4: Business process automatic reload system

The advantages that an automatic reload system has are quite similar to those of a postpaid system:

it’s very lightweight at the point-of-sale and self-reliant. There are however more transactions from

the visitors’ bank account per event and leftover balance will need to be reimbursed, also adding to

the number of transactions. The important disadvantage of debtor management, which is in place at

a postpaid system, is in large part mitigated by working with a credit account instead of a debit

account. There still is some risk, for example when an order at the point-of-sale brings the balance

beneath zero or when the connection with the bank is lost and the payment request is buffered, but

this is a lot smaller than in a postpaid system.

An additional challenge compared to a postpaid system is handling the connection between the

system of PaySystems which manages the credit accounts and the bank(s) which handle the direct

debit requests from the visitors’ bank accounts.

5.5 Keep the current system At this moment there is no external pressure or any direct reasons to move from the current system.

Periodic surveys among visitors show that they are in general satisfied with the system. Further, it is

specifically tailored to the needs of the other stakeholders: vendors and event-organizers, and

48

PaySystems has a strong market position. Keeping the current system in place is therefore a realistic

option. The business process of the current system is given in figure 5.5.

Each of the options above present at least some disadvantages and they might be larger than the

expected gain from the realization of the goals or the investment or risks might be too large. The

alternatives presented above will thus also be compared to the current system. If the option to keep

the current system is chosen, the achievement of the business goals can be explored through other

avenues, for example by adapting the token vending machines to operate in fixed venues.

Figure 5.5: Business process current system

5.6 Shortlist When looking at these five options from a higher level, one can see three main directions: utilizing a

real-time payment system built and maintained by a financial institution, building a proprietary

system or keeping with the current system. When building a proprietary system, only then

PaySystems is offered a real choice on payment time, since the current system is prepaid and a real-

time system utilizes real-time payment by default. Proprietary systems on the other hand can never

utilize real-time payment, since PaySystems is no bank and thus cannot transfer money from one

party (the visitor) to the other (the vendor) entirely independently. Settlement will thus have to be

conducted either in advance, using (electronic) quasi-goods, or after the sale, with the help of a real-

time payment system of banks.

In this section, three options for proprietary systems are presented: A prepaid wallet similar to the

current system only with electronic credit, a postpaid system in which sales are recorded and

payment is settled in one payment using a real-time payment after the event and an auto-reload

option, which attempts to exploit the advantages of a postpaid system, namely the easy process at

the point-of-sale, and limit the debtor risk that accompanies a postpaid system.

To come up with the final shortlist, a rudimentary risk-value analysis is presented in Figure 5.6 to

assess which systems are most promising to explore further. The real-time option offers most value,

since it is easily scalable and thus allows for market expansion more easily than the other options.

The current system presents very little risk, since it already runs smoothly. From a value perspective

the three proprietary system are pretty comparable, since they function quite similar based on the

process models.

49

In the specific situation of PaySystems, where there are short and unsustained relationships with the

visitors of events, debtor risk in postpaid systems is more profound than in continuing services,

where postpaid payments are mostly used, due to the fact that there is no threat to discontinue

service. This means that PaySystems has very little leverage when dealing with defaulters and this

causes extra risk. Further, since many visitors do not return, it may be impossible to track them down

if invalid information is entered by the visitor, either on purpose or by accident.

Figure 5.6: Risk-value matrix

In light of this, postpaid payment risk is considered too high to seriously consider this a viable

alternative to both the prepaid option, which carries many similarities regarding costs, potential on

the business goals and operation, and the current system, which still functions so good that the

addition of the payment risk will not make up for the performance improvement.

The auto-reload option decreases risk by spreading the payment over installments during the event

and blocking the visitor’s payment tool when payments aren’t accepted. The decrease in risk has a

high correlation with the response time of the payments: If PaySystems is informed in real-time

about the success or failure of the payment, they can immediately respond in the case of a failure.

But the longer this response time is, the more risk there is for PaySystems, since in the meantime the

visitor can make purchase and built his debt. This is modeled in Figure 5.6 by the sliding scale of the

auto-reload system. At the moment, the response time for direct debits is quite high: A couple of

days, which means that for almost all events, the responses on the payments do not arrive before

the end of the event. This means there is little risk reduction, and thus currently the risk is on the

high end of the scale. Until this response time goes down significantly this is thus not a viable option

as well.

In the remainder of this thesis there will thus be three options considered and compared to one

another: A real-time payment system, an electronic prepaid wallet and keeping the current system.

Should the prepaid system be chosen in the end, an auto-reload option could in time be added to the

system should the response time on direct debits go down, since they are compatible with each

other. Instead of buying credit, visitors can sign a direct debit authorization and credit is loaded

automatically.

50

6 Analyzing the shortlist options Now that the shortlist of three possible options is presented, it is time to take the range of criteria

uncovered in the previous chapters and make an in-depth comparison of these options. The two new

system options are outlined in more detail in the first section of this chapter by means of a

component diagram and by describing the expected impact of the new system on PaySystems’

business model. The component diagram describes how the system works from a more technical

point-of-view, while the business model impact deals with the organizational implications of a new

system. The system outline for the current system is omitted, since this is already covered in great

detail in chapter 3, where the current business model of PaySystems is presented.

The middle three sections will compare the shortlist alternatives on three different viewpoints. In

section 2 the expected performance of the three alternatives on the business goals, presented in

section 4.3.1, will be assessed. The next section will look at how the options are expected to perform

on the quality requirements from section 4.3.3 and finally in section 4, the implementation costs,

risks and barriers will be discussed. The current system will be omitted from the latter section, since

there is no implementation to consider when choosing this option.

The comparison on the three viewpoints will form the basis of the advice which will be presented in

the last section of this chapter. This section will cover some market considerations which play an

important role in the advice, the advice itself and finally some initial directions for further research

for PaySystems will be presented.

6.1 Outline of the systems In this section the two new system options, a real-time system and a prepaid wallet, will be described

in more detail. Component diagrams are used to this end. In these diagrams, the system is split-up

into the loose components which comprise the system and the information exchange between them

is modeled. This gives an insight in the vital parts of the system and which communication links are

critical. This will allow for a detailed view of how each system works and what challenges need to be

overcome before the system can be deployed at events from a technical point-of-view. Further, to

assess the organizational implications of the alternative, the impact on the business model is

described. The current business model of PaySystems is presented in detail in chapter 3. That model

will be used as a baseline for the comparison of alternatives from the shortlist. The impact that each

system has on the business model of PaySystems will be assessed by looking from two directions:

What are the elements where changes are required when changing to the new system? And does the

change to the new system open up any new possibilities? The former question is meant to find out

what challenges are associated with the choice for the alternative in question from an organizational

point-of-view. The latter is to find out if the change to the new payment system opens up additional

benefits, so that these can be considered by PaySystems when determining which direction to

pursue.

6.1.1 Real-time system

The most common real-time system implementation that is currently used in the Netherlands is debit

card payment. Recent study by the Dutch Central Bank show that about 96,5% of the Dutch

population uses debit cards in retail situations. (DNB 2010) On the question ‘which payment

option(s) do you use to pay at retail stores’ the response of 96,5% on debit cards was even slightly

higher than cash and no other method manages 40%. This means that currently debit cards are the

51

only viable option that PaySystems has for the real-time system to use, so that is what the rest of this

section will focus on, both with the component diagram and the business model impact.

Component diagram A real-time system is the least difficult for PaySystems to implement. The component diagram in

Figure 6.1 shows why: The only two components that PaySystems needs to deploy are the payment

terminal, which is used at the point-of-sale to establish the connection with the underlying payment

infrastructure offered by banks, and the order input terminal, which is used by the vendor to insert

the order into the system and thus transfer the amount due to the payment terminal, which can

further handle payment. The debit card is the payment tool used by the visitor to identify himself to

the payment system and to authorize the payment and is offered by the bank of the visitor. The

actual money transfer from the visitors’ bank account to PaySystems’ bank account happens in the

payment infrastructure of the banks and can be considered a black-box by PaySystems.

Figure 6.1: Component Diagram Real-time system

The two elements that PaySystems need to deploy will now be shortly discussed. Such an input

terminal can be a simple keypad on which a vendor can insert a payment amount or it can be an

extensive point-of-sale terminal in which the products are entered and the total price is calculated

automatically. The advantage of the latter is that it can be coupled to other systems, such as stock

management and CRM-systems and thus offers more functionality and flexibility to the vendor. The

advantage of the former system is that it is much more lightweight and flexible: Only the amount due

needs to be entered. The way information is entered into the system can also vary. They can be

entered manually, for example by keypad or touch screen, or this can be automated, most commonly

by scanning product barcodes in retail stores, but increasingly by RFID-tags and -readers.

The visitor needs to put his debit card into the reader of the payment terminal. The payment

terminal asks the PIN-code which corresponds with the debit card as way to authenticate that the

visitor is the true owner of the debit card and eligible to authorize payments from the corresponding

bank account. The payment is then offered via an internet connection to the debit card payment

infrastructure and in seconds the payment is either processed or rejected. Rejection is most

commonly due to a lack of account balance. The confirmation or rejection message is then relayed

back to the payment terminal.

52

In the Netherlands, the infrastructure is offered by banks via a couple joint-ventures: Equens and

Currence. Equens (Equens 2011) is an European payment infrastructure service provider which is

tasked with processing debit card and other digital payments. Currence (Currence 2011) is the Dutch

licenser of the debit card system, which is owned by the eight largest Dutch banks. PaySystems has

already adopted this system and has a license to use the system and a connection to the Equens-

infrastructure. Visitors can already use their debit card to buy tokens in the current system. For a

point-of-sale debit card payment system, the scale of debit card payment needs to be increased:

There’ll be many more transactions and terminals, but there is already experience with debit card

payments and payment processing.

An additional element to consider is that many available debit card terminals are also able to process

credit card and ChipKnip-transactions, since these are also processed by Equens and licensed by

Currence. Therefore it is quite easy to expand the range of payment options offered to include these,

if desired.

Impact on the business model A real-time system significantly changes some elements of the business model of PaySystems, since

instead of being actively involved in the payments at the point-of-sale with their own system, their

value proposition becomes more about enabling the payment instruments offered by the banks, so

that they can optimally be deployed at the point-of-sale. There are however other companies that do

this, such as banks themselves or other payment service providers, for example CHESS, (Chess 2011)

but they are not specialized for events and thus are not expected to deliver proper performance.

Many aspects regarding the resources, activities and partners will change. Most current activities are

geared towards the sale of tokens to the visitors, a step that is omitted in the business process of a

real-time system. Instead, PaySystems will help at the point-of-sale directly, by using their new

resources: the point-of-sale terminals, and servicing the system behind it during the event. The

connection to the bank becomes more important, since this is required to complete the transaction.

One important advantage is that visitors are used to debit card payments and that usability and user

adoption are thus of little concern. Visitors use the system in many other occasions and know how it

works and they have trust in the system, which is important for their attitude and towards it.

As for new opportunities with a real-time system, it offers good prospects for broadening the market

for PaySystems. Since the operation can be done much easier and cheaper due to the removal of the

sale of tokens as a process step, it is feasible to think that a rental-construction is possible, in which

operation is done by the customer themselves and they pay a licensing fee to PaySystems for use of

the terminals and underlying system, which makes the system more scalable from PaySystems’

point-of-view.

6.1.2 Prepaid wallet

A prepaid wallet represents a credit account on which a visitor loads credit by a real-time

transaction. This credit account is debited at the moment of purchase at a vendor. There are two

sub-options in such a system: One in which the account is kept on a payment tool in possession of

the visitor and another where the payment tool is only used to identify the visitor and authenticate

the payment and where the account is kept on a central system, similar to the way a debit card

53

works. These have a significantly different component diagram, so both are given here, but the

organizational implications are pretty similar and thus they’re considered in one section here.

Component diagram In this section there are two component diagrams presented for the prepaid payment system. The

same legend as in the previous section can be used for both component diagrams. The first diagram,

given in Figure 6.2, depicts the system where the balance is kept on a central system. The most eye-

catching difference with the debit card system from the previous section is that PaySystems needs to

deploy far more components for a prepaid system. Aside from the payment and input terminals, it’s

also PaySystems’ responsibility to offer a payment tool which can be used, a system which keeps

track of the visitors’ account balance and a reload terminal, where the visitor can buy credit.

The sale of credit is similar to the current sale of tokens. Visitors can use various real-time payment

tools to buy credit, for example at vending machines or as part of a phone app, which would function

as reload terminal in this diagram. The reloading method that is depicted here is again a debit card

transaction. After money is transferred to the bank account of PaySystems, the appropriate amount

of credit is added to the visitor’s account. The proper credit account is identified by the presentation

of payment tool 2, the payment tool that is issues to the visitor by PaySystems, which is also used at

the point-of-sale.

The order input terminal has a similar role and responsibility as in a real-time system. It should allow

the vendor to easily insert the order or amount due into the system and offers the amount due to

the payment terminal so it can handle payment. The payment terminal is here not coupled to any

third party infrastructure, but to PaySystems’ infrastructure, where the amount due is deducted from

the visitor’s credit account. To identify the visitor, the visitor needs to present its payment tool to the

payment terminal. The main difference is that the payment at the point-of-sale is entirely handled by

PaySystems and that no third party infrastructure is involved.

Figure 6.2: Component Diagram Prepaid system - Balance on central system

54

In the next diagram, given in Figure 6.3, the other variant of a prepaid system is given, where the

account balance is kept on the payment tool itself. The main difference is that there is no central

system involved in the payment, but instead credit is loaded to and deducted from the payment tool

itself. This means that the payment tool becomes more complicated, since data needs to be read and

written to the tool during each transaction. In the component diagram this difference is depicted by

the fact that in figure 6.3 there are in- and outbound connections to the payment tool, while in figure

6.2 there are only outbound arrows. The advantage of keeping balance on the payment tool is that

there is no connection at the point-of-sale required to process payments. In reality there probably is

some back-office system, which is used to monitor sales at the various payment terminals and also to

prevent fraud. If there are transactions made with a payment tool which shouldn’t contain any

credit, this is an indication that there’s something going on.

Figure 6.3: Component Diagram Prepaid system - Balance on payment tool

In both systems there are possibilities to integrate the reload terminal and payment tool 2. If the

prepaid system uses a mobile phone app as payment tool, it is conceivable to add a reloading option

to such an app which would enable visitors to buy credit from their phone. Of course, that would

require an internet connection so that a bank payment can be requested and, in the first option,

credit to be loaded onto the account on PaySystems’ system.

Impact on business model The business model of the prepaid mobile wallet is more similar to the current situation, mainly

because the business process is more similar and the payment time stays the same. The value

proposition is similar to the current system: a full-service solution with a prepaid system to increase

volume and speed at the point-of-sale.

The activities will remain similar, although the work at the point-of-sale will increase. Currently, there

are only buckets to distribute in which tokens are collected, but in this system, there’ll be point-of-

sale terminals, which need to be installed and serviced. When visitors are able to reload their balance

without some form of hardware from PaySystems, such as reloading stations, the infrastructural

costs will go down. This is problematic at the moment however, since public events lack in wireless

connectivity, so users will not be able to make connection with just their phones. Once solutions

55

become available to solve this, this will seriously reduce workload on PaySystems, since they then

only need to provide software for the phones and payment terminals.

There is some legislation associated with electronic money, most notably e-money directive by the

European Union. (EU 2000) PaySystems would either need to comply with this directive or get an

exemption, so this adds another complication to this option. If user information is registered, the

system will also need to comply with privacy and security legislation.

Compared to the current system, the infrastructural costs will go up, since there need to be point-of-

sale terminals in addition to reload stations. The connectivity between the central system and these

terminals is essential as well and thus require significant time and money. Operation of the system

will be cheaper, since there is much less personnel required in a digital system and there are no

tokens. An added opportunity is to add other functions to the app, such as mobile marketing, where

the vendors can advertise inside the app, and other extra’s, such as event-information.

6.2 Achievement of business goals This section will assess to what extent it is possible for each shortlist alternative to reach the business

goals, which are specified and explained in section 4.3. Each business goal will be briefly discussed

and the expected performance of all three alternatives will be described.

6.2.1 Goal 1: Maximize food and beverage sales volume at customers’ events

The maximization of food and beverage sales is viewed as the most important goal for PaySystems.

Not only in this situation, but in every decision that PaySystems makes, since this is an integral part

of the value proposition offered to their customers: event-organizers. Another important group of

stakeholders, the vendors, are also heavily invested since all of their revenue comes from food and

beverage sales. The current system does a good job of increasing the sales volume as it is, so this will

be an important aspect to consider. There are many aspects of the payment system which influences

sales and they’ll be discussed shortly to get a proper overview of the expected performance of the

alternatives.

First of all, the current system profits from redemption of tokens, which is the difference between

tokens sold and tokens collected by the vendors or reimbursed after the event. These tokens have

been paid for, but no sale has occurred, thus this is an extra source of revenue. Redemption is

restricted to prepaid systems, because in real-time systems there cannot be payments without sales.

In the prepaid wallet redemption is expected to be lower than in the current system, since electronic

credit cannot get lost like tokens can and the amount of redemption also depends on how easy it is

to reimburse credit. Visitors may be more inclined to reimburse if the only effort is the push of a

button, instead of standing in line, especially when it’s just a few tokens.

There is an up selling effect in the current system, because there is a significant effort associated in

re-buying tokens for the visitor. That is motivation to minimize the number of times he needs to go

back to a vending machine or –booth and buy additional tokens. This can be achieved by buying

enough tokens for the entire event, or at least a good part, the first time and this may be even more

than he would’ve spent if the extra process step of buying tokens wasn’t there. This effect is once

again limited to prepaid systems. In general, customers are inclined to consume more and faster if

they’ve bought in bulk. (Ailawadi and Neslin 1998)

56

The third factor is the ease of paying from the visitors’ point-of-view. If it’s easier for him to pay at

the point-of-sale, it’s more likely he’ll make more purchases. One can imagine that when a visitor is

out of credit almost at the end of the event, whether it are tokens or electronic currency, he may not

want to re-buy tokens and thus either not make another purchase or purchase a cheaper product, to

prevent re-buying. The prepaid system and current system therefore perform less on this aspect.

Some empirical evidence is already available for this, summarized in a study by the Smart Card

Alliance (Alliance 2004).

Then there are two psychological factors which play a role in the sales volume: the visitors’ ability to

keep track of their spending and set a budget, and the sense of money that the visitor feels when

purchasing. When customers are unable to keep track of what they’ve spend so far, it is much harder

for them to set a budget or to keep within this budget. With prepaid systems, either tokens or

electronic, this is easier to do than with the real-time variant. The sense of money also depends on

the payment time. In prepaid scenarios, the costs of credit is more seen as sunk costs by the

customer (Gourville and Soman 1998) and therefore he may be more inclined to actually spend the

credit.

As can be seen in Table 6.1, all options have multiple positive and negative factors affecting them,

thus there is not a clear better choice when isolating this business goal. More research can be done

on the spending patterns and the height of these effects in this market, but that would be an entire

extensive study in itself. For now, all systems are considered about equal, with a slight edge to the

current system, due to the quite large redemption effect. (Roberts and Jones 2001)

Redemption Up selling Ease of use Budgeting Sense of money

Real-time - - + + -

Prepaid o o - - +

Current + + - - + Table 6.1: Performance on maximizing sales

6.2.2 Goal 2: Minimize operational costs

As explained in chapter 3 on business models, the operational costs of PaySystems currently consists

of three main parts: personnel costs, transaction costs and token costs. These are costs incurred in

every payment setting, whether it is in a stadium or at an outdoor event. Especially at outdoor events

there are high costs associated with getting the vending machines and –booths to the location and

connecting the debit card terminals and vending machines, but these highly depend on

circumstances. The minimization of all these costs is another goal of PaySystems and the expected

performance of each alternative will be discussed here. All three of these cost centers will be

touched upon.

Transaction costs One of the advantages of a prepaid system, current or electronic wallet, is that the number of

transactions at the financial institutions is limited. Real-time systems require one transaction for

every purchase made, while the other two systems only require one transaction per credit load. The

transaction costs for real-time systems are thus quite a bit higher than for the other two alternatives.

57

Personnel costs This is the primary cost driver in the current system, since the sale of tokens and the handling

afterwards is very labor-intensive. Each of the electronic systems will present an upgrade in this

aspect, since tokens are no longer an issue. There are more terminals to service though, since each

point-of-sale has a terminal with electronic system, so there are more technical people required.

Each electronic system will also require some form of service desk, where visitors can turn to if their

payment instrument isn’t functioning properly or some other failure occurs.

Token costs Another aspect is the costs of the tokens or, more generic, the payment tool. There will be no costs

for this in the real-time system, since the payment tool is already owned by the customer. While in

the prepaid system, there are no tokens to order, the visitors do need to be provided with a payment

tool, whether it is a mobile phone app, contactless card or something else.

As can be seen in Table 6.2, there isn’t a single solution which it better in every aspect. Real-time

systems perform best in token and personnel costs, but they are by far the most expensive when

looking at transaction costs. The prepaid system has one advantage over the current system:

Personnel costs are lower due to the decrease in sales staff and token handling. However, any

electronic system will have increased costs in connecting all terminals to the payment infrastructure

and this negates some of the gains in this area.

Transaction Personnel Token

Real-time -- ++ ++

Prepaid o ++ o

Current o o o Table 6.2: Performance on cost reduction

6.2.3 Goal 3: Expand market to include smaller events and fixed venues

A requirement to the expansion to smaller events and fixed venues, such as clubs and discotheques,

would be that the operation of a payment system can be done independently by the customer of

PaySystems. The revenues of these events are substantially lower and therefore there is less budget

available for the operation of a payment system than at large events. Including the operational costs

in the price of food and drinks is a risky step, since there is typically more competition in these

situations between venue owners and the customers are more price-sensitive. Operation of the

system should therefore be as easy as possible for the customer of PaySystems, while the system

also needs to be very friendly to the visitors of the event or venue, since there are many substitute

events and venues available to them. A second factor is the visitor attitude towards a system. Since

there is a lot of competition in these markets, an unattractive payment system could deter visitors.

A real-time system performs exceptionally well in this regard, since there is little to no effort before

or after the event required for the operation of the system. The terminals will need to be connected

and installed, but in fixed venues this is a one-time process and the amount of terminals, and thus

the cost of this, are generally in-line with the revenue of the event. Therefore these costs should be

manageable. During the event, there is a minimum of process steps and the money is directly

credited to the bank account of the event/venue owner. The system should be able to work on a

licensing basis, where PaySystems installs the system and trains the venue in how to use it. After this,

PaySystems is only involved in troubleshooting and maintenance of the system and thus costs can be

58

quite low. Visitors will not be deterred by this system, since they already are familiar and

comfortable with this payment system.

The prepaid system suffers from the effort that is required upfront. All three require the visitor to

obtain a payment tool, whether it is a card, phone app or something else, and to load credit on this

tool. From the visitors point-of-view this is a large obstacle, especially when there are other venues

which they can visit that not require this. Contrary to large events, where visitors already lose a lot of

their anonymity when they buy a ticket, visitors of small events and venues are almost always

anonymous, and therefore a payment system which requires the visitor to register himself may find

resistance. As an extra factor, when there is a ticketing scenario, the distribution of payment tools

could be coupled to the distribution of tickets or the entrance of the event.

There are however also possibilities of reaching this goal with the current payment system. Especially

in fixed locations, which are open many times a year, there is the possibility to outfit them with fixed

token vending machines, which are easy to operate by the venue owner. PaySystems would supply

tokens, maintenance and troubleshooting services and the venue owner would be able to run this

system themselves. While the operation costs are still quite high, the visitors would be more inclined

to accept such a system, since there is no sign-up required and many of them are already familiar

with some form of payment tokens.

Operation Visitor attitudes

Real-time ++ ++

Prepaid + o

Current o + Table 6.3: Performance on market expansion

The performance on both factors, operational and the visitors’ attitude towards the system, for use

in small events or venues is given in Table 6.3. Although the operation of a prepaid system, either

electronic or the current system is an extra step for venue owners compared to the real-time system,

but there are still prospects for both. Visitors are familiar with token-based systems, since they’re

employed at many venues and therefore the current system scores slightly better than an electronic

prepaid system. An electronic prepaid system offers easier operation for venue owners, since there is

more automation and credit sales can be conducted without the need of a terminal if there’s wireless

connectivity, this makes it more scalable and offers prospects to service more venues.

6.2.4 Goal 4: Achieve high visitors’ satisfaction with payment at events

Achieving a reasonable degree of visitor satisfaction is important, since visitors may push event-

organizers towards an alternative payment system if they’re dissatisfied with the payment system

used. A recent survey conducted under visitors showed a very high satisfaction with the current

system: 86% of the visitors said to like the current token-based system and both the price per

consumption and the usability of the system are found to be important criteria. In electronic

payment scenarios, aspects such as trust in the payment system and the perceived security of the

payment play a big role as well.

The most important advantage that real-time systems have is that visitors are familiar with the used

method: They use it regularly in other settings and not only know how to use it, but also have a high

amount of trust in the payment system. Second, the real-time system also has the least amount of

59

process steps and this makes it a good choice in terms of usability. The only true disadvantage is that

it is very hard for visitors to keep track of how much they’ve spent or set a budget.

Although the current system has some clear disadvantages, such as the process step of buying

tokens, the reimbursement of tokens after the event and the limited possibilities of the amount of

tokens to buy, the system is well liked by visitors. This is mainly due to the ease by which they can

pay at the point-of-sale and the high usability of the tokens: Visitors can instantly see how much they

have left, are able to set a budget and are accustomed to tokens, since at many events, clubs and

discotheques there is a token-based system.

An electronic prepaid system can be developed in a way that many of the disadvantages for the

visitors from the current system are mitigated. Buying credit could be made easier, for example by

adding a way for the visitor to reload credit from any point of the event-area with a few button

presses, without having to go to a terminal. Other examples are buying credit in any amount and

reimbursement can be done in the same way as buying credit, possibly even after the event is over.

One concern however is that trust in the payment system will need to be earned over time and that

visitors may have initial concerns about the safety of an electronic payment system they’re not

familiar with.

6.2.5 Overall business goal performance

The overall performance on the business goals is aggregated in Table 6.4. It shows that the current

system has the best performance on the most important business goal: Maximizing the food and

beverage sales, mainly due to the redemption factor of the current system. How big the difference is,

is very hard to estimate at this point, while this is an important consideration when considering the

change.

Maximize sales

Cost reduction

Market expansion

Visitor satisfaction

Real-time o + ++ ++

Prepaid o + +/o +

Current + o +/o o Table 6.4: Overall performance on business goals

With regard to the other three goals, it is clear that the real-time system provides quite a big upgrade

in value over the current system, especially with regard to expansion possibilities and in visitor

satisfaction. The prepaid system however provides only a small upgrade in value, especially when it is

considered that the visitor satisfaction on the current system is sufficient. The only real upgrade over

the current system is then the reduction in the operational cost.

6.3 Compliance with quality requirements In this section the performance of the shortlist options regarding the quality requirements will be

analyzed. The five most important categories from the quality grid from chapter 4 will be discussed

one by one. For each of the shortlist options, it will be indicated if the option can fulfill the quality

requirements and what the expected complications may be in reaching sufficient levels of

performance.

60

6.3.1 Integrity and security

The way the system defends itself from threats, whether it’s a failure of a system component or

external factors, such as fraud-attempts, is highly dependent on which option is chosen and in some

cases even how this option is implemented. Since the analysis concerns the transactions at the point-

of-sale and because there is no automation at the point-of-sale in the current system, the integrity

and security is no concern in the current system: All six quality requirements are fulfilled or not

applicable for the current situation. The other two options will now be shortly discussed regarding

integrity and security.

When looking at integrity and security it is important to make the distinction to what degree the

system chosen is run by PaySystems. In real-time systems, PaySystems simply leverages one or more

payment system offered by financial institutions. This means that the transactions are not executed

on hardware and software of PaySystems. The integrity and security of these systems is therefore for

a high degree inherently offered by the financial institution as part of the payment system. And

because these payment systems are offered to the general public, they need to comply with many

government regulations regarding security and fraud prevention. As a consequence, the

requirements in this section will be covered by the financial institutions’ infrastructure and will thus

be of little concern to PaySystems.

The issue of integrity and security is a lot more complicated in a prepaid wallet system. There is a

large amount of hard- and software involved which is ran by PaySystems to keep the user accounts

and process transactions. The place where the visitors’ accounts are kept, on the payment tool or on

a database, presents different challenges for the integrity and security of the system. In systems with

a central database with accounts the connection between the point-of-sale and the database system

is very important as well as the security of this connection and the database itself to prevent fraud.

When the account is on the payment tool, this is of no concern, since there is no connection to a

back-office system necessary to process the transaction.

Further, in a system with a central database, visitors need to be protected from hackers who try to

pose as others in order to make purchases on their accounts. In systems where the account is kept

on the payment tool this is much harder, since the identification of the user itself is not enough to

conduct a transaction. In this case, it is much more interesting for fraudulent visitors to illegally up

the account balance on their payment tool, as can for instance be seen with the OV-Chipkaart. (Klis

2011)

But no matter if the accounts are kept centrally or on the payment tool, integrity and security will be

big concerns in designing and operating the system. Making the system not only resistant to fraud

and other malicious attempts, but also to disasters is a difficult job, since monetary transactions are

involved. An insufficient performance on these criteria will lower trust in the payment systems by

both visitors and event-organizers and will be bad for PaySystems’ reputation.

6.3.2 Correctness

Errors can occur in a system for a variety of reasons. The two main categories are errors in the

system itself where due to errors in the hard- or software transactions are conducted incorrectly and

secondly there are user errors, where end-users of the system handle the system in a wrong way. An

example of the former is a partly processed transaction, due to a power or connection loss. The

system needs to be able to recognize that such an error occurred and restore a proper state. The

61

latter most commonly happens due to input/output errors of the users, in this case the point-of-sale

personnel and visitor.

Since in any electronic system the amount due, or the products ordered, need to be entered into the

system, input errors become a distinct possibility for any electronic system. To prevent input errors

both the vendor and visitor will need to be able to see what amount was entered into the system.

Further, the success or failure of a transaction needs to be clearly presented to both, so that reality

matches with the payment that is executed in the database. The action of serving drinks or food is

reliant on the success of the payment, so this needs to be clear.

Correctness in the hard- and software of the system itself is a different issue. In real-time payment

systems, the transaction occurs on systems of the financial institution(s) offering the payment system

and thus correctness is provided by these systems themselves. The prepaid system will need to fulfill

the correctness requirements itself. Most database systems currently adhere to the ACID-principles

(Garcia-monlina, Ullman et al. 2000) which ensure that transactions in the database are conducted in

a way that correctness of the database is ensured. Coupled with a proper identification of the visitor

at the point-of-sale, this could ensure correctness of the system. Should account balance be kept on

a payment tool, these ACID-principles should be implemented as well, to ensure a proper balance on

the payment tool at all times, but proper identification is less of an issue, since no wrong account can

be debited.

6.3.3 Reliability and availability

As explained in chapter 4, the availability of the payment system during the event is essential. There

can be no sales made if the system is unavailable at the point-of-sale. Again, as with the previous two

quality factors, there are significant differences on how to ensure this between real-time systems

and the prepaid system, which are designed and ran by PaySystems. Since the only requirement for

point-of-sale transactions in the current system are the availability of tokens by the visitor, there is

no concern here.

A major problem is that real-time systems are generally not suited to process transactions in the

event of a connection loss. With both debit and credit cards a connection to the bank is necessary for

the transactions to be completed. This presents a great risk for PaySystems, since if the connection is

lost, or the system goes offline due to another reason, the entire system is down, which is

unacceptable. Therefore this either needs to be prevented to a sufficient extent, for example by

redundant connections, or otherwise handled, for example by accepting multiple real-time methods

at the point-of-sale to ensure redundancy.

If PaySystems themselves designs and operates a prepaid wallet payment system, they can be more

flexible in this. Payment terminals could for instance buffer transactions in the case of a system

failure and process them once the system is back online. Should the choice be made to keep balance

on a payment tool this even becomes less of an issue, due to the fact that no connection is

necessary.

Future developments may however present solutions for availability of real-time systems. Financial

institutions are working on the availability of their real-time payment system, since this is very

important in their long-term desire to decrease the amount of cash transactions. Therefore it can be

62

expected that solutions, such as offline debit card transactions during connection losses, present

themselves in the short-term.

Regarding robustness of the system, there is again way more flexibility with a proprietary system

designed and operated by PaySystems than with a real-time system. Real-time systems have a

complement of hardware, such as terminals, which is inherent to the system. There is limited

flexibility for PaySystems to increase the robustness of this hardware. When terminals and other

hardware is designed specifically for the system, there are more options to make terminals robust.

6.3.4 Usability

Real-time systems are adaptable to the event-market only to a small extent while in a prepaid

system, it can be designed to meet the usability criteria to the best extent possible with regard to the

other requirements. This means that the potential of such a system with regard to usability is greater

than with a real-time system. But there is also an upside to the use of real-time systems: Visitors are

familiar with these systems from other payment scenarios and thus are able to use the system

without any explanation or learning curve.

Another factor is the vendors: they have many employees working with the system during an event

and many are temps, so the learning curve of the system is important for them too. They should be

able to use the system with a very high speed and accuracy without much training. The input of

orders into the system needs to be done by means of an input terminal, whether the system is real-

time or prepaid, so this part of the system, PaySystems can design an input system which is easy-to-

use for employees.

The payment terminal which is used by the visitors to conduct the payment is however highly

dependent on the system used. Real-time payment systems come with standard payment terminals.

There are multifunctional terminals, which can handle debit and credit cards, but they do not

necessarily fully fulfill the usability requirements, since the transaction times are typical quite high

for event purposes, (Atkinson 2006) which is one of the primary reasons the token-based system is

currently being employed. In the prepaid system, the terminal can be developed by PaySystems and

tailored to meet the usability requirements of the event-market.

6.3.5 Efficiency

The current payment system with the plastic tokens is as efficient as it gets: A transaction at the

point-of-sale takes almost no time at all, just a case of handing the tokens from visitor to vendor, and

any electronic system is unlikely to perform better. Scalability is a concern in the current system,

since human resources and vending machines are limited in number and thus token sales are limited,

but an unlimited amount of points-of-sale can be serviced. Since the current system performs so

good and the fact that efficiency is so very important make it seem that there are little prospects for

any of the alternatives.

There is an important factor to consider however. When looking at the business processes in chapter

5, one can see that while the process at the point-of-sale of the current system is linear: The

payment happens before the vendor retrieves the order. In both electronic systems the vendor

enters the order or amount due into the system and then payment and retrieving the order can

happen in parallel, since the vendor is not a part of the payment process itself. The vendor can

retrieve food or drinks and when he comes back with the order some seconds later the payment has

63

hopefully been successful and a visual signal notifies the vendor of this fact. This could save some

time and make the electronic system efficient enough to be viable. Further, since almost all options

save on the operational costs there is some room to offset an efficiency loss by increasing capacity.

The transaction speed of the different shortlist options is again a matter of flexibility with the prepaid

option and the system inherent performance of the real-time system. A prepaid system could be

tailored to be as efficient as possible, while currently the real-time systems underperform somewhat

and there is limited room for PaySystems to improve performance. Debit cards are not fast enough,

but the systems of financial institutions are changing and transaction speed is enhanced because of

it. MasterCard’s PayPass (MasterCard 2011) is an example of a faster implementation of a traditional

payment system. Dutch banks are also looking at contactless payments which would help transaction

speed.

The scalability and accompanying bandwidth requirements are of little concern in real-time systems:

These systems service many thousands points-of-sale in different settings at once. For example, debit

and credit cards are accepted at almost any store and thus there are many tens of thousands

terminals connected at any time. Thus it would be no problem to connect as many terminals as

needed to the system. However, the bandwidth requirements per terminal may be quite high, so

connecting as much as 1000 terminals may require a very large and expensive internet connection.

In the prepaid scalability is a major concern if accounts are kept on a central database, since the

database system should be able to handle over a thousand terminals without losing transaction

speed. Bandwidth is a similar concern here, although an attempt could be made to keep the protocol

lightweight. When accounts are kept on a payment tool, there is little data to transfer, so both

scalability and bandwidth requirements are of little concern.

6.4 Implementation costs and barriers In this section the most important implementation issues regarding both the real-time and prepaid

system will be discussed. This will be done by presenting the most important and difficult barriers

that will need to be cleared before these systems will become feasible for large-scale use at public

events and by assessing the effort and cost that implementation will take. The two electronic system

options will be discussed one by one and the current system will be omitted, since it is already

implemented.

6.4.1 Real-time system

In this section the most important remaining barriers for successful implementation of the debit card

payment system will be shortly discussed. These are issues that need to be solved going forward to

ensure that the debit card system will actually be a success. Since a large part of the payment

processing infrastructure is a given for PaySystems, there are limited possibilities for PaySystems to

solve these issues. The components which PaySystems deploys are the payment terminals, input

terminals and the connection to the Equens-infrastructure. These need to be designed and used in

such a way that the quality requirements can be met.

Transaction speed Debit card transactions take a relative long time and therefore it is unlikely that the quality

requirements on transaction speed will be met without modifications. There are many studies in the

speed of different payment methods and the results show that payment with a magnetic swipe debit

64

card takes about 24 to 26 seconds, which is longer than cash. (Alliance 2004; Atkinson 2006; Polasik,

Górka et al. 2011) Currently the magnetic strips on debit cards are being replaced by chips, which

post similar transaction times. This is very far of the quality requirement, which lists a target of 4

seconds. Even though these 25 seconds are measured in a fairly general set-up and it is more than

likely that with a good infrastructure and optimal input- and payment terminals a fair amount of

seconds can be gained, it is unlikely that the target will be met with a debit card system.

There is also good news. Many debit card terminals allow the user to conduct his payment actions in

parallel with the input of the amount due in the system. The customer needs to insert his card, type

in his 4-digit PIN-code and authorize the payment. The authorization requires the amount due to be

send to the terminal. After this, the transaction is offered to the Equens-infrastructure and the wait is

for confirmation. This typically takes 2 to 5 seconds. (Currence_1 2011) Further, while the customer

conducts the payment and waits for confirmation, the vendor can already retrieve the food or drinks

that the customer ordered. This may reduce the ‘pure’ transaction time, the time that the vendor is

working on or waiting for a transaction, possibly to the extent that the gap between the target set in

the requirements and the pure transactions time is manageable.

Another initiative to keep an eye on is MasterCard’s PayPass, (MasterCard 2011) which is already

discussed multiple times in this thesis. In short, it leverages contactless technology to conduct

payments over the credit card payment infrastructure. Compared to a normal credit card transaction,

the magnetic stripe card is replaced by a contactless card, key fob or mobile phone app as payment

tool and a contactless reader is used as payment terminal. PayPass transactions are significantly

faster than normal credit card transactions: PayPass, and similar contactless systems, report

transaction times of 12 to 15 seconds. (Alliance 2004; Atkinson 2006) These contactless initiatives are

not yet widely used in Europe, but once proven successful in the US, adoption in Europe is a matter

of time. Since the infrastructure on which these credit card payments are offered is the same for

debit cards, it should become possible to leverage contactless technology for debit card transactions

in a similar way.

Offline payments There is another important quality requirement that is currently not fulfilled by the debit card

payment system and that is the ability to continue sales even when there is a connection loss from

the point-of-sale. To process a debit card payment there is always a working connection necessary to

the Equens-infrastructure. When it is offline for whatever reason, payment cannot happen and they

also cannot be buffered for processing when the link is restored. While the uptime of the debit card

system is quite good, it is not 100% and due to often unpredictable conditions at event locations and

the temporary set-up of the IT-infrastructure there is an added risk of the system experiencing

downtime. Since debit cards would be the only payment option (a possible extension with credit

cards wouldn’t help, since they use the same infrastructure) this would stop sales entirely at the

point-of-sale.

This is therefore the second problem that needs to be solved and there are several directions to turn

to. The most obvious option is to reduce the chance of downtime happening, for example by building

redundancy in the connections. Not connecting all terminals in one point-of-sale through the same

connection, making use of a WiFi or UMTS back-up for when wired connection is lost. There could

also be an organizational solution, for example keeping an emergency supply of cash at each point-

65

of-sale and switch to cash when the system goes down. The viability of such options needs to be

researched before a proper solution can be chosen.

This problem could also be solved by banks themselves. They’re heavily promoting the usage of

electronic payment in favor of cash in all sectors and they too are working on this problem. In some

other countries, it is already allowed to buffer debit card transactions in case of a connection loss

and process them once connection is restored and it is very conceivable that this will become the

case in the Netherlands as well in the short to medium term.

Robustness There are many payment and input terminals available on the market, but they are not specifically

designed for the event market. This could not only mean that they are not optimized for speed, but it

could also mean that they are not fit for the conditions in which they need to operate at events.

Since the sales happen at food and drink vending points, the terminals will need to be able to

withstand spills on them, whether it’s food or a beverage. Many events take place outdoors, so rain

water or mud can also get on the terminals. Finally, the terminals must be able to withstand a

reasonable amount of abuse from visitors. This should be an important selection criterion when

looking for terminals and some research should also be done what it would cost to design terminals

from scratch which are tailored to requirements of the event market.

Implementation costs and risks Since the real-time system fulfills many of the quality requirements by itself and there is little

possibility to do something for the requirements where this is not the case, the implementation costs

are quite limited. The main costs incurred when choosing a real-time system are the hardware, such

as payment terminals and the connection to the banks’ infrastructure. While these are expected to

be substantial, because of the amount of terminals that need to be connected, there is little

development costs, since the system’s infrastructure is already up and running.

Therefore there is little risk associated with the design and implementation of a real-time system: It

is a proven payment system, which is adopted and trusted by the visitors of the event. Issues as

security, fraud prevention are all tackled and therefore there is little risk to the reputation of

PaySystems as a reliable payment service provider for events. The technology is also proven in many

contexts and therefore the implementation is fairly straightforward and risk-free. Should something

go wrong, for example in the domain of security, the risk is mostly covered by the financial institution

providing the real-time payment system further reducing the risks for PaySystems.

6.4.2 Prepaid wallet

A prepaid system allows PaySystems more latitude to develop the system in a way that best fits the

specific requirements of the event market: Efficiency, reliability, ability to support revenue sharing,

all while keeping increasing the sales volume in the back of their mind. The downside of this is

however that far more choices need to be made and that designing a system which in fact meets all

these requirements takes a lot more work than simply deploying an already existing real-time

system. This section will go in to some specific issues that need to be solved before a prepaid system

can be considered feasible and will also touch upon the costs and risks involved in implementing a

prepaid system.

66

Scalability One of the most important problems that PaySystems will encounter when designing and

implementing a prepaid payment system is scalability. At large events, there are many points of sale

and they all will need to perform up to standard. Making sure performance doesn’t slip when these

events operate at peak-capacity is critical.

An important decision that needs to be made that has a lot of impact on scalability is where to store

the account balance. The option which looks most promising in this regard is to keep the balance on

the payment tool, since that allows the payment terminal and payment tool operate stand-alone,

without regarding a central system which handles all the other terminals as well. This does make the

payment tool a more critical part of the system because data is stored on the tool and the

correctness of this data is vital for success of the system. The OV-Chipkaart works in this way and this

has led to fraud and undermined confidence in the system. This could present a financial risk for

PaySystems as well as hurt their reputation.

Legislation Another consideration is the regulations regarding electronic-money. As specified in the EU’s E-

money Directive (EU 2000), there are strict requirements for firms who want to issue electronic

money. Firms need to have a license to issue e-money or they need to fall within the limits regarding

the amount of e-money issued and the scope for which it is usable to get an exemption. PaySystems

falls on the edges of these exemption issues, so this is an important issue to consider and it’s

advisable to make sound arrangements before the system is employed to prevent legal issues down

the road, especially when growth is factored in.

Implementation costs and risks While a prepaid system presents fewer barriers to implementation and has more influence in

overcoming these, since PaySystems can build the system the way they like and because the point-

of-sale transactions are independent from third party infrastructure, there is little which stands in the

way to fulfill all quality requirements. But the size of the system that needs to be developed and ran

by PaySystems is much bigger than with the debit card system. There are many more components to

consider and they all need to comply with the quality requirements presented in chapter 4.

Instead of just point-of-sale payment terminals, in a prepaid system visitors need to be provided with

a payment tool, which is used to either store the credit of the visitor and process the transactions (in

conjunction with the payment terminal) or to identify the user at the point-of-sale. If the latter is the

case, there another important component is needed in a transaction: a database system which keeps

the account balance of the visitors and processes the transactions in conjunction with the payment

terminal. Developing these components in a way that fulfills all quality requirements will be very

costly since it should be a very fast and scalable system with a high security and fraud prevention

standard, because money is involved in the transactions.

Due to the size of this implementation there are not only more costs involved, but the risks are also

much higher. PaySystems itself is responsible for the correctness and security of the transactions and

the credit balance of the visitors and because there are many quality requirements this system must

fulfill, the implementation is very difficult and thus risky.

67

6.5 Conclusion This section will present the advice regarding electronic payment for PaySystems. First off, some

market considerations for each of the option will be presented to explicate the reasoning behind the

actual advice in the second subsection. The final part of this section will present the most important

avenues for future research to strengthen this advice and move towards implementation.

6.5.1 Market considerations

Real-time system The market position of PaySystems could considerably change when a debit card based payment

system is chosen. The preliminary analysis of the operational costs in a real-time system shows that it

performs better than the current system in this aspect. This means that PaySystems may be able to

offer the system to potential customers for a lower price than their current offering. Coupled with

the excellent prospects for market expansion to fixed venues and smaller events, this makes the

potential market for PaySystems quite a lot larger. This means that attention needs to be given to

how PaySystems can scale the number of events and venues they service in the future, both from a

technological as from an organizational point-of-view.

There is also a concern: The physical elements of the payment system that PaySystems deploys are

the input and payment terminals. Such terminals are available from many suppliers for anyone and

thus PaySystems should take a close look about how substitutable they become for their customers.

Currently, the token vending machines are a proprietary piece of hardware, which is a unique part of

PaySystems’ value proposition. It is essential to offer something unique that is of value to event-

organizers. In practice this means adding something that is not easy to replicate.

When looking at the e3 value model in chapter 4, there are two transactions that PaySystems

supports: the point-of-sale transaction and the revenue share. PaySystems improves the

performance of the point-of-sale transaction by using tokens as payment medium and it conducts

the revenue share transaction. Once the credit sale is removed from the equation, PaySystems is only

involved in the revenue share and this severely limits the scope of the value proposition. PaySystems

could however stay relevant in the point-of-sale transaction by enabling top performance, for

example by using proprietary terminals or leveraging its IT-connectivity knowledge and experience.

Prepaid The market position of PaySystems will remain very similar to the current situation: It will offer a

complete payment solution, from payment tool to financial handling, which is tailored to public

events. There are more possibilities to expand the system to other venues, but since the value

proposition is essence the same as with the current system there are no other big changes here, the

market position of PaySystems is poised to stay strong, provided of course that the new system

functions properly and meets the needs of customers.

Current PaySystems’ current system is quite expensive for event-organizers, but in turn it offers good value

over the alternatives available to the event-organizers. This however can change when there are

important improvements made by substitutes or competitors. A prime example of this is debit card

payment systems adopting contactless payments, similar to MasterCard’s PayPass. (MasterCard

2011) This may make the debit card payment system a very good alternative for event-organizers

compared to the expensive system of PaySystems, although they would themselves need to deploy

68

the system. In short, PaySystems needs to be aware that its market position may change over time

and stay ahead of it.

6.5.2 Advice

In the short-term, the current system is considered the best system going forward. There are many

implementation barriers to overcome before the real-time system becomes a feasible option, some

of which are beyond PaySystems’ control. The prepaid system offers only limited added value in

comparison to the current system and this value is mostly a reduction in operational costs, while the

expected investment in the development of such a system is very high and the implementation

carries a lot of risk.

Although it is not feasible at the moment, the real-time system does offer a significant value to

PaySystems, mainly due to the excellent opportunities it offers to grow by expanding the market.

Therefore, it is advised to pursue implementation of this system by attempting to mitigate the

implementation barriers, either by improving components of the system or by working together with

the financial institutions offering these systems to overcome these barriers, since many of these

barriers are also viewed as negatives by them.

Finally, PaySystems should keep a close eye on the payment market, because changes may not only

help facilitate the implementation of a real-time system, but they may also become a serious threat

to the market position of the current system of PaySystems. This could force the hand of PaySystems,

forcing them to change to electronic payment, and maybe even a prepaid system, earlier than they

otherwise would.

6.5.3 Future research

The advice already gives an indication where PaySystems should focus their efforts: In the coming

period PaySystems should focus on researching the various implementation barriers for the debit

card payment system. It is essential to know in detail what the feasibility of the system is so a switch

can be considered as soon as the barriers are overcome. Another important aspect is how to

implement the debit card system: Can it be used in combination with the current system, which

would allow for a gradual rollout of the system which would limit the risks during the

implementation phase. If it’s not viable to run two systems in parallel, the change will need to

happen rather sudden and this would mean that implementation becomes more complicated.

Another big unknown in this is the performance of both systems on the most important business

goal: Maximizing the food and beverage sales. If this can be quantified more accurately, a preference

for one of the systems may also present itself, or it could show that the current system outperforms

the presented alternatives to such an extent that a change is not an option that is acceptable for the

customers of PaySystems, unless there is a serious cost-saving aspect.

The final issue that needs to be critically considered is the timing of the change to a new system. At

this moment, the current payment system still functions well. PaySystems’ customers and visitors at

events are satisfied and PaySystems is profitable. Therefore there is no need to implement a new

system as soon as possible, but should the market demand electronic payment at some point,

PaySystems needs to know this as soon as possible so they can make a choice; either for a

(suboptimal) real-time system or to develop their own prepaid system.

69

7 Discussion and conclusion In this chapter the research in this thesis will be concluded. First the research questions, which are

presented in the introduction will be answered using the results from the previous chapters. Then

the research done will be shortly discussed: Attention will be given to the theoretical implications of

the results and the limitations of the research. The recommendations for PaySystems which follow

from this thesis will be summarized in the next and final chapter.

7.1 Answers to the research questions The main objective of this thesis was to research whether there are possibilities for PaySystems to

implement some form of electronic payment for retail transactions at public events. The main

problem statement covers this objective and the results will be given in this section. Before it can be

answered, the research will be shortly recapped by answering the research questions presented in

section 1.1.

What technological developments are currently influencing the retail payment landscape? In chapter 2 the retail payment landscape is analyzed, with an emphasis on the situation in the

Netherlands. There are three stakeholders in payments: the customer, the vendor and the payment

service provider, who operates the payment system, which is the role of PaySystems at events. Most

vendors accept various payment instruments, since this offers choice to their customers. Electronic

payment systems, such as debit card payments and e-purses, become increasingly popular and there

is a lot of development in electronic payment. There are some promising technologies which enable

new systems, which are easier to use and faster than the current systems. There are already pilots or

fully-implemented payment systems based on 2D Barcodes, contactless cards or tags and Near Field

Communication. Such new systems deployed by others may be a threat to the market position of the

current payment system of PaySystems, but these technologies may also offer possibilities for an

electronic payment system for PaySystems.

Is the current business model of PaySystems sustainable in the future? Business modeling is used to accurately analyze the current payment system of PaySystems and the

future outlook of this system in the changing payment landscape. Business models show how an

organization creates and captures value and one of their main uses is to identify risks and pressure

areas, therefore it is used to assess the sustainability of PaySystems’ payment system.

PaySystems currently has a good market position at large scale public events, because their system

fits very well with the needs of payment at events: Transaction speed, robustness/reliability and the

support of revenue sharing between vendor and event-organizer. Further it maximizes the food and

beverage sales and the system is entirely operate by PaySystems, which is important for event-

organizers. PaySystems can deliver superior value to its customers because of their unique business

partners: FAB which can handle event catering for the event-organizers and Dutchband to develop

their payment system further.

The downside is that the system is quite expensive for event-organizers and due to the increasing

financial squeeze they face there are concerns about the sustainability of the business model. Event-

organizers could be enticed to look at the new payment systems offered by banks and other payment

service providers as they leverage the new payment technologies discussed in chapter 2. These

systems will probably be at the same price level as the current payment systems offered by banks,

70

which is quite a bit lower than PaySystems’ price level. Should they provide value that comes close to

the current payment system of PaySystems, they may prove to be a big threat going forward.

What are the business goals and requirements for an electronic payment system at public events? There are four business goals identified in this thesis for an electronic payment system and they for

the most part can be related back to the business model analysis. The first business goal is

maximizing the food and beverage sale, which is an important part of the value proposition of

PaySystems and a critical factor for both event-organizers and vendors. The second goal is minimizing

the operational costs of the system, which would allow PaySystems to improve its margins and/or

reduce its price level. Expansion into other market segments, such as smaller events and fixed

venues, is not directly derived from the business model, but this is an ambition that PaySystems has

for the future. The final business goals is achieving a high visitors’ satisfaction is mainly inserted to

ensure that the interests from these stakeholders are kept in mind, since they’re not directly helped

with the other business goals.

Payment at public events has three primary characteristics, which together are represented in the

critical elements of the requirements specification. High efficiency, which is the speed with which the

system works, is the most important quality requirement, since there are many sales and high peak

volumes, the throughput at the point-of-sale is of the utmost importance to all stakeholders and the

prime reason the current system is attractive to event-organizers and vendors. The reliability of the

system is also a critically important quality requirement, since the vendors accept only one payment

system, failure of the system means that no sales can occur. A complication is that many events are

held in temporary outdoor locations, so the system must operate in a difficult environment. Finally,

revenues of food and beverage sales are most often split between vendor and event-organizer. This

revenue sharing needs to be supported by the payment system and thus this is an important function

in addition to the payment itself.

Which alternatives for payment systems are viable for PaySystems? There are three primary options for PaySystems going forward. First off, they can leverage one or

more of the real-time payment systems offered by banks to fit the specific needs of event-organizers

regarding transaction speed, reliability and revenue sharing. The main advantage is low investment

costs, but it is unclear if the chosen system(s) can fulfill the critical requirements to a satisfactory

degree. The second option is to design and build a proprietary prepaid payment system. In such a

system, a visitor gets an account with PaySystems and this account is debited when a purchase is

made. Before the visitor can make purchases he needs to deposit money on the account. Such a

system can be tailored to the specific needs of events: speed, reliability and revenue sharing, but the

investment costs are expected to be higher. The last option is to keep the current system for the near

to medium-term future. The main advantage is that there is no investment costs or risks and that the

current system fulfills all important requirements, but the sustainability of the current system needs

to be watched closely to ensure the market position of PaySystems going forward and business goals

may not be reached.

How do these alternatives fit with the business goals and requirements for electronic payment at public events? The performance of the three alternatives on the business goals are estimated by the impact to the

business model the implementation of the alternative will have and literature on similar systems. The

performance on the most important business goal, maximizing sales revenue, is expected to suffer a

71

small decline with both a real-time payment system and a proprietary prepaid system, mainly due to

the fact that there is no or little redemption in electronic payment systems. When looking at the

other business goals, a real-time system offers a lot of value, especially since it is not only expected

to reduce operational cost, but the prospects for market expansion are very good, due to good

scalability of the system. The only true upgrade that a prepaid system offers over the current system

is a reduction in costs. While it could also perform better on visitors’ satisfaction, the current system

performs adequately on this aspect.

Real-time systems have a set performance on all quality requirement factors. This means that there

is little cost involved for PaySystems in implementing this system, but it also means that if the

performance is not up to the requirements there is limited room for PaySystems to improve the

performance. This is especially likely on the critical areas of efficiency and reliability, because the

performance targets are especially high there. While the prepaid system can probably meet all

quality requirements, it is far more complicated to design and build, since non-critical quality

requirements, which are fulfilled by the real-time system without problem, will need to be

considered in the design of a prepaid system. Examples of this are security concerns, fraud

prevention and the correctness of the system.

The answers to the research questions above give a basis on which to answer the research objective

can be presented. The research objective reads:

What are the possibilities for PaySystems to introduce electronic payment technology at

public events?

Compared to the current system, the prepaid alternative offers little upside: There is a possibility to

reduce the operational costs somewhat and there are some ways to make it more friendly to the

visitors of the event. So while PaySystems may be able to offer this system at a reduced price to its

customers due to the cost reduction, it is likely they occur some losses due to the lower performance

on maximizing the food and beverage sales. Coupled with the high investment costs and the risk that

the implementation entails, it is unadvisable to develop a prepaid system.

A real-time system based on the banks’ infrastructure delivers much better value, since the cut in

operational costs is probably more profound and because there are far better prospects to increase

the market segment of PaySystems. And this while the investment costs and the risks of

implementation are substantially lower since the proven infrastructure of the banks is used. The

problem is that the use of a real-time system might not be feasible since the available systems may

not fulfill the critical quality requirements involving transaction speed and reliability. But if these

problems are overcome, this would be serious option for PaySystems.

In the short-term, it is therefore advised to stick with the current system, while work is being done to

overcome the implementation barriers of the real-time system. When this proves successful, an

implementation of the real-time system can be pursued. In the future it is also be important to keep

a close eye on the developing payment market, since there may be new systems which would be

feasible for PaySystems. The sustainability of PaySystems’ business model should also be watched

72

closely because if it is threatened, a switch to an electronic system may become a necessity, in which

case a prepaid system might have to be reconsidered.

7.2 Discussion In this section the research will be discussed from the theoretical side. First some attention will be

given to the theoretical implications from the research done and what lessons can be learned from

the methods used. Then the limitations of this thesis will be briefly discussed to put the presented

results and recommendations in perspective.

7.2.1 Theoretical implications

The first theoretical contribution is that in the section on business modeling the most common

ontologies are compared to one another and an attempt has been made to identify the common

elements. Although these ontologies all have the goal to define the concept of business modeling

along with its elements and functions, there are still a lot of differences between them. Second the

industry specific framework of Pousttchi, Schiessler et al. (2009) is used to make sure all relevant

aspects are covered. Although this took quite some effort and there were some aspects which

weren’t especially relevant in this case, this method helped think about some non-obvious aspects,

especially in the value network and value architecture categories. Especially when the analyst is not

very familiar with the industry, such a model will provide valuable, since it helps ensure

completeness of the model. The relation between business models and threat model, which is an

element in the Pousttchi framework, was an interesting aspect to analyze and this thesis argues that

it is not an element of a business model.

The relation between business modeling and requirements engineering also deserves some

attention. First off, many of the business goals can be directly traced back to the business model,

since they are meant to satisfy the stakeholders and their needs are described in the value

proposition. The financial analysis of PaySystems’ business model gives an estimation of were many

of the costs are made and thus were costs can be saved and this is reflected in one of the business

goals. The choices made in the quality grid in Table 4.1 can also be traced back: The critical factors

feature prominently in the value proposition of PaySystems, while the others are not actively

mentioned. Finally, an e3 value model is presented to accurately show the value transactions in the

business model of PaySystems’ current system. These transactions are relate to the user tasks in the

system and thus form a starting point for high-level functional requirements engineering.

Finally, in chapter 5 the shortlist alternatives are derived by using the payment time as a basis. The

reasoning behind this was that for each payment time alternative, the business process of the

payment system is different. While this is the case, further analysis of the options showed that there

are many similarities between the three proprietary options: prepaid, postpaid and auto-reload. The

costs of implementation of these systems are very similar as well as the impact these systems have

on the business model of PaySystems. Therefore the difference between using a real-time system or

building a proprietary system may be the more important choice and was in the end used to come

up with the shortlist.

7.2.2 Limitations

The most important limitation of this thesis is that the three shortlist alternatives are compared

based on best effort assumptions. While these are based on observations, interviews and literature,

they are not measured and quantified. It is especially hard to assess the impact the prepaid system

73

and the real-time system have on the food and beverage sales. As explained in chapter 4, a drop in

sales will likely lead to severe resistance from both event-organizers and vendors, so it is essential to

assess to what extent a new system will influence sales. The performance of the alternatives on the

other goals also isn’t quantified, but since the real-time system comes out on top on all three of them

and that it is the cheapest option of the two, a solid decision is possible without quantifying these.

A second limitation is that the quality requirements are not based on measurements. As an example,

the targets that are presented for the speed by which a transaction must occur are based on

observation of the current payment system in action, but measurements on how much time the

various steps of the business process take will give a better picture about the constraints by which an

electronic systems should operate. Further, there are no business cases made for the two

alternatives for electronic payment. This is a critical step to assess the costs and risks of

implementing one of the options and it would be advisable to make a solid business case before

starting an actual implementation.

Finally, there is an important practical issue for payment systems at public events to consider. The

current payment situation at public events is quite unique, in large part due to the fact that retail

payment is currently seen by many stakeholders as a profit center: Not only the cost of payments are

important, but also how much money can be made with payments. In the current system, this money

is being made by upselling and the redemption of tokens. In almost all other payment scenarios,

there is no party making money on the payment itself except for the organization offering the

payment system to the vendor. These costs are either directly or indirectly included in the price of

the good or service sold, but there is no money being made by the vendor. There are other

exceptions of course, such as public transportation, where some account balance on the OV-

Chipkaart may never get used.

This makes the needs of the customers of PaySystems far more complicated than those of most

vendors in typical retail situations. While they also like a low-cost, reliable and efficient payment

system, the amount of money the payment system can earn for them and the vendors is an extra

complication. Since this issue is quite unique, the generic, real-time payment systems offered by

financial institutions do not consider this issue at all. This means that PaySystems

74

8 Recommendations This chapter will summarize the recommendations made to PaySystems regarding electronic

payment. It will focus on the most critical things that need to be taken care of before the change

towards an electronic payment system can be made.

Make accurate measurements regarding efficiency Efficiency is such an important part of the value proposition that it will be very hard to come up with

a credible system which does not fulfill the requirements regarding efficiency. On the other hand, it is

one of the most difficult barriers to clear when choosing for a real-time system. In this thesis a best-

effort guess is made to decide where to put this barrier, since a detailed analysis based on

measurements falls out of the scope of this broad, exploratory study. But if this guess is too low, then

a perfectly viable real-time system may be disregarded due to the fact that it is not fast enough, and

if it is too high, a system may be chosen which is too slow and the stakeholders will not accept the

new system. It is therefore vital to ensure that the efficiency target is accurate, which could be

investigated by measuring the speed of the different steps in the business process of the current

system and by tests with prototypes of a new system.

Explore pilot opportunities in cooperation with banks Banks and other financial institutions are actively involving themselves in pilots regarding new

payment systems, such as contactless payment. The public event market would present a challenging

environment to run pilots with these new systems due to the unique quality requirements. This has

the benefit that PaySystems may become involved in the further development of these systems and

the potential roll-out in the event market. This may help new real-time system better fit the specific

needs of the event market and thus increase the feasibility of these systems. PaySystems could also

learn a great deal from these pilots without investing a lot themselves.

Accurate assessment on market potential in fixed venues One of the important ambitions PaySystems has is to expand its market towards smaller events and

fixed venues, which is reflected in the business goals for the electronic payment system. The

excellent potential of real-time systems regarding this goal is one of the main reasons this option is

presented as the primary one going forward. Whether this potential can actually be realized is not

yet clear. A big change from the current system to a real-time system might not be worth it when

there is little willingness by potential customer to pay for the use of the system. Further some

investigation in specific needs for these customers is an important aspect as well to ensure actual

realization of gains from this goal.

Build a solid business case which makes sense for PaySystems and for event-organizers An important aspect of the value proposition is that although event-organizers pay a high-end price

for the current payment system is that it often makes financial sense for them, since PaySystems

increases the food and beverage sales and reduces other costs for event-organizers, such as the

amount of catering personnel needed. This means that when changing to a new system it is very

important that the system still makes financial sense for these event-organizers. When building a

business case for one or more options, it is important to not only consider PaySystems’ costs and

revenue, but also consider the business case from the side of their customer, the event-organizer.

These business cases are not yet considered in this thesis, since there is more quantitative research

necessary to make numbers available, for example on how a system might impact food and beverage

sales and how much bandwidth and thus connection costs are made in a new system.

75

Prepare a detailed plan for implementation Whichever option for electronic payment is chosen in the end, there will be a drastic change in a

critical aspect of an event, both from a financial and an organizational point-of-view. Not only do the

technical aspects change, such as the IT connectivity and the robustness of the terminals, but also

the organizational aspects, since the key activities and resources associated with a new payment

system will change significantly. This makes an immediate cutover to a new system very risky and

difficult to manage. Running the system in parallel with the current system and thus implementing

the new system gradually carries less risk, since there is a back-up available during the first period.

This is quite expensive however, seeing that the costs of the payment system are quite high as it is.

Therefore a detailed plan needs to be in place to handle the implementation in a way the risks

remain manageable while keeping the extra costs in check. Of course, running pilots and starting at

relatively small events is advisable as well. Once everything is found to be working, the system can be

scaled up.

76

References. Ailawadi, K. L. and S. A. Neslin (1998). "The Effect of Promotion on Consumption: Buying More and

Consuming It Faster." Journal of Marketing Research 35(3): 390-398. Al-Debei, M. M. and D. Avison (2010). "Developing a unified framework of the business model

concept." European Journal of Information Systems 19(3): 359-376. Alliance, S. C. (2004). Contactless Payments: Delivering Merchant and Consumer Benefits. Alliance, S. C. (2007). "Proximity Mobile Payments: Leveraging NFC and the Contactless Financial

Payments Infrastructure." White Paper: Smart Card Alliance. Andersson, B., M. Bergholtz, et al. (2006). "Towards a Reference Ontology for Business Models."

Conceptual Modeling - ER LNCS 4215: 482-496. Arendarenko, E. (2009). "A study of comparing RFID and 2D barcode tag technologies for pervasive

mobile applications." MSc Thesis, Department of Computer Science and Statistics, University of Joensuu.

Atkinson, J. (2006). Contactless Credit Cards Consumer Report 2006. Find Credit Cards. Balan, R. K., N. Ramasubbu, et al. (2009). mFerio: The Design and Evaluation of a Peer-to-Peer Mobile

Payment System. Proceedings of the 7th international conference on Mobile systems, applications and services, New York, NY, USA, ACM.

Bhalla, G. (2010). Collaboration and co-creation: new platforms for marketing and innovation, Springer.

Bolt, W. and S. Chakravorti (2010). Digitization of Retail Payments. DNB Working Paper. Amsterdam, De Nederlandse Bank.

Borzekowski, R. and E. K. Kiser (2006). The Choice at the Checkout: Quantifying Demand Across Payment Instruments. Finance and Economics Discussion Series. Washington, D.C., Federal Reserve Board.

Brits, H. and C. Winder (2005). "Payments are no free lunch." De Nederlandsche Bank Occasional Studies.

CardTech (2000). "ACI Adds Chipper To Its Chip Portfolio." Card Technology(http://www.cardtech.faulknergray.com/jun00.htm).

Carr, M. (2008). "Mobile Payment Systems and Services: An Introduction." Institute for Development and Research in Banking Technology.

Chan, P. K., W. Fan, et al. (2011). "Distributed Data Mining in Credit Card Fraud Detection." Intelligent Systems and their Applications, IEEE 14(6): 67-74.

Chesbrough, H. and R. S. Rosenbloom (2002). "The role of the business model in capturing value from innovation: evidence from Xerox Corporation's technology spin-off companies." Industrial and Corporate Change 11(3): 529-555.

Chess. (2011). "CHESS | Home." http://www.chess.nl/nl/home/Wat-we-doen. Chipknip. (2011). "Chipknip | Home." http://www.chipknip.nl/Pages/default.aspx Retrieved 20-7-

2011. Crowe, M., M. Rysman, et al. (2010). "Mobile Payments at the Retail Point of Sale in the United

States: Prospects for Adoption." Review of Network Economics 9(4). Crowe, M., M. Rysman, et al. (2010). Mobile Payments in the United States at Retail Point of Sale:

Current Market and Future Prospects. F. R. B. o. Boston. 10: 1-39. Currence. (2011). "PIN | Home." http://www.pin.nl/nl-NL/Pages/default.aspx. Currence, DNB, et al. (2008). De overgang op SEPA, Versie 3.5. Currence_1. (2011). "Het Nieuwe Pinnen."

http://www.hetnieuwepinnen.nl/index.php?option=com_content&view=article&id=100%3Aacceptant-fqa-breedband&catid=35&Itemid=57.

DNB (2010). Voorkeuren en gewoontes: Hoe betalen nieuwe Nederlanders in winkels en op afstand? Maatschappelijk Overleg Betalingsverkeer.

DNB, D. N. B.-. (2007). "Statusrapport veiligheid betaalproduct: Incasso."

77

Eisenmann, T., G. Parker, et al. (2006). Strategies for Two-Sided Markets. Harvard Business Review, Harvard Business School Publishing Corporation. 84: 92-101.

Equens. (2011). "Equens SE." http://www.equens.com/. EU (2000). Richtlijn 2000/46/EG van het Europees Parlement en de raad betreffende de toegang tot,

de uitoefening van en het bedrijfseconomisch toezicht op de werkzaamheden van instellingen voor elektronisch geld. 2000/46/EG. E. Union.

Gao, J. Z., L. Prakash, et al. (2007). Understanding 2D-BarCode Technology and Applications in M-Commerce – Design and Implementation of A 2D Barcode Processing Solution. 31st Annual International Computer Software and Applications Conference, Beijing

Garcia-monlina, H., J. D. Ullman, et al. (2000). Database Systems: the Complete Book, Prentice Hall. Garcia-Swartz, D. D., R. W. Hahn, et al. (2006). "The Move Toward a Cashless Society: A Closer Look at

Payment Instrument Economics." Review of Network Economics 5(2): 175-198. Google. (2011). "Google Wallet - make your phone your wallet." http://www.google.com/wallet/

Retrieved 13-7-2011. Google. (2011). "Nexus S - The new Android phone from Google." http://www.google.nl/nexus/

Retrieved 13-7-2011. Gordijn, J. (2002). Value-based Requirements Engineering: Exploring Innovative e-Commerce Ideas.

Faculty of Exact Sciences, VU Amsterdam. Gordijn, J. (2004). e-Business Model Ontologies. e-Business Modelling Using the e3value Ontology.

W. C. (ed.), Elsevier Butterworth-Heinemann, UK: 98-128. Gourville, J. T. and D. Soman (1998). "Payment Depreciation: The Behavioral Effects of Temporally

Separating Payments from Consumption." The Journal of Consumer Research 25(2): 160-174. Henderson, J. C. and N. Venkatraman (1993). "Strategic alignment: leveraging information

technology for transforming organizations." IBM Systems Journal 32(1): 472-484. iDeal. (2011). "Currence | Home; www.currence.nl." Retrieved 5-7-2011. ISO/IEC (2008). ISO/IEC 14443-1. Identification cards -- Contactless integrated circuit cards --

Proximity cards -- Part 1. ISO/IEC (2010). ISO/IEC 21481 Near Field Communication Interface and Protocol -2. Kemppainen, K. (2003). Competition and regulation in European retail payment systems. Bank of

Finland Discussion Papers. 16. Klis, H. (2011). Saldo OV-chipkaart gemakkelijk te manipuleren. NRC.

http://www.nrc.nl/nieuws/2011/01/25/saldo-ov-chipkaart-gemakkelijk-te-manipuleren/. Lauesen, S. (2002). Software Requirements: Styles & Techniques. Lauesen, S. and M. Mathiassen (1999). Use Cases in a COTS Tender. Proceeding of REFSQ'99,

Heidelberg. LOC7000. (2011). "PaySystems by LOC7000." Retrieved 21-03-2011, from

http://www.paysystems.nl/nl/index.html. Luftman, J. (2000). "Assessing Business-IT alignment maturity." Communications of the Association

for Information Systems 4(Article 14). MasterCard. (2011). "MasterCard PayPass | MasterCard." http://www.paypass.com/ Retrieved 14-7-

2011. McCall, J. A. and M. Matsumoto (1980). "Software Quality Metrics Enhancements." Rome Air

Development Center Vol. I-II. McGrath, J. C. (2006). Micropayments: The Final Frontier for Electronic Consumer Payments Payment

Cards Center, Federal Reserve Bank of Philadelphia. Morris, M., M. Schindehutte, et al. (2005). "The entrepreneur's business model: toward a unified

perspective." Journal of Business Research 58(6): 726-735. Mulliner, C. (2009). "Vulnerability Analysis and Attacks on NFC-Enabled Mobile Phones."

International Conference on Availability, Reliability and Security: 695-700. News, N. (2010). "Multicard, Rabobank roll out contactless mobile payment stickers."

http://www.nfcnews.com/2010/08/19/multicard-rabobank-roll-out-contactless-mobile-payment-stickers, 29-10-2011.

78

O'Callaghan, R. (2007). "Fixing the payment system at Alvalade XXI: a case on IT project risk management." Journal of Information Technology 22(4): 399-409.

Ondrus, J. and Y. Pigneur (2009). "Near Field Communication: an assessment for future payment systems." Information Systems and e-Business Management 7(3): 347-361.

Osterwalder, A. (2004). "The Business Model ontology - A Proposition in a design science approach." PhD Thesis University of Lausanne.

Osterwalder, A., Y. Pigneur, et al. (2005). "Clarifying business models: origins, present, and future of the concept." Communications of AIS 16(Article 1).

OV-chipkaart. (2011). "OV-chipkaart - Home; www.ov-chipkaart.nl." Retrieved 5-7-2011. Papp, R. (1999). "Business-IT alignment: productivity paradox payoff?" Industrial Management &

Data Systems 99(8): 367-373. Pateli, A. G. and G. M. Giaglis (2003). A Framework for Understanding and Analysing eBusiness

Models. 16th Bled eCommerce Conference on eTransformation, Bled, Slovania. Patrick, V. M. and C. W. Park (2006). "Paying before consuming: Examining the robustness of

consumers’ preference for prepayment." Journal of Retailing 82(3): 165-175. PayPal. (2011). "Welkom - PayPal." https://www.paypal.com/nl/cgi-

bin/webscr?cmd=_home&country_lang.x=true Retrieved 21-5-2011. Piercy, N. and W. Giles (1993). "Making SWOT Analysis Work." Marketing Intelligence & Planning

7(5/6): 5-7. Plouffe, C. R., M. Vandenbosch, et al. (2000). "Why smart cards have failed: looking to consumer and

merchant reactions to a new paym." International Journal of Bank Marketing 18(3): 112-123. Polasik, M., J. Górka, et al. (2011). "Time Efficiency of Point-Of-Sale Payment Methods: The Empirical

Results for Cash, Cards and Mobile Payments (DO NOT CITE)." Working Paper Series. Porter, M. E. (1979). "How Competitive Forces Shape Strategy." Harvard Business Review 57(2): 137-

145. Porter, M. E. (2001). "Strategy and the Internet." Harvard Business Review 79(2): 63-78. Pousttchi, K., M. Schiessler, et al. (2009). "Proposing a comprehensive framework for analysis and

engineering of mobile payment business models." Information Systems and e-Business Management 7(3): 363-393.

Roberts, J. A. and E. Jones (2001). "Money Attitudes, Credit Card Use, and Compulsive Buying among American College Students." The Journal of Consumer Affairs 35(2): 213-240.

Rochet, J.-C. and J. Tirole (2002). "Cooperation among competitors: some economics of payment card associations." The RAND Journal of Economics 33(4): 549-570.

Shafer, S., H. Smith, et al. (2005). "The power of business models." Business Horizons 48(3): 199-207. Sheenan, N. T. and C. B. Stabell (2007). "Discovering new business models for knowledge intensive

organizations." Strategy & Leadership 35(2): 22-29. Simyo. (2011). "Prepaid bellen - prepaid internet - sim only abonnement - Simyo; www.simyo.nl."

Retrieved 5-7-2011. Sphilberg, D., S. Berez, et al. (2007). "Avoiding the Alignment Trap in Information Technology." MIT

Sloan Management Review 49(1): 51-58. Starbucks. (2011). "Starbucks Card Mobile App." http://www.starbucks.com/coffeehouse/mobile-

apps/starbucks-card-mobile Retrieved 16-7-2011. Stewart, D. W. and Q. Zhao (2000). "Internet Marketing, Business Models, and Public Policy." Journal

of Public Policy & Marketing 19(2): 287-296. Taalwaardig. (2011). "Uitverkocht??" http://www.taalwaardig.nl/?p=911#more-911 Retrieved 12-6-

2011. Teepe, W. G. (2008). "In sneltreinvaart je privacy kwijt." Privacy & Informatie Themanummer

Volgsystemen: 1-14. Van Baal, S. and M. Krueger (2005). "Internet-Zahlungssysteme aus Sicht der Händler." IWW,

Universität Karlsruhe.

79

Van Damme, G., K. M. Wouters, et al. (2009). Offline NFC Payments with Electronic Vouchers. Proceedings of the 1st ACM workshop on Networking, systems, and applications for mobile handhelds, Barcelona, Spain, ACM.

Van der Ven, L. (1996). Succesvol studeren voor BIV/AO: bestuurlijke informatieverzorging administratieve organisatie. Amsterdam, Pentagan.

Weigand, H., P. Johannesson, et al. (2006). On the Notion of Value Object. Proceedings of Advanced Information Systems Engineering: 18th International Conference (CAiE06), Luxembourg.

Wernerfelt, B. (1984). "A Resource-Based View of the Firm." Strategic Management Journal 5(2): 171-180.

WMATA. (2011). "Metro - Fares - SmarTrip." http://www.wmata.com/fares/smartrip/index.cfm Retrieved 12-7-2011.

80

List of tables Table 3.1: Business model element categories ..................................................................................... 26

Table 4.1: Quality Grid ........................................................................................................................... 39

Table 4.2: Goal-domain trace ................................................................................................................ 41

Table 6.1: Performance on maximizing sales ........................................................................................ 56

Table 6.2: Performance on cost reduction ............................................................................................ 57

Table 6.3: Performance on market expansion ...................................................................................... 58

Table 6.4: Overall performance on business goals................................................................................ 59

Table B.1: Value Proposition PaySystems ............................................................................................. 84

Table B.2: Target Customer PaySystems ............................................................................................... 85

Table B.3: Customer Relationship PaySystems ..................................................................................... 86

Table B.4: Distribution Channel PaySystems ......................................................................................... 87

Table B.5: Value Configuration PaySystems .......................................................................................... 89

Table B.6: Capabilities PaySystems ....................................................................................................... 89

Table B.7: Partnerships PaySystems ...................................................................................................... 90

Table B.8: Cost Structure PaySystems ................................................................................................... 91

Table B.9: Revenue model PaySystems ................................................................................................. 91

Table B.10: Financing PaySystems ......................................................................................................... 91

81

List of figures Figure 2.1: QR-Code .............................................................................................................................. 18

Figure 4.1: e3 value model .................................................................................................................... 35

Figure 5.1: Business process real-time payment ................................................................................... 44

Figure 5.2: Business process prepaid payment ..................................................................................... 45

Figure 5.3: Business process postpaid payment ................................................................................... 46

Figure 5.4: Business process automatic reload system ......................................................................... 47

Figure 5.5: Business proces current system .......................................................................................... 48

Figure 5.6: Risk-value matrix ................................................................................................................. 49

Figure 6.1: Component Diagram Real-time system .............................................................................. 51

Figure 6.2: Component Diagram Prepaid system - Balance on central system .................................... 53

Figure 6.3: Component Diagram Prepaid system - Balance on payment tool ...................................... 54

82

Appendix A: Business Model Elements

(Al-Debei and Avison 2010) (Osterwalder 2004) (Shafer, Smith et al. 2005)

Value-proposition Product-service output(offering)

intended-value-element value proposition value proposition

target-segment target customer customer

competitors

strategy

differentiation

mission

Value configuration core-resource resources/assets

value-configuration value configuration processes/activities

core-competency capability capabilities/competencies

Partner-Network actor partnership suppliers

role

relationship

flow-communication

channel

governance

network-mode

Finance total-cost-of-ownership cost structure cost

pricing-method

revenue-structure revenue model revenue/pricing

financial aspects

profit

Customer interface distribution branding

product/service flows

relation customer relationship

customer information

information flows

83

Appendix B: Current Business Model PaySystems

Value Proposition

PaySystems offers a full-service payment solution for purchases made at public events, such as

concerts, festivals and football matches. The system focuses on payment during the event and thus

ticketing is explicitly out-of-scope of the current payment solution. The payments are made at food

and beverage vendors, which are manned retail points-of-sale, and they are mainly small ones:

almost all of them are under €20,- and the majority under €10,-, but each visitor makes multiple

purchases during an event.

The current system is based on plastic payment tokens, which are sold both at manned vending

booths as from automated vending machines, both accepting cash and debit and credit cards. Only

the tokens are accepted at all food and beverage vendors at the event. PaySystems is responsible for

the handling, including sale of the tokens, the processing of the transactions, handling of the cash

and financial reporting afterwards.

The main value proposition of PaySystems is that it offers a reliable payment solution, which is user-

friendly for both visitors of the event as well as for vendors selling at the event, while improving food

and beverage sales and delivering full-service and strict financial control to their customer, the event-

organizer.

This full-service aspect is important to the event-organizers, since there is a lot of planning involved

in deploying the payment solution. Securing and keeping track of the finances is an important aspect

as well, since most events are partly funded from the food and beverage sales. PaySystems operates

at the high-end of the market, meaning that while they are expensive, event-organizers know when

they hire them, that they will take care of everything involving payment and finances, and that it is

done right.

The second important aspect is the improvement in food and beverage sales which is realized by

employing PaySystems’ payment solution instead of cash. Since in most cases food and beverages

revenues are split between the vendors and the event-organizer, it is an important part of the value

proposition for both these stakeholders. This improvement is realized by many factors in the

payment systems. The first of them is upselling: tokens are only sold in multiples of four or five,

depending on the token price, so visitors may buy more tokens than they otherwise would and end

up spending those anyways.

Tokens may also get lost or taken home after the event, in which case the money is already spent,

while no sale of food or beverage has occurred. This effect is called redemption. Further, there is a

psychological aspect: tokens represent some monetary value, but for a visitor at an event it

represents a beer or other drink. In his mind, the sale has already happened, even when tokens can

be exchanged back for cash at the end of the event.

Finally, since the payments of food and beverages at the vendors goes quicker with the PaySystems’

tokens than with cash, the vendors can increase their sales by reduced waiting lines at their sales

points. Faster payment has shown to increase overall sales volume. (Alliance 2004) The increased

transaction speed also allows the vendors to operate more efficiently.

84

PaySystems has little direct competition from other companies which have a similar value

proposition. However, a lot of event-organizers are not interested in a full-service approach, be it

because of financial or other reasons. A prime example of this is the Alvalade-case (O'Callaghan

2007), which operates its own magnetic card-based payment system. Since the only value

proposition of PaySystems right now offers full-service, a large part of the market is out-of-reach.

In Table B.1 the value proposition elements from (Pousttchi, Schiessler et al. 2009) are filled in. The

integration of m-marketing is left empty, since m-marketing is not a consideration in the current

business model of PaySystems. An important element is the ‘Guarantee of Payment’. (Pousttchi,

Schiessler et al. 2009) argues that in a payment system, a guarantee for the payee that he’ll actually

receive the money associated with the payment is an important part of the value proposition. (Van

Baal and Krueger 2005) assert that vendors are willing to pay for this payment guarantee. This

guarantee covers the risk of for instance fraud and defaulting. In the current business model, this is

part of the value proposition of PaySystems, since vendors get paid based on the number of tokens

they receive and organizers by the sales of tokens. When something goes wrong, for instance a

shortage in the cash register, the loss is carried by PaySystems.

Table B.1: Value Proposition PaySystems

(Pousttchi, Schiessler et al. 2009) considers a payment to be a ‘micropayment’ when the amount is

under €10,-. While this is the case in the majority of the payments, a large part falls above this

threshold. However, since the payment method at the point-of-sale is geared towards throughput

and ease-of-use, characteristics associated with micropayments, the payments are regarded as

micropayments. Finally, the Customer2Customer use case type is also considered, since tokens can

and are transferred between visitors of the events, most commonly when someone is getting a

round of drinks for a group.

In Table B.2 the target customer elements from (Pousttchi, Schiessler et al. 2009) are given. The

customers of PaySystems, the event-organizer, can be seen as a reseller of the payment system: they

are not end-users of the system itself, but rather allow merchants and visitors to utilize the system

during the event. The willingness to pay describes how willing the visitors are to use this particular

payment system. In the context of PaySystems, this is very high, since the event-organizer demands

the merchants to only accept tokens as payment and thus the visitors are forced to use the system to

buy food or drinks.

The market segmentation strategy of PaySystems is concentrated: it focuses solely on large-scale

public events and stadiums. There are currently no value propositions which are intended for

85

smaller, fixed locations, such as discotheques or bars. A new system may allow for more flexibility in

this regard.

Table B.2: Target Customer PaySystems

Customer Interface

The customer interface describes how PaySystems delivers its product, or more accurate, value

proposition, to their customers. It discusses all interactions between PaySystems and event-

organizers, from how the they are made aware of PaySystems to how the payment system is

delivered to an event and what type of customer relationship they value. First off, the most

important aspects of the customer relationship will be discussed, then the distribution channel will

be described.

The relationship between PaySystems and its customers can be described as one based on value co-

creation. Value co-creation between a firm and its customers means that the firm actively tries to

help its customers to create and capture as much value as possible, instead of simply delivering a

product or providing a service. (Bhalla 2010) The primary goal of PaySystems is deploying their

payment system at the event and ensuring it runs smoothly and that the financials are handled

correctly. But further, PaySystems is willing to help customers to maximize revenue from food and

beverage sales and improve the visitor experience at events.

PaySystems has single-event deals with many of its customers, but it also strives to make long-term

arrangements with customers. A good example of this are the football stadiums with which

PaySystems has long-term deals, these stadiums include De Kuip in Rotterdam and Phillips Stadium in

Eindhoven, and deals with event-organizers which have many events, such as ID&T.

A further note on the acquisition of customers is the role the other labels of LOC7000, Food and

Beverage (FAB) and Event Management (LEM). First off, event-organizers can easily combine the

services of different labels. The most common example of this is when they hire Food and Beverage

for their catering services, the services of PaySystems as payment provider are sold in combination

deals. Even when the customer only hires PaySystems, it has some indirect access to the expertise of

the other labels via the project manager from PaySystems, who can easily contact employees of FAB

and LEM for help with specific issues.

In Table B.3 the appropriate customer relationship elements of the (Pousttchi, Schiessler et al. 2009)

framework are given. These elements sketch the relation that the payment provider has with

merchants and payers, but it doesn’t describe the contents of the customer relation, especially since

86

neither merchant nor payer is the customer in this case. Acquiring describes how the merchants that

accept the payments are acquired. In this case, that is done by the event-organizer or by FAB, if they

arrange the catering, thus this is an existing business connection. The way that the payer receives the

payment instrument, the tokens in this case, is called issuing. Issuing is the responsibility of

PaySystems, since they sell the tokens. A payment provider is enabling when it doesn’t operate the

payment system itself, but instead enables other companies to perform the operation of the system

in exchange for a licensing fee or rent.

Table B.3: Customer Relationship PaySystems

The channel between PaySystems and its customers can be viewed for all four phases of the

Customer Buying Cycle. (Osterwalder 2004) These phases are: (1) awareness of the value

proposition, (2) evaluation by the customer of the value proposition compared to his needs, (3)

purchase of the value proposition and (4) after sales, such as troubleshooting or updates. How

PaySystems handles the contact with their customers in these phases will be explained here first.

The market of large-scale public events is rather limited in size, so most parties are at least aware of

one another and have a rudimentary understanding of what each of them offers. Awareness of

PaySystems’ offering is mainly created by actively contacting event-organizers and of course by

word-of-mouth between different organizers. A lot of the parties in the market are also actively

looking at events in which they are not involved to come up with new ideas and this is also a way in

which awareness for the payment solution of PaySystems is created.

During the evaluation phase of the buying cycle, the customer tries to gather as much information as

possible on the value proposition of PaySystems and how it fits in with their specific needs and

budget. This is mainly done by an active sales approach, in which PaySystems discusses the

customers’ wishes and their payment system together with the customer. Potential clients are often

invited to attend other events that are serviced by PaySystems to get a behind-the-scenes impression

of the benefits of the payment system.

The purchase includes everything from negotiation of the price and parameters of the service

delivery to the contract with the customer and the fulfillment of the service. Negotiation, decision

and contract are important steps, since there is a lot of money involved in food and beverage sales at

an event and it is a critical part for any event-organizer, both financial and operational. Payment is

handled after the event, most often by subtracting the contract sum from the revenues of the token

sale, which are transferred to the customer. The fulfillment of the service is done in coordination

with the customer, since important aspects, such as power and internet connectivity, are often

arranged by the event-organizer or another third party.

After sales consists of helping the customer to profit from the value proposition, with help such as

manuals, troubleshooting and maintenance. Since PaySystems’ value payment system is deployed

with full-service included, almost all of these aspects are all covered in the fulfillment phase of the

87

buying cycle. The only after sales of note are evaluations, which are conducted with the event-

organizer after the event, in order to improve for next editions of the event.

The (Pousttchi, Schiessler et al. 2009) mobile payment framework captures two elements in addition

to the consumer buying cycle: the branding strategy and the rollout scope of the payment system.

The payment system is branded to the event-organizers under their own brand-name: PaySystems.

Branding to visitors is not actively pursued, since visitors can only use the tokens sold by PaySystems

and thus there is no competition. The payment system is rolled out regionally, since tokens are only

available and usable at the event terrain and during the event. In Table B.4the distribution channel

elements are displayed.

Table B.4: Distribution Channel PaySystems

Value Architecture

The value architecture describes the key resources and activities needed to deliver the value

proposition to the customer, as well as the core capabilities of the organization by which these are

executed. The most important elements for the delivery of the payment solution of PaySystems to

the public events will be described here, as well as the considerations made in the framework for

mobile payment by (Pousttchi, Schiessler et al. 2009).

There are three main phases in the process of providing a payment solution to an event: the planning

and preparation before the events, the operation during the event and the financial handling

afterwards. Each of these phases entails different activities and resources. They will be discussed

briefly here.

There is a lot of planning and preparation that needs to be done before the event, such as the design

and ordering of tokens, planning of tangible and human resources and the ordering of change for the

cash registers. The vast experience of PaySystems allows them to make accurate and complete plans

with a great deal of efficiency. The employees of PaySystems and their expertise are the main

resources in this phase.

During the event, PaySystems is responsible for operating the payment system. This includes the sale

of tokens at both the vending machines and the manned vending booths, the counting and weighing

of the tokens collected by the merchants and the cash distribution and transports. PaySystems also

takes care of the placement of the infrastructure on the event-site, such as placement of the vending

machines and booths and connectivity of the debit card terminals and vending machines.

The most important tangible resources that PaySystems utilizes for the operating of the payment

system are their vending machines and token-dispensers for the manned sales booths, since these

88

are directly related to the sale of the tokens and are unique to PaySystems they are a source of

competitive advantage. Connectivity of the vending machines and debit card terminals is essential to

the operation of the system, so the hardware utilized by PaySystems, such as satellite uplinks and Wi-

Fi connections, is also a key resource.

One of the key human resources which PaySystems employs is the project manager, which oversees

the operation during the event. The project manager has extensive experience at events and is

tasked with ensuring the payment system runs smooth during the entire event from an operational

point-of-view. Service mechanics, who ensure the continuous operation of the vending machines and

the connectivity of the debit card terminals are also important, since they ensure smooth operation

from a technical standpoint.

After the event, the most important task is the handling of financials. This begins with counting and

weighing the tokens which are collected by the merchants and afterwards, when all the money from

the token-sales is received by PaySystems, it needs to be transferred to the event-organizer and

possibly to the merchants. Financial reporting and control is also an important aspect, since it’s an

important part of the value proposition. PaySystems is supported by the financial administration of

LOC7000 in these tasks.

Another important aspect of PaySystems is their reputation. Event-organizers choose PaySystems

because their reliability and an expectation of quality, and they are prepared to pay a high-end price

for this. Should PaySystems lose their reputation as a reliable, high-quality payment solution

provider, there is little incentive for event-organizers to spend money on them. Maintaining a good

reputation is therefore extremely important.

The final aspect of note is the product design capabilities that PaySystems has in-house. Close

business partner Dutchband B.V. and PaySystems developed the current dispensers and vending

machines together and the input of PaySystems remains important today in the continuous

development of the core resources, in both vending machines and internet connectivity.

The value configuration and capability elements from the (Pousttchi, Schiessler et al. 2009) are given

in Table B.5 and Table B.6 below. In the current system, there is no need for the user to register

beforehand. The authentication at the retail point-of-sale is only by possession, meaning that if a

visitor has tokens he can make a transaction. Therefore, no registration of users and their

characteristics is needed. The ‘method of settlement’ can be likened to an e-money account, without

the digital component, in the sense that the bought tokens mimic a pre-paid account.

89

Table B.5: Value Configuration PaySystems

Table B.6: Capabilities PaySystems

PaySystems currently has no banking license, since it operates under an exception from the

regulations. This could become an important issue with a digital payment system, since there may be

other regulations and legislation associated with this.

Value Network

There are two partners of note involved in the creation of the value proposition of PaySystems:

Dutchband and, in the cases where catering is provided by LOC7000 Food and Beverage (FAB), they

can be considered a partner as well. Besides these there are numerous parties involved in the

operation, such as temp agencies for personell of the manned vending booths and rental companies

of various materials, but they are not exclusive to PaySystems and do not help them create a

competitive advantage, while Dutchband and FAB certainly do.

Dutchband B.V. is a company specialized in event solutions and they have a close relation with

PaySystems. First off, they supply the tokens used by PaySystems, so they are one of the most critical

suppliers. But more importantly, they developed the token dispensers for the manned vending

booths and the token vending machines together with PaySystems. They are specialized in the

research and development of these machines, especially in the design. The vending machines are

fully-owned by PaySystems, but Dutchband remains involved in the continuous development of the

payment system. Finally, they supply PaySystems with critical IT-infrastructure for events, such as

sattelite equipment, and they help PaySystems find solutions for IT problems at events. An example

of this is enhancing the robustness of certain off-the-shelf IT equipment to deal with wet and rough

environments. In Table B.7 the partnership with Dutchband is given in the darkest shade.

FAB is another label of LOC7000, which is concerned with organizing food and beverage sales for

event-organizers. They recruit vendors of food and exploit drinks sales themselves. They are

90

considered an important partner of PaySystems, since all FAB deals include the payment solution of

PaySystems. Most often, event-organizers first have a PaySystems deal, which is subsequently

expanded to include FAB. One of the main advantages is that through PaySystems’ earlier

engagement a full financial picture of the food and beverage sales is available for LOC7000. Finally,

via FAB a large merchant base is reached, who work with the payment system of PaySystems. While

these merchants aren’t the customers of PaySystems, they are important stakeholders in the market

and their desires regarding payment and opinions towards PaySystems are important. Maintaining a

good relation with them is of value. FAB is displayed as the lighter shade in Table B.7. While it is only

an intermediary towards merchants, it is nonetheless noted in the merchant category.

Table B.7: Partnerships PaySystems

Finance

This section will describe the financial aspects of the operation of PaySystems’ current payment

system. This description will include the cost structure of PaySystems, the revenue streams they

currently possess and their pricing mechanisms.

(Pousttchi, Schiessler et al. 2009) define five different cost elements for payment systems, they are

given in Table B.8. Set-up costs refer to the costs incurred to enable a company to offer their value

proposition, for example obtaining a banking license. Since PaySystems currently is operating, there

are no set-up costs to consider. Referring back to the section on customer interface, there are little

advertising and promotion costs, since most awareness is created by existing business connections

and word-of-mouth. The main cost pillars are therefore infrastructure and operation.

Infrastructure costs are a substantial part of the total cost structure. The sale of tokens is done either

fully automated by vending machines and/or semi-automated at manned vending booths. There the

sale is supported by both debit/credit card terminals and token-dispensers. While the vending

machines are expensive in purchase, manned vending booths and card terminals need to be rented

from a third party which comes with a cost as well. Still, the infrastructure costs are higher for

vending machines than for manned vending booths. This is counteracted by the fact that there is less

personnel needed for the operation of the vending machines and this reduces the operational costs.

The infrastructural costs are part variable and part fixed costs. All the hired equipment is variable,

91

while the owned equipment has a fixed cost element. These fixed costs are primarily the vending

machines and token dispensers for the manned booths.

The biggest part of the cost structure are the costs of operating the payment system. These

operational costs consist of three primary components: Personnel, transaction and token costs.

Token costs consists of the procurement and disposal costs of the payment tokens. Transaction costs

are incurred when tokens are sold to the visitors, these can be either debit/credit card transaction

costs or the transport and handling of cash when a visitor pays with cash.

The largest part of the operational costs are made by the employment of personnel. The project

manager of PaySystems, with the help from other LOC7000 staff, makes all preparations for the

event, from the design and order of tokens to the personnel planning. During the event there is a

large staff running the payment system: token sellers who man the manned sales booths, mechanics

who fix problems with the vending machines, runners who resupply vending machines and sales

booths with extra tokens or cash and financial and operational staff. As a general rule: when more

vending machines are employed, less personnel is needed, since the manned vending booths are

more labor-intensive.

Table B.8: Cost Structure PaySystems

The revenue stream of PaySystems can be characterized as a usage fee paid by the event-organizer

for the services they deliver. The pricing of this fee is negotiated between PaySystems and the event-

organizer and the price can be either a fixed price, based on the costs incurred by PaySystems and a

mark-up or it can be a transaction-dependent price, in which PaySystems is paid dependent on the

number of tokens sold. See Table B.9 below for the revenue model.

Table B.9: Revenue model PaySystems

(Pousttchi, Schiessler et al. 2009) has adopted financing as an additional element compared to the

business model ontology (Osterwalder 2004). Financing denotes how the operating expenses are

covered, either with borrowed or own (equity) capital. PaySystems currently operates on equity

capital and also owns important assets such as the vending machines.

Table B.10: Financing PaySystems