Point of Sale Overview

Adyen offers an end-to-end POS solution that includes acquiring, terminal sales and support, and payment services. The Adyen POS solution is an integral part of our omni-channel solution. All reporting, reconciliation and notification are the same across different channels.

Adyen offers multiple ways for merchants to accept POS payments, see types of integrations, transaction flows, and POS terminology for detailed information.

We offer full integration with C LibraryC LIbrary COM extension, Java Native Interface, Android and iOS integrations. Download our integrations from the Adyen Customer Area (CA). See our Developer Manuals for instructions on how to integrate.

Review terminal user guides in our User Manuals section.

Types of integrations

Adyen provides various types of integration according to your requirements:

Standalone

The most basic system configuration for accepting payments, with a payment terminal only. The payment terminal accepts all major credit and debit cards and connects over the internet. Transactions are initiated directly on the payment terminal.
Adyen Customer Area (CA) gives access to comprehensive reporting functionality and easy-to-use interface. The Customer Area gives access to the merchant accounts, financial data and payment terminals' properties and products. The POS terminal fleet manager allows for remote control of payment terminal properties.

The stand-alone package contains:

  • Hardware (payment terminal) and user manuals.
  • Access to the Adyen's Customer Area.
  • Setup of merchant data and accounts, setup of terminal properties and products.

Library Integration

Library Integration enables businesses with in-house development of software and apps to be integrated with Adyen's payment platform. By integrating with Adyen's library, you can fully customise Adyen's POS solution to your specific needs.
The following libraries are available:

The library integration requires extensive development effort from the integrator of the POS solution. The minimal set of methods that must be implemented includes:

  • Register application
  • Register payment device
  • Initiate sale transaction
  • Refunds

Each method implements several callbacks which provide information to the cash register or to get additional info from the attendant.

As well as the basic package (hardware, access to the Adyen Customer Area (CA) and setup of merchant accounts and information), a Library integration also includes:

  • Software packages available in the customer area.
  • Documentation.
  • Integration code examples.

Advanced library integration

Besides sale transactions, refund, and reporting functionality, additional features include:

  • Card based shopper recognition.
  • Including price adjustment during transactions.
  • Cross-channel refunds.
  • Cross-channel tokenised card payments with stored data for quick checkouts and recurring payments.

The advanced library integration is an extension of the previously described library integration. Each option requires additional development effort on your back-end.

Transaction flows

Sale

This flow is used to accept a normal payment.

Sale with Digital Customer Recognition

This flow can be used in case loyal customers as recognized based on card number will get the discount. It can also be used for upselling with a use of customer recognition.


EMV Refund

EMV (with data / unreferenced)

This flow is used in case a refund needs to be performed and it cannot be tied to the original payment for example in the case of returned christmas gifts or during the change of providers.

Referenced (partial) refund

This flow should be used in case a receipt is available and the refund can be initiated by the merchant backend.

Referenced (partial) refund without receipt

This can be used in case the customer returns the goods but no longer has a receipt so you can look up the original payment and refund the return goods. This can also be a partial amount in case not everything is returned by the shopper and also be used across channels so in case the goods were purchased online and then brought back to the store.

Authorisation with manual(partial) capture

In case the goods are not available in store this flow can be used with the (partial) capture occurring upon goods being sent out from the fulfillment centers. One example of this would be in store kiosks connected to the website of the merchant.

Referenced full refund (SME fallback)

If you do not have backend implementation for order and transaction management, this library offers the ability to perform a full refund. Only the PSP reference is required as a parameter.

POS terminal fleet management (POSTFM)

The terminal fleet management (TFM) system is a web-based solution used for facilitating, monitoring and controlling the distribution of products in a terminal.

It allows users to view and edit the configuration of their terminals from anywhere. Adyen's terminal fleet management system is accessible via Adyen Customer Area (CA). In this sub system you can view all registered POS and PEDs. Each user with POSTFM access can view, and depending on roles and permissions, edit a subset of the terminal configuration for a group of terminals or individual terminals. This system also provides the functionality to track PEDs to conform to the new PCI P2PE requirements.

You can configure the following:

  • About: Model, serial number, firmware version, system logs
  • Locale: Country code, language, and time zone
  • Display logo on screen
  • Maximum and minimum amounts that can be processed
  • Supported card brands and currencies
  • Dynamic Currency Conversion (DCC)
  • Gratuity
  • Contactless and Manual Key Entry abilities
  • Signature: if needed, accepted on paper receipt or screen
  • Receipt: header, footer, and print properties
  • Online/offline transaction properties
  • Standalone terminal: ability to perform transactions without an external cash register or device

