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
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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: [email protected] 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
Related Documents
