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

Master Thesis Title: Date: Author: Student number: E-mail: Institution: Faculty: Master:

Electronic retail payments at public events: An exploratory study into the feasibility of various electronic payment systems at public events September 23th, 2011 Merijn N.S. Boot 0091006 [email protected] University of Twente, Enschede, The Netherlands School of Management and Governance 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: Institution: Faculty: Research group:

Dr. N. (Klaas) Sikkel University of Twente, Enschede, The Netherlands Faculty of Electrical Engineering, Mathematics and Computer Science Information Systems

External Supervisor Supervisor: R. (Roland) Wassink Company: LOC7000 1

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

2

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 3

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

4

Table of Contents Acknowledgements ................................................................................................................................. 2 Management summary ........................................................................................................................... 3 1

Introduction ..................................................................................................................................... 8 1.1

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

1.1.1

2

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

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

3

Scope ............................................................................................................................. 10

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

2.3.1

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

2.3.2

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

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 5

3.2.4

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

3.2.5

Finance .......................................................................................................................... 30

3.3 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 5

6

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

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

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

6

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

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

6.4

6.4.1

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

6.4.2

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

6.5

7

8

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

Conclusion ............................................................................................................................. 67

6.5.1

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

6.5.2

Advice ............................................................................................................................ 68

6.5.3

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

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

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

7

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

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

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, highlevel 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 10

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.

11

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

12

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.

13

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 eventorganizer. 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. 14

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 banktransaction, 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 quasi15

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-tocustomer 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. 16

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

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) Figure 2.1: QR-Code

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

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.

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)

19

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.

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.

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 20

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 21

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.

22

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 23

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 24

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

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; AlDebei 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 Value proposition Value-proposition Value architecture Value-architecture Value network Value-network Finance Value-finance Customer interface Value-proposition

Osterwalder, 2004 Value proposition Infrastructure management Infrastructure management Financial aspects Customer interface

Shafer et al., 2005 Strategic choices Create value Value network Capture value 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 26

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 27

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 eventorganizer, 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.

28

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-ofsale, 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.

29

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 30

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

Looking for alternative digital payment systems, which is done in this thesis, is another step in this direction.

32

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 33

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

34

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.

35

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

36

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 eventorganizer, 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 37

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

4. Transfer money organizers/vendor

Automatic generation with information from subtask 2; leave it the responsibility of vendors/organizers to

event- 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 38

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.

Transition Revision

Operation

Quality Factors payment system

for Critical

Important

Integrity/security

x

Correctness

x

Reliability/availability

x x

Testability

x x

Portability Interoperability Reusability

Ignore

x

Maintainability Flexibility

Unimportant

x

Usability Efficiency

As usual

x x

x

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

39

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

40

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

G1: Maximize Sales G2: Minimize operational costs G3: Expand to other venues G4: High visitor satisfaction G1: Maximize Sales G2: Minimize operational costs G3: Expand to other venues G4: High visitor satisfaction

T1 x x x x Q9 x

x

T2 x x

Q1

Q2

Q3

Q4 x

Q5

Q6

Q7 x

Q8

x x

x x X Q10 Q11 Q12 Q13 Q14 Q15 Q16 Q17 Q18 x x x x x x x x x x x x x x x

Table 4.2: Goal-domain trace

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 41

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.

42

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

43

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 44

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 realtime 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 45

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 pointof-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 46

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

47

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

48

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.

49

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 50

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.

51

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

52

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 eyecatching 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

53

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-ofsale 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 54

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-ofsale 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)

55

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)

Real-time Prepaid Current

Redemption o +

Up selling o +

Ease of use + -

Budgeting + -

Sense money + +

of

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.

56

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.

Real-time Prepaid Current

Transaction -o o

Personnel ++ ++ o

Token ++ 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 57

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.

Real-time Prepaid Current

Operation ++ + o

Visitor attitudes ++ 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 eventorganizers 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 58

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.

Real-time Prepaid Current

Maximize sales o o +

Cost reduction + + o

Market expansion ++ +/o +/o

Visitor satisfaction ++ + 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.

59

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 pointof-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 60

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

61

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 realtime or prepaid, so this part of the system, PaySystems can design an input system which is easy-touse 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 62

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 63

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 point64

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.

65

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 Emoney 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 pointof-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.

66

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 eventorganizers. 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 67

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.

68

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 eventorganizers. 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. Eventorganizers 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,

69

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 70

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

71

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 72

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 OVChipkaart 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

73

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 besteffort 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. 74

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.

75

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-72011. 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%3A acceptant-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."

76

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 MCommerce – 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-72011. 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-mobilepayment-stickers, 29-10-2011. 77

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/cgibin/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): 137145. 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/mobileapps/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-62011. 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.

78

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): 171180. WMATA. (2011). "Metro - Fares - SmarTrip." http://www.wmata.com/fares/smartrip/index.cfm Retrieved 12-7-2011.

79

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

80

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

81

Appendix A: Business Model Elements Value-proposition

(Al-Debei and Avison 2010) (Osterwalder 2004) Product-service intended-value-element value proposition target-segment target customer

Value configuration core-resource value-configuration core-competency Partner-Network actor role relationship flow-communication channel governance network-mode Finance total-cost-of-ownership pricing-method revenue-structure

Customer interface

value configuration capability partnership

(Shafer, Smith et al. 2005) output(offering) value proposition customer competitors strategy differentiation mission resources/assets processes/activities capabilities/competencies suppliers

cost structure

cost

revenue model

revenue/pricing financial aspects profit branding product/service flows customer relationship customer information information flows

distribution relation

82

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 userfriendly 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 eventorganizer. 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.

83

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 84

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 eventorganizers, 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 cocreation. 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 85

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 86

buying cycle. The only after sales of note are evaluations, which are conducted with the eventorganizer 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 87

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

88

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 89

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,

90

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 eventorganizer 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

91