Contact support for further information on terminal fleet management.

POS Terminology

This section explains terminology used throughout the documentation.

General POS Terminology

Term Description
POS Point Of Service/Point Of Sale. Used to describe anything from the Cash Register to the Payment terminal and all possible combinations of both. For Card Schemes, the Shopper Interaction type is always a Card Present transaction. Adyen uses specific terms to avoid confusion.
Cash Register An application that allows product selection and which computes the total amount to be charged to the card holder. Additional functionality may include loyalty handling, stock keeping interface etc. The application can run on a physical machine or can be hosted in combination with an interface for the staff or shopper for kiosks. The Cash Register will communicate with the Adyen library or App interface to initiate payments.
Tender

The process where the staff gathers the desired goods (and/or services) with their prices and computes the total. This total is then relayed to the cardholder to pay. In the context of digital payments and terminals, the tender is the entire process for the POS to start the transaction, receive card information, make optional changes to the amount, await authorization, print the receipt and receive a final status. This entire process is accompanied by a reference for the tender: the tenderReference.

Payment terminal (PED/PDQ/Terminal) Refers to the Payment terminal where a card is inserted or swiped. "Terminal" is sometimes used to mean the Cash Register. Adyen refers to the Payment terminal as "the terminal".
EMV Europay MasterCard Visa (standard for ICC transactions)
POS Entry Mode Means by which the PAN is propagated to the terminal
CVM Cardholder Verification Method
Terminal Capabilities Supported POS Entry Modes and CVM's
ICC Integrated Circuit Card (chip card)
MKE Manual Keyed Entry – Card Present transaction
MSR Magnetic Stripe Reader (swipe card)
NFC Near Field Communication. In the context of POS, NFC is the technology used in Contactless payments.
PED PIN Entry Device. This is separate from the card reader, and is typically unattended. This method is popular in France.
PDQ Process Data Quickly – old name, reading the PAN from the MSR was quick compared to MKE.
POSTFM POS Terminal Fleet Manager
DCR Digital Customer Recognition
P2PE Point To Point Encryption 
General
DCC Dynamic Currency Conversion
API Application Programming Interface
ISO International Organisation for Standardisation
MOTO Mail Order Telephone Order – Card Not Present transaction
TX Transaction

Main POS Components

Term Description
Terminal (payment terminal)

Accepts a request from the Adyen libraries to start transactions. The PAN is read via any supported POS Entry Mode and CVM is performed on the terminal if applicable. The terminal informs the shopper about the amount charged, offers DCC if applicable and allows printing of a receipt. The authorization is obtained and the resulting data is sent to the Adyen platform for further processing. The receipt is sent with this data and you can see it in the Adyen Customer Area (CA).

Shopper Cardholder
Adyen POS Application Acts as a hardware driver that also facilitates simple transactions using a built-in cash register. The app can be connected to a Merchant Cash Register application through a simple interface while still offering a wealth of functionality.
Adyen POS Library Provides payment functionality to the Cash Register. This includes registering the Cash Register with Adyen, boarding the terminals and performing payment functions. The Adyen POS Application also uses the Library to integrate with the Merchant Cash Register.
Adyen platform The PSP service and acquiring host. The terminal connects to this system to obtain authorizations and submit capture data. Processes like DCR as well as DCC are controlled by the Adyen platform. The Cash Register connects to this system, via the library, to register itself and terminals in the POSTFM. The terminal and account configuration is done here. The Adyen platform sends out notifications to the Merchant back-end.
Merchant Back-end When the Cash Register has performed product selection and totaled the amount, the order is typically stored in the Merchant back-end. The outcome of the payment process will be stored with the order. Refunds for existing orders are communicated from the Cash Register to the Merchant back-end where an API call to the Adyen platform is made to perform the refund. The Merchant back-end receives notifications from the Adyen platform.

Offline processing

Adyen terminals process transactions online by default. Offline processing is optional and requires configuration.

 
The Floor Limit is the maximum cash value the terminal allows for a transaction when processed offline. If the amount of the transaction is below the configured Floor Limit and the terminal can not connect to the Adyen host for authorization the terminal will leave the decision up to the card to approve or decline the transaction. Debit cards will typically decline a transaction while most credit cards are configured to approve a relatively small amount offline.

Dynamic Currency Conversion

