F
UTURE
-P
ROOFING
M-POS:
S
ELECTING
M
OBILE
T
ECHNOLOGY
C
ONTENTS
The Commerce and Payments Landscape Is Rapidly Changing ...3
From Payments to Commerce ...5
Integrating Payments to the Business Process ...7
Cardholder and Merchant Security ... 7
Supporting New Security Features ... 8
Expanding to New Payment Types and Customer Engagement Options ... 9
Implementation and Deployment Models ... 10
Whether to Build or to Buy a Payments Solution ... 12
The Apriva Solution Set ... 13
Conclusion ... 15
Copyright Notice ... 15
The Commerce and Payments Landscape Is Rapidly Changing
Looking at the point of sale (POS) today, it is hard to comprehend how modern POS systems evolved from the mechanical device created by James Ritty in 1871 called “Ritty’s Incorruptible Cashier,” shown at right. Change came slowly. The first 25 years saw the addition of receipts and a motor, which were breakthroughs at the time. But it is not surprising that the pace of change increased dramatically a century after the device’s invention, with the introduction of electronic POS devices in the 1970s.
IBM took a direct approach and developed the electronic cash register (ECR) in the mid-1970s. But when programmable chips hit the market and research and development moved to Taiwan, low-cost cash registers became as common as programmable calculators. In the blink of the eye, the era of the personal computer arrived.
In 1978, Gene Moshel developed the first program for an Apple computer that created a POS system, which he used in his own deli. Moshel began selling his software and enhanced it to add order-entry capability and remote kitchen printing in 1979. He then converted the software to operate on the Atari 520ST, in 1986 launching the first graphical user interface with a color touch-screen. A Microsoft Windows implementation took another seven years to be introduced.
In the PC-based POS, a large part of operational costs was associated with connectivity to the card networks and interconnectivity of multiple-station and multiple-location devices. With the deployment of local area networking (LAN) in the 80s and the Internet in the 90s, the cost of connectivity
dropped essentially to zero because these two technologies were so widely deployed. In essence, the POS terminal for merchants in the small and medium-sized enterprise (SME) class was either a dedicated device (commonly referred to as a brick) or a cash register, similar to those shown to the right. These devices were, and are, purpose built, relatively
expensive, and difficult to upgrade. Typically, only the manufacturer can create and update the software, which makes the addition of new functions costly and time consuming.
New technology has once again changed the environment, lowering the cost and effort associated with creating and deploying software, and is now displacing older POS technology. Following is a description of the new environment:
Ritty’s Incorruptible Cashier
A Dedicated POS “Brick” and a Cash Register Circa 1990s
Payment devices today are always connected.
Mobile phones and tablets have established, low-cost, readily available open platforms.
These operating systems, from Google and Apple, deliver common interfaces to an increasingly broad array of hardware devices, including Global Positioning System (GPS) devices, accelerometers, and a range of Universal Serial Bus (USB) devices.
The volume of mobile devices sold allowed low price points unattainable in proprietary solutions. These new, always connected, operating systems deliver a new easy and low-cost mechanism for
deploying compatible applications and upgrades.
These always-connected open platform payment solutions establish new development environments that reduce the cost of both building and distributing new products and functions. The environments are often called cloud computing and software as a service (SaaS). SaaS has quickly become the leading model for delivering business solutions into the market. SaaS models eliminate upfront costs in favor of monthly or annual usage fees, while cloud computing enables an application to leverage features and functions that are implemented by a third party over the Internet.
POS devices built on the technologies and services described above are far more “future-proof” than previous devices because updates to the operating system and the software applications themselves can be performed over the Internet frequently and at low cost.
These always-connected platforms also enable new customer support options. Instead of restricting users to phone and Web support, mobile apps can provide guided support based on user input and can add text, recorded voice, and even real-time video with remote support similar to Amazon’s Mayday function.
These capabilities have fundamentally changed the POS market. The point-of-sale device built on this
infrastructure is often called an m-POS, with the “m” representing the “mobile platform.” The m-POS market has changed the POS market in four fundamental ways:
Mobile platforms, which include smartphones and tablets, are rapidly becoming the POS devices preferred by small and midsize businesses.
Payments as an Internet service enables a broad number of new payment types to be made available at the POS. Besides national card networks, international card networks, and currency conversion
capabilities, it may also support paper check acceptance, gift cards, and electronic benefit transfer (EBT) cards (e.g., SNAP or food stamps). Also to be considered are the latest digital currencies (such as Bitcoin) and loyalty/incentive cards.
The environment described above has enabled the easy and low-cost introduction of a much broader array of value-added services that are integrated to the payment transaction. Among these are loyalty programs, inventory management solutions, payroll, incentive solutions, and a wide range of other applications, all delivered via the Internet as cloud-based services.
Cloud computing enables the data generated at the POS to be aggregated and analyzed at low cost and with minimal local resources, with the results returned to the mobile platform in real time.
In short, mobile networks, cloud computing, and application connectivity, implemented on low-cost and more capable mobile platforms, have driven a new era of payments innovation and will continue to do so throughout this decade and the next.
It is important to recognize that the existing card acceptance model is also evolving rapidly and will require new hardware and software in the near term. The traditional card networks are undergoing significant technological change that will raise the stakes regarding the future of payment acceptance. Several payment technologies— EMV, Near Field Communication (NFC), Merchant Customer Exchange (MCX), and tokenization—are all being rolled out over the next few years. Implementing these technologies in a way that will not demand
re-architecting existing hardware and software will require much forethought. With the introduction of Apple Pay, it is clear that these are short-term decisions, not long term.
The goal of this Mercator Advisory Group research brief is to help software business and development managers better understand how payments operate today, how the traditional card payment infrastructure is evolving, and how to address this evolution within the business’s architecture to ensure the development effort will withstand the test of time. To do this, it is important to understand how payments have become an intrinsic part of the larger ecosystem typically described as commerce, which involves delivering solutions that engage the consumer early, encourage purchases, and keeps the consumer engaged after the purchase. Offering just a payments platform is no longer sufficient for small and midsize businesses.
From Payments to Commerce
The transition of the point-of-sale device from a payment mechanism to a commerce solution began with those companies that have a large number of field representatives, including sales and customer service. Initially the mobile solutions allowed those representatives to accept a payment, but it didn’t take long for firms to recognize that the mobile device could also manage the entire customer engagement, from planning, scheduling, and reporting, to the payment itself. This approach quickly grew beyond the mobile field force. Today small and midsize merchants, companies that have small offices distributed across a large geography, and any business that would like its employees to be in front of the customer instead of behind a cash register, have all begun to adopt tablets and custom-built mobile devices for their employees.
No doubt the primary drivers of this adoption are the low cost associated with purchasing and deploying mobile devices, combined with the efficiencies the devices can create. Mobile tablets cost significantly less then custom devices, and the vast majority of people already know how to work with these devices’ mobile operating systems—after all, these devices are already in people’s pockets and homes. In addition, these mobile devices have a unique set of technologies that enable the device to better integrate with the environment and they provide information, identified below, that the application environment can utilize to establish context and eliminate key entry.
Geofencing can improve employee utilization and track location. The cameras can be used to take a picture for the records or take a picture of a driver’s license for identification purposes or simply to enter name and address fields without the need to key in the information. Voice recognition as a key-entry device is also available as a standard part of the operating system. In short, these mobile devices have a greater range of technologies for sensing the environment. Their operating systems have exposed many of these sensors as high-level application programming interfaces (APIs) that greatly improve the capability of any application deployed in the mobile device. All of this capability is available at a price point far below that of a PC. All of the software, from the operating system to the apps on the device, can be automatically updated, enabling a much easier upgrade path for the user and greatly lowering software deployment costs, as the upgrade leverages the connectivity inherent in the mobile device and the upgrade features built into the operating system. Based on these benefits, it comes as little surprise that the payments industry is adopting these new low-cost platforms quickly. From Apriva to World Pay, mobile handsets became the low-cost and high-impact mechanism for taking a payment. For the first time, payment acceptance has become primarily a software function. Although hardware is still needed to read the customer’s payment card, everything else can be accomplished in software.
Apple demonstrated the power of this approach when it designed its retail experience for Apple Stores that utilized the iPad, enabling sales reps to engage the customer as they demo the Apple products and then take the order and the payment without sending the customer to the POS. Initially, this solution had minimal integration into other back-end systems that Apple operates, but it was the proof of concept that
demonstrated the benefits of engaging the customer and reducing the friction associated with lines at the cash register. As a result of Apple’s success, there has been a rush to redesign business processes and to integrate payments into an ever greater number of vertical and horizontal markets. And so these mobile devices have become the cornerstone in the development of integrated payments.
Integrating Payments to the Business Process
To the uninitiated, accepting a card with a swipe may appear simple, but there are three areas that add significant complexity to this apparently simple act.
First is the need to meet existing security standards of the PCI Security Standards Council and cardholder security standards that control the risk a merchant will be exposed to if card fraud occurs. The latter is associated with card processing networks’ liability rules, which are in turn tied to the hardware and software environment of the POS implementation. Second is the larger process of accepting a payment, which often includes storing transaction details, delivering a receipt compliant with government and network standards, and enabling returns and credits against past transactions. Add to this second issue the ability to recognize recurring transactions from the same cardholder or maintain a card on file so it can be used the next time without requesting the card information, and the process can become devilishly complicated. Last is the necessity to accept multiple payment types and deliver customer engagement utilizing loyalty programs, acceptance of incentive offers, and perhaps gift card sales and acceptance.
Because it is relatively intuitive that adding more solutions to the payment transaction will also increase complexity, this report next describes how the first two issues—PCI compliance and enabling the acceptance of new payment processes—add to the challenges of creating an software architecture that will stand the test of time.
Cardholder and Merchant Security
The card networks in the United States (MasterCard, Visa, Discover, American Express, et al.) require that all POS implementations protect cardholder data. Initially this was accomplished by requiring all card acceptance implementations to meet or exceed the PCI standard. Although PCI standards remain in effect, the networks have more recently decided to promote the more secure EMV “chip and PIN” standard (which requires a card reader that accepts cards with embedded EMV chip and PIN device for cardholder to enter personal
identification number, or PIN, to verify the cardholder). The networks did this by declaring a “liability shift” date, scheduled for October 1, 2015. After that date, any merchant that does not accept an EMV-capable card as an EMV transaction, or that deliberately processes an EMV card as a magnetic-stripe card, will be required to absorb the liability related to any fraud that results. If a criminal gains access to the card data (from the card’s magnetic stripe) and conducts a counterfeit payment transaction, the merchant of record will be required to pay the issuing bank for any loss that results and also underwrite the reissuance of a new card to the affected consumer. These costs could easily bankrupt a small business if many cards were affected.
While EMV encrypts data transferred to the POS, some POS implementations fail to keep the data encrypted within the mobile POS or even over the wire to the acquirer, instead relying on a virtual private network (VPN) or other encryption. This is significantly less secure than end-to-end encryption, which keeps the card data encrypted from the card reader all the way to the payment processor or acquirer. When data remains
encrypted, the payment processor returns to the merchant a token that represents that transaction, without a card number, for the receipt and to support local processing and credits (see more below). For a merchant selecting a payment processor, it is therefore important to determine if any card data is in the clear within the mobile payment app or in the authorization request sent to the issuing bank. The answer should be no, it is not, and the payment processor should be able to describe exactly how that data is protected.
Implementing EMV acceptance requires new hardware in the mobile device, the ability to securely accept the consumer’s PIN data, several new data elements in the authorization transaction, as well as the ability to accept and respond to several new error codes and responses. Clearly it is in a developer’s best interests to select a payment partner that can make this transition to EMV acceptance as effortless as possible and in a way that keeps the data encrypted until it is out of the merchant’s environment. Otherwise, the merchant of record will be responsible for a full PCI compliance audit, an expense very much worth avoiding through careful planning. It is imperative that the payment partner demonstrate thorough knowledge regarding security and have a history of strong network and acquirer compliance.
Supporting New Security Features
The recently launched Apple Pay mobile payments solution introduced advanced security features. Apple Pay is the first implementation of the new network security feature being deployed worldwide called tokenization. Whereas EMV encrypts the card number to protect cardholder data, tokenization completely replaces the card number with a network-created “token” a sequence of numbers that is impossible for a criminal to relate back to a card number. The token ensures that any data stored by the merchant of record can’t possibly include the card number. This eliminates thieves’ ability to steal card data and create counterfeit cards. It will take decades before the majority of payment transactions involve tokens, but it remains imperative that the payments partner selected support Near Field Communications (NFC) hardware and software today if the merchant intends to accept Apple Pay, Google Wallet, or Softcard implementations at the POS as well as all other NFC-based card transactions that will soon enter the market. Supporting NFC and tokens requires that the payment solution provider support the NFC hardware and support new fields in the authorization request sent to the acquirer. Recognizing that each acquirer will have a separate certification process for accepting, transmitting, and managing tokenized card transactions, a payment provider should confirm that it intends to support these new security features with the acquirer chosen by the merchant.
Expanding to New Payment Types and Customer Engagement Options
After establishing the basic payment acceptance at the POS described above, some merchants will want to be able accept new payment types. Following are just a few of the payment types that may be of interest to the merchant of record:
• Physical checks
• Split ticket payment, which is a single payment made with multiple payment instruments (e.g., cash and card, or two different cards)
• A card-on-file solution, which eliminates the need for a customer to present the card for every purchase • A recurring payment performed at some set time interval
• EBT cards
• Direct debit, which utilizes the ACH network to reduce costs
• Acceptance of international cards not supported by the traditional U.S. networks; currency conversion to support international customers
• Gift cards
• New alternative payments such as bitcoin
For every new payment type, a new process at the POS is required to select that payment type and collect and protect the payment credentials the consumer provides, and of course the back-end system must be able to support and manage that particular payment type. Each payment type will fall under a specific regulatory construct for consumer opt-in, the acceptance of the payment credential, and in some instances consumer protections around disputes and charge-backs.
It is also likely that the merchant will become aware of different loyalty, coupons/incentives, and prepaid solutions currently available in market and will be interested in adding these value-added services to the existing payment function. By integrating to the existing payment functions, these services and the payment itself can be executed with a single swipe or tap of the customer’s credential and all of the data can be consolidated so that analytics can track performance of the program.
Coupons and incentives might be tied to a one-time use or require some specific purchase pattern before being redeemed. These offers might be made directly to the consumer by the merchant or distributed through affiliates or partners, and the management function should support reporting on how these partners perform related to offers distributed, redeemed, and measure the associated increase of in-store or Web-based traffic. These capabilities require the collection of new data and the implementation of a new and more complex business process at the point of sale.
effort. It is also important to understand if this intensive database and analytic computing will be performed in the mobile device or in the cloud. Merchants’ opinions differ regarding the benefits or drawbacks of cloud computing, but the fact remains that mobile devices are performance constrained and as processing needs increase, offloading the mobile device is necessary to maintain a fast and convenient purchase experience for the customer.
Implementation and Deployment Models
With the payments of tomorrow being in flux, the challenge is to leverage the power of the mobile handset’s connectivity and its easy and reliable method for updating software, to future-proof the payments solution. Doing this requires deciding on the implementation that will best meet your needs for product distribution and business logic integration. The vast majority of m-POS devices deployed today are smartphone or tablet based and connected via Internet directly to an acquirer that charges a per-transaction fee. In this scenario, the acquirer is responsible for all aspects of the payment product and all value-added services that may be
associated with those payment apps. This scenario is identified at the center of Figure 1. Because the acquirer is also delivering all of the m-POS functionality, the “cloud provider” in Figure 1 is also executed by the acquirer and there is likely no need to expose the payment software via an API, all functions being self-contained.
Figure 1: Implementation Methods to Integrate Business Logic and Payments
Source: Mercator Advisory Group
Internet
Provider
Cloud
Acquirer 1
Business
Logic
Acquirer N
Central Host-Driven
Business Logic
M-POS Driven
Architecture
Business
Logic
Business
Logic
Internet
API API API Basic CardAPI Services
If any business logic is needed in the mobile device that can integrate to the payment process, it must be integrated using APIs provided by the acquirer. Such business logic should likely be kept to the minimum. While mobile devices have a very robust operating environment, the fact remains that they have limited processing power, memory, and storage space.
More complex integrations are likely better suited to a Central Host Driven Business Logic environment (shown on the left side of Figure 1). This is a more complex environment because the business logic can be divided between the mobile device, the host, and the cloud provider. A likely scenario is that the host logic controls the process until the payment is conducted. At that point, the host will initiate the payment on the mobile device. The mobile device then processes the payment and communicates the payment details using end-to-end encryption to the cloud provider. The host has access to device management and the transactional data using its own APIs, which interact with the cloud provider’s platform. In either scenario, the API provided will have a significant impact on the success of the solution.
The services the API may offer the programmer are shown on the bottom right-hand side of Figure 1. In the center is the minimal control over a basic card swipe. This basic API could control payments that include split tender, EBT, and gift card acceptance in a way that is relatively transparent to the business application. The next layer has support for emerging card types, which includes card operations that are more complex, such as registration of a card on file that requires documentation that the consumer requested the relationship, gift card purchase and load functions, and any other card functions that require a complex interaction between the business process and the payment service. The third layer out includes those APIs that relate to noncard payment products, including checks, ACH, and digital currencies, each of which may have its own unique process typically driven by regulatory issues. The last layer of APIs can access data and control services other than payment that are also available from the supplier, such as incentive or loyalty programs, scheduling systems, payroll, inventory management, or any other value-added capability.
In all cases, the goal should be to minimize the payments footprint in the mobile device to reduce
dependencies and minimize performance problems. As long as the API calls the payment app and the payment app controls all aspects of the transaction, then updating the payments software is relatively independent of the payment module. The more the business logic tries to micromanage the payment, the more difficult it will be to update that payment module without having a negative effect on the business logic.
The payment software in the mobile device has two distinct functions. One is to reliably and securely accept the consumer credentials and move those credentials as an authorization request to the appropriate back end for approval. The second function is to interact with the consumer to collect the information needed for creating the authorization request, communicating the results of the payment request, and providing the consumer a receipt, all of which must meet the requirements of the payment network selected.
The mobile payment footprint will interface to the hardware that enables the payment, perhaps a mag-stripe reader or NFC device, but may also utilize the camera for check acceptance or for collecting identification. This software should protect the payment information with encryption, preferably in the card reader, so that PCI compliance in the handset is minimized. Once the payment transaction is passed to the payment processor in its encrypted form, the processor is responsible for the PCI compliance issues associated with delivering that card transaction to the customer’s acquirer of choice.
But the transaction information must be returned to the mobile handset so that it can print a receipt, and the information must be stored so that an inquiry regarding the transaction can be accommodated or a credit back to the card accomplished. This should be enabled using a mechanism that eliminates card data from the process. The payment service provider will typically accomplish this by passing stand-in data that replaces the card number, typically providing a number that includes only the last four digits of the original card number for printing on the receipt and stored in the host environment with no PCI risk.
Whether to Build or to Buy a Payments Solution
If after reading all of the above you are considering developing your own payment software for your company, then this research brief has failed to convey the complexity involved in payments. Writing payment software is not a typical software effort. Visa Operating Rules Volume 1 (dated 2006) is 840 pages long. Volume 2 is 362 pages. The Visa Interlink regulations are 156 pages long, and the Visa 3d Secure Merchant Implementation Guide is 98 pages. These regulations and specifications do not include the documents that define support for EMV or NFC. Now multiply the above documents times each network (which has its own operating documents and certification process), including American Express, MasterCard, NYCE, STAR, and every other network that supports the cards you intend to accept, to understand the full scale of implementing this on your own. Even if you did make it through all these obstacles, recognize that each acquirer has its own implementation and certification process.
And another note of caution: Should you be successful and get sufficient volume to get the attention of banking regulators, your business could be considered a critical component of the payment system, which means that the bank regulators can audit your operations at will. Fail this audit and your business will be shut down. Mercator Advisory Group has supported several start-ups in the payment space, but most typically the start-ups are not starting from scratch; they select a payment partner that provides the base code that addresses the issues described in this report, and we recommend you do the same.
The Apriva Solution Set
Looking at how a current solution in the market addresses the issues addressed in above will provide clarity regarding the recommended evaluation process. In this research brief, we evaluate the solution from Apriva because of its unique architecture and feature set. The company’s products have been in market since 1999 and represent one of the first payment solutions available for RIM that combined a third-party magnetic card reader with the enabling payment software and services.
Perhaps the first area to consider is how aggressively the partner manages the security and regulatory aspects of the payment implementation the merchant plans to adopt. This is not a simple check-list item. It is
important to dive deep into this area because the potential liability cost associated with failure could easily put a small company out of business and severely damage the reputation of even a major brand. Apriva operates a secure messaging service tested and verified by the U.S. intelligence community, the U.S.
Department of Defense, Visa, MasterCard, and the PCI Security Standards Council. The encryption technology used by the Apriva Messaging Gateway is used by the U.S. government to protect classified information and has been vetted and tested on a regular basis. Apriva also uses this technology to secure payment
information. In 1999 the company was one of the first to introduce a third-party card reader for the RIM platform. Today it supports eight different card readers, each of which delivers end-to-end encryption to assure a minimal PCI certification effort.
On the regulatory front, Apriva supports three of the top banks in the United States and is highly focused on meeting and exceeding the regulatory requirements associated with operating a POS. As an example of the advanced support it offers, the company announced support in AprivaPay Plus for the American Disabilities Act (ADA), an often overlooked government regulation. In fact, the ATM industry fell behind in its adherence to the ADA, which resulted in several large lawsuits. Apriva has extensive capabilities for certification with networks and acquirers and is certified on every major card network and with 35 acquirers.
On the API front, Apriva clearly has a long history of supporting its APIs across multiple platforms and lists support today for Android, iOS, Linux, and Microsoft Windows. What is more interesting is that Apriva also offers integration not only on the mobile platform but also to its cloud implementation. This capability offers developers a much wider range of solutions, especially when implementing a three-tier architecture. For example, the payment API can be embedded in the mobile solution, which therefore provides end-to-end encryption to the Apriva cloud, but the information associated with that transaction, sans card number, can easily be accessed by the business logic in tier 2 so that the all processes are aware of the transaction and capable of taking action on it.
The solution fits the business models of carriers, acquirers, independent service organizations, or independent software organizations. The Apriva Message Gateway supports 35 different acquirers or can be locked to just
almost certainly support it. The proof of this is in part the existing Apriva customer base, which includes 1,000 merchant services providers (MSPs) and independent sales organizations across the United States and Canada. Another valuable attribute of the solution is that it is independent or agnostic to the acquirer selected. Because the Apriva Message Switch is in the cloud receiving all payment transactions from the Apriva payment end points, the end points become highly independent of the acquirer selected. Even if you are the acquirer or an independent sales organization, this architecture delivers benefits in that it increases the ability to shield end-user mobile devices from changes made to the acquiring network protocol or process. While large changes, such as support for EMV and NFC, will certainly require changes in the mobile environment, it might be possible to prevent smaller changes, such as the addition of an extra field for tokens, from impacting the mobile device.
With regulatory support and business models resolved, the next issue to consider is support for the evolving payment types. As already described, the networks are driving the market to accept EMV, NFC, and tokens, all of which are required to support Apple Pay. Then of course there are the non-card-based payments, which include ACH, checks, EBT, gift cards, and digital currency. Apriva can process credit, debit, check, EBT, and closed-loop gift card transactions available across more than 35 different processors in North America and also will accept digital currencies including bitcoin.
Reliability is also a critical consideration. Mobile networks are notorious for dropouts and blind spots. The technology called AprivaTalk delivers reliable transaction processing using two fully redundant data centers in different geographic locations. End-to-end security envelopes protect financial information transmitted over public networks. Intelligent fault recovery is built into the software with store-and-forward logic in case the network goes down temporarily, and coverage-sensing technology safeguards transaction integrity. The same technologies that the U.S. Department of Defense relies on for data communications are embedded in the Apriva solution set.
The last area to consider is future-proofing the solution with value-added services such as loyalty and reward programs and incentives. Apriva has introduced AprivaLife, which merchants can access through a simple online portal to control the creation, management, and delivery of relevant offers, promotions, and reward programs through the mobile device. All customer information and program offerings are securely stored in Apriva cloud and delivered direct to the consumer’s handset. Using the portal, merchants can manage and view all mobile commerce activities, including total daily sales receipts and transaction history, from either a mobile device or a desktop computer.
Conclusion
Payments are extremely complex, rapidly changing, and highly regulated. Integrating payments into the business process to improve the consumer experience is critical—witness the success of Starbucks’ mobile payment app. Developing an engaging environment for the consumer which utilizes the complex and rapidly changing payments technology requires the right payment supplier, not just to enable the development environment but also to protect those accepting payments from the liability that is part and parcel of the highly regulated payment environment. This research brief has highlighted many of the most important areas to be considered, but of course each company’s unique business model and software architecture will have a major impact on the choice of payment supplier. Don’t be fooled by low-cost offers that, given the complexity described here, are simply too good to be true. There are very real costs associated with regulatory
compliance, acquirer certification, network certification for new network products, and of course payment-related security. Recent history shows how clever and persistent hackers can be. Every merchant must stay alert to potential intrusion in its systems, and the company’s payment partner must epitomize the tightly managed and controlled environment seen in banks and government agencies. Anything less will cost far more in the long run.
Copyright Notice
External publication terms for Mercator Advisory Group information and data: Any Mercator Advisory Group information that is to be used in advertising, press releases, or promotional materials requires prior written approval from the appropriate Mercator Advisory Group research director. A draft of the proposed document should accompany any such request. Mercator Advisory Group reserves the right to deny approval of external usage for any reason.
Copyright 2014, Mercator Advisory Group, Inc. Reproduction without written permission is completely forbidden.
About Mercator Advisory Group
Mercator Advisory Group is the leading independent research and advisory services firm exclusively focused on the payments and banking industries. We deliver pragmatic and timely research and advice designed to help our clients uncover the most lucrative opportunities to maximize revenue growth and contain costs. Our clients range from the world's largest payment issuers, acquirers, processors, merchants and associations to leading technology providers and investors. Services include Banking Channels, Credit, Commercial and Enterprise Payments, Debit, Emerging Technologies, International, and Prepaid practices, which provide research documents and advice; CustomerMonitor Survey Series, which report and analyze primary data collected in our biannual consumer surveys; and Consulting Services, which enable clients to gain actionable insights, implement more effective strategies, and accelerate go-to-market plans; offerings include tailored project-based expertise, customized primary research, go-to-go-to-market collateral, market sizing, competitive intelligence, and payments industry training. Mercator Advisory Group is also