Dynamic Currency Conversion (DCC), also referred to as Cardholder Preferred Currency (CPC), allows shoppers to convert the transaction amount to their cards default currency when making a payment abroad.

The shopper is presented with the choice to convert the transaction amount, when the transaction is in a currency other then the default configured on the card and the terminal has been configured to allow DCC.

Full details on the exchange rate are provided to the shopper on the terminal to allow an informed decision, and simultaneously to the Cash Register for merchant information.

The shopper either accepts or rejects the DCC offer and proceeds with the selected amount and currency. If DCC is selected, related information is shown on the receipt.

 Shoppers may appreciate this feature because they can immediately understand the full amount charged for the transaction in a familiar currency.

Terminal Capabilities

The terminal capabilities are defined in the Adyen Back-end and propagated to the PED. They indicate the POS Entry Mode options as well as CVM options the terminal supports.

POS Entry Mode Options

There are four POS Entry Modes on Adyen terminals. They are:

Term Description
Chip/ICC Integrated Card Circuit
Swipe; MSR Magnetic Stripe Read
NFC; CLESS_CHIP/CLESS_SWIPE Contactless flavors
Keyed; MKE Manual Keyed Entry

Each can be configured independently to be supported by the terminal.

CVM Options

There are five supported CVM options on Adyen terminals. Sometimes two are combined. They are:

Term Description
Offline Enciphered CVM that verifies the cardholder's PIN by encrypting the entered PIN before sending it to the card. Terminals that support Offline enciphered PIN must also support the less secure Offline plain-text PIN method. (PosEntryMode ICC only)
Plain text PIN Verifies the cardholder's PIN by sending the unencrypted PIN to the card. This is commonly used by cards that can not support the more secure Offline enciphered PIN. (PosEntryMode ICC only)
Online PIN Verifies the cardholder's PIN by encrypting the entered PIN before sending it online to the card issuer. Active if the specific card scheme (payment method) and specific card supports it.
Signature The signature can be captured on screen or paper.  If the signature is unsuccessful, the tender cannot be authorized.
No CVM

No CVM required.

The accepted POS Entry Modes and CVM's can be configured to only consist of a subset of the above. Each can be configured independently to be supported by the terminal.

Transaction Types

Adyen supports two transaction types:

  • GOODS_SERVICES (a.k.a. SALE).
  • REFUND (processed over the terminal as opposed to via an API call).

Cash Withdrawals and Cashback transactions are not supported. Adyen does offer an API to record Cash payments for bookkeeping purposes. They are included in the reporting as transactions without settlement.

CVM lists

The CVM list contains Amount Thresholds and includes three elements per CVM:

  • CVM Code - States what to do when an entry fails, either proceed with the next one or fail the CVM process.
  • CVM Type - the actual CVM to be performed e.g. PIN verification.
  • Condition Code - stipulates under which conditions the CVM Type is applicable e.g. Always enforce Online PIN for ATM withdrawals.

A LIVE Example

The following CVM list is taken from a Mastercard of type "mcredit".
The Amount Thresholds are not used. The first CVM is only used for ATM's and Cashback transactions. All other CVM's are used if the terminal supports them. For an Adyen terminal all are supported and the first available one in the list would be selected – CVM 2 Enciphered PIN verification performed by ICC

  Amount Thresholds

  • Amount X: 0
  • Amount Y: 0

Cardholder Verification Method 1

  • CVM CodeFail cardholder verification if this CVM is unsuccessful
  • CVM TypeEnciphered PIN verified online
  • CVM Condition CodeIf cash or cashback (includes quasi-cash)

Cardholder Verification Method 2

  • CVM CodeApply succeeding CVM field if this CVM is unsuccessful
  • CVM TypeEnciphered PIN verification performed by ICC
  • CVM Condition CodeIf terminal supports the CVM

Cardholder Verification Method 3

  • CVM CodeFail cardholder verification if this CVM is unsuccessful
  • CVM TypePlaintext PIN verification performed by ICC
  • CVM Condition CodeIf terminal supports the CVM

Cardholder Verification Method 4

  • CVM CodeFail cardholder verification if this CVM is unsuccessful
  • CVM TypeEnciphered PIN verified online
  • CVM Condition CodeIf terminal supports the CVM

Cardholder Verification Method 5

  • CVM CodeFail cardholder verification if this CVM is unsuccessful
  • CVM TypeSignature (paper)
  • CVM Condition CodeIf terminal supports the CVM

Cardholder Verification Method 6

  • CVM CodeFail cardholder verification if this CVM is unsuccessful
  • CVM TypeNo CVM required
  • CVM Condition CodeIf terminal supports the CVM

A TEST Example

Adyen has various TEST cards that allow for testing of a wide variety of scenarios via a single physical card.
This is possible through a combination of a specific CVM list and outcomes based on amounts (see POS test system)
The full CVM list with details, for the Adyen TEST card provided to you, is best inspected through the Adyen CA. You can perform a transaction with each application on the card and see the CVM list as part of the EMV details. The use of Amount Thresholds is not common for LIVE cards but very useful for testing purposes. Through the amounts the CVM can be varied easily. The last three digits of the amount determine the outcome of the transaction independent of the CVM. As part of the Condition Code the currency has been added.
As an example, the CVM list for one of Adyen's TEST card application has the following elements:
Amount Thresholds

  • Amount X: 10000
  • Amount Y: 20000

Cardholder Verification Method 1

  • CVM Code: Apply succeeding CVM field if this CVM is unsuccessful
  • CVM Type: Enciphered PIN verified online
  • CVM Condition Code: If transaction is in Application Currency Code and is over Y value

Cardholder Verification Method 2

  • CVM Code: Apply succeeding CVM field if this CVM is unsuccessful
  • CVM Type: Enciphered PIN verification performed by ICC
  • CVM Condition Code: If transaction is in Application Currency Code and is over X value

Cardholder Verification Method 3

  • CVM Code: Fail cardholder verification if this CVM is unsuccessful
  • CVM Type: Signature (paper)
  • CVM Condition Code: Always

If the selected application has Currency Code EUR and the transaction is for GBP 95 there are two options:

  1. The shopper accepts DCC and is charged ~ EUR 135,-. This means CVM 2 is selected because EUR 135 over Amount X and the transaction – after accepting DCC - is in the Application Currency Code
  2. The shopper rejects (or is not offered DCC). This means CVM 3 is selected because the transaction is not in the Application Currency Code and CVM 3 'Always' applied.

CVM Results

The resulting CVM reported to the Cash Register is a hexadecimal representation of the CVM used to verify the card holder.
Example: 440702. The character in second position in this string holds the CVM. The following table outlines what each character means.

Character Definition
1  Offline plaintext PIN
2 Online PIN
3 Offline plaintext PIN and signature
4 Offline enciphered PIN
5 Offline enciphered PIN and signature
E Signature
F No CVM performed

NFC limits and CVM

Contactless or NFC transactions are subject to the following configuration options:

  • Contactless CVM limit: an amount (minor units) above which the terminal will require a CVM.
  • Contactless Currency : currency for which contactless transactions can be performed, equal to the country in which the store is located.
  • Contactless floorlimit: floorlimit specifically for contactless transactions.
  • Contactless maximum amount: maximum amount for which a NFC transaction can be performed. If the amount is higher and the terminal general maximum allows it the transaction will start without activating the NFC reader.

If the transaction amount is higher than the contactless CVM limit and a NFC capable card is tapped the terminal will indicate to the card a CVM is required. The card will indicate whether a signature or PIN is required. For PIN this always means an Online PIN is the actual CVM. This implies a NFC transaction over the CVM limit, requiring PIN, cannot be processed offline.

PIN bypass

Used to bypass PIN entry by the shopper in situations where the shopper does not know the PIN for the card and the Merchant trusts the shopper.

  1. The shopper indicates the PIN is not known.
  2. The staff initiates a special functions transaction through a separate menu and asks the shopper to press Enter when prompted for PIN.
  3. The shopper provides a signature.
  4. The Merchant checks the signature and approves it.

A cardholder is expected to know the PIN for the card issued. Comparing the signature as well as cardholder name with some form of identification is recommended.

Notifications for Merchants processing POS transactions

The Merchant back-end receives notifications from the Adyen platform. This includes reports on the outcome of transactions, refunds, creation of recurring contracts, etc.

For offline transactions the pspReference is generated by the Adyen platform and sent to the Merchant in a notification. This value should be stored in the Merchant back-end for use in Refunds. 

Notifications are used to report the outcome of refund requests. Refunds are processed asynchronously by the Adyen platform. Refunds requests are received and a response confirms the receipt of the request. In the rare event a refund can not be processed, contact Adyen and, if possible, the shopper to find an alternative way of refunding the shopper.  

Notifications are also sent out when a report is generated. This way report retrieval can be automated from the Merchant back-end system.