POS (Point Of Sale) payment terminal is the hardware terminal that enables the merchant to collect the card payment data and send it to the acquirer. It is y this device that you swipe your card in or tap it on.
On the other hand, the PoS application is the application that is used by the cashier at the merchant store to create the sales order and trigger the payment. This application, for example, integrates with the bar-code reader and fetches the prices of the purchased goods from the products catalog. It collects multiple purchased goods or food menu items in one invoice/order and sends the total amount to the POS payment terminal to collect the payment from the customer. PoS applications are quite advanced now, and some vendors even provide cloud backend for them. For example, to manage all tables in a restaurant and track orders for each..etc.
Collecting and processing a payment is not part of the PoS application. Many PSPs or payment facialitators, like Square, provide the POS application besides the terminal for different industries like restaurants or retail. While others only provide the terminals and their integration SDKs to be used by the merchants to develop their own POS application like Adyen and Stripe.
The Payment Terminal
The terminal contains both contact and contactless card readers embedded in single hardware to be used to read the card data or "card holder data". This can be a reader for the chip on the card, or it may contain a magnetic reader as well since it’s sometimes the backup way to read the card data, especially in US.
The terminal as well contains a hardware called PED (PIN Entry Pad), which is the keypad used to enter the PIN, or as it is called the " CVM", the Cardholder Verification Method. The terminal stores the specific acquirer encryption keys in a secure manner in order to use them to verify the PIN. This can be offline or online PIN verification.
There are many POS vendors, like PAX, Ingenico, and Verifone.
Terminal Types
There is a wide range of terminal types to match the different merchant use cases:
- Classic POS
- MPos (Mini POS)
- Pay phone
- Pay Tablets
- Smart ECR
- Kiosk
- Unattended POS (like in parking garages)
Terminal Operating System
Before Android, terminals were used to be Linux only (classic terminals) since it’s efficient and secure. Now most POS vendors customised the Android kernel to enhance its security and used it as their temirnal operatign system. With Android, merchants can guarantee the ease of use and the benefit from the variety of UI/UX. Acquirers as well can ensure the security of the payment process. Overall, terminals are now eithe Linux or Android.
Terminals Compliance
The card scheme (Visa, MasterCard..etc) and EMVCo put some rules to be followed by the acquirers, issuers, and the terminals vendors as well in their terminal design and build. This is embodied in a set of certification that need to be acquired by all players in the card payment chain:
PCI DSS Certification
PCI DSS stands for Payment Card Industry Data Security Standard. It is a set of security standards designed to ensure that all companies that accept, process, store or transmit credit card information maintain a secure environment to protect both the consumer and the merchant.
When you take a customer’s credit card, you receive a great deal of sensitive data. The PCI SSC (Payment Card Industry Security Standard Council) was founded by major card brands (like AMEX, MasterCard, Visa, JCB and Discover) to develop and manage security in the payment card industry.
EMV L1, L2 and L3 Certification
EMVCo is focused on the security and compliance of any hardward that reads card payment data. Any POS terminal hardware used in the market has to pass by EMVCo to certify that the POS terminal can collect the cardholder data according to their standards and the card scheme standard.
- EMV Level 1 testing evaluates the terminal chip reader for compliance with the mechanical and electrical protocols in the EMV Chip Specifications, which covers the transfer of data between the terminal and the card, smartphone, watch, or other devices for making card-based payments. This includes tests to confirm how close the card/device and the reader need to be for information to flow.
- EMV L2 testing evaluates the ‘EMV Level 2 kernel’, which is the software inside the terminal (known as firmware) that performs EMV processing, for compliance with the EMV Chip Specifications. This includes tests to confirm that the software supports the EMV payment application functions.
- EMV Level 3 testing ensures the conformity of merchant terminals to payment systems policies and procedures. The payment systems require that chip terminals that have been configured for deployment are Level 3 tested before being integrated into their payment acceptance environments.
This means the chip terminal must be complete with its EMVCo-approved hardware (L1) and software kernel and payment application (L2) in place and must be configured with the right application before being connected to a test environment or host simulator, which mimics authorisation responses from payment systems.
L3 testing evaluates and confirms that an EMV-compliant payment acceptance terminal will work with merchant or bank systems to enable end-to-end transaction acceptance. The testing helps ensure that a new or upgraded terminal (hardware and/or software) meets the specific requirements and recommendations of the individual payment systems before it is brought to market.
The Integration with The POS Terminal
PoS applications need to integrate with the terminal, to collect the payment from customer, or to trigger a refund..etc. This is done through two ways:
Local integration: Through some Terminal SDK provided by the PSP or terminal vendor. The terminal SDK runs in the same runtime of the PoS application. At the end, it is a library to be invoked in the PoS application. The Terminal SDK interacts with the terminal through the local network and doesn’t pass through the internet.
SDKs provided by PSPs are in client languages and operting systems, like Android (Javae or Kotlin), iOS (ObjectiveC or Swift), or Web (JavaScript).
Cloud or Server Integration: To avoid this SDK and programming language limitation, some vendors (like Stripe, Adyen, and Square) provide integration with the terminals through server integration. This means that your PoS application should call your POS backedn first, which triggers the payment at the PSP (through REST APIs in this case, not SDK). The PSP will trigger or push the the payment in the terminal then. Indeed, integration here is longer and has to pass through the internet to your PSP, and from PSP to the teminals.
It is always better to use local integration since it does’t completely rely on the internet connection in the store or the restaurant. Cloud integration as well doesn’t support store and forward transactions and offline transactions.
Local Integration Flow
In the diagram below is an example of a Single Message System transaction, which means the transaction is authorised and captured in one call:
- The terminal is started and connected to the merchant PSP account (endpoint A). This is done through pre-configuration in the terminal.
- The PoS application through an API endpoint in the PoS backend (endpoint B), to request an access key to use it for communication with the terminal.
- The backend consequently calls the relevant API at the PSP (endpoint C) to retrieve such access keys. The keys are used by the PoS application in all calls to the terminals through the PSP Terminal SDK.
- Now the cashier at the store creates a new sale for a new customer, the PoS application adds the amounts of all the prices of the purchased goods, with discounts..etc. The cashier clicks on “Charge” button in the PoS client to collect the payment through the terminal.
- First, a payment intent with payment information has to be created at the PSP. This is done through the a call from the PoS application to the terminal through the PSP Terminal SDK
- The terminal will communicate directly with the PSP (endpoint D) to create a payment intent and return the intent ID to the POS application.
- The POS application, using the PSP Terminal SDK, triggers the payment on the terminal for collection, using the returned payment intent ID. The terminal shows the amount to be paid on its screen and the API waits for the customer to present the card.
- The customer presents the card and the payment information is collected by the terminal.
- Another call is made to the terminal to “process” the payment. This is using intent ID. Card payment data is not returned back to the POS application in anyways.
- The terminal then sends the encrypted card payment data to the PSP for processing the payment (endpoint E).
- Payment transaction is sent to the card network and a response with success/fail is returned back to the POS application. If the payment is successful based on the API response, the flow is continued to print the receipt..etc.
PCI DSS Compliance
It is interesting as well which systems and integration lines fall under the PCI DSS compliant and audit, and thus all the encryption, card data manipulation..etc in these systems have to be compliant. As we saw in the flow, only the following systems process and read card holder data or card payment data:
- The terminal: That is why all terminal models have to be PCI DSS compliant as mentioned above.
- The PSP: Indeed, the PSP systems have to be compliant.
- Only the last call (10) to process the card data. This is the call that has encrypted card holder data in the payload.
As we can see, the entire POS application and any merchant systems don’t fall under the PCI DSS at all and thus it is easier and simpler to develop and build such application with this isolation.
Tap to Pay on iPhone
Apple recently released in US only the feature to use the iPhone as a terminal (Tap to Pay on iPhone). This would make the cost much cheaper and time much shorter to onboard new merchants into payment facilitators or PSPs.
The feature needs special integration between the PSP and Apple servers, That is why limited number of PSPs support this feature till now. List of PSPs that support this feature is in this link. This is different from Apple Pay which requires special integration between the issuer bank or processor and Apple servers. We will talk about that later.
Here is a really nice video from Apple on the new feature:
Integration Flow
First we need to understand two hardware components on the iPhone, that are quite related to the integration flow. These are the definitions as they are from Apple:
Secure Element: The Secure Element is an industry-standard certified chip running the Java Card platform, which is compliant with financial industry requirements for electronic payments. The Secure Element IC and the Java Card platform are certified in accordance with the EMVCo Security Evaluation process.
NFC Controller: The NFC controller handles Near Field Communication protocols and routes communication between the Application Processor and the Secure Element, and between the Secure Element and the point-of-sale terminal.
Here is the flow for a POS app on the iPhone to support Tap to Pay and act as a terminal, mostly influenced by Stripe flow. However, all PSPs have similar flows:
- The PoS app code connects to the NFC controller when starting up. This is done through API calls for the the iOS SDK provided by the PSP that calls iOS native SDKs. We will call it "PSP iOS Terminal SDK".
- The PSP iOS Terminal SDK connects to the NFC controller on iPhone. Now the POS app is connected to the iPhone NFC controller/reader.
- There is a customer with some purchases. The cashier opens the POS app on the iPhone (owned by the store may be) and adds the different goods, and the app calculates the total sum to be paid.
- The POS app code calls the PSP iOS Terminal SDK to create a payment intent.
- PSP iOS Terminal SDK calls the PSP backend API to create the intent payment (endpoint A).
- Now the POS app code calls the PSP iOS Terminal SDK to collect the payment.
- The SDK calls iOS ProximityReader APIs (this is iOS native SDK) to collect the payment, which means it shows the secure payment acceptance applet, which is a modal screen as in the picture on the right.
- The customer presents his card, or even his phone if he/she is using ApplePay. The iOS secure payment acceptance applet is shown.
- Then payment data is read through the NFC controller and stored in the Secure Element in the iPhone. The entire card reading flow is done using iOS software (through the applet) and hardware (NFC Controller and Secure Element).
- The encrypted card data is sent to Apple servers. They are stored in Apple servers and encrypted using keys generated only for this specific PSP. This PSP only can decrypt the card data.
- Now the POS app calls the PSP iOS Terminal SDK to “process” the payment.
- The PSP SDK calls directly the PSP backend to process the payment (endpoint B).
- PSP calls Apple servers to retrieve the encrypted card data for this payment. Only this PSP is allowed to decrypt the card holder data. Apple Tap To Pay servers exchange the decryption keys with the PSP beforehand.
- Using the decrypted card data, PSP calls the card network to process the payment. Response is returned to the PSP, then to the PSP iOS Terminal SDK and POS app on the merchant iPhone, to continue the flow, like receipt payment..etc.
PCI DSS Compliance
Although the Tap to Pay feature in iPhone looks as if it is an integrated part of the POS app, the payment flow isolation makes the app again out of the coverage of the PCI DSS compliance. As we see from the flow, only the following systems process card holder data and thus fall under the PCI DSS compliance. They are marked in red:
- The iOS ProximityReader SDK
- The NFC Controller
- The Secure Element on the iPhone
- The call to transfer the encrypted card data from the secure element to Apple servers, which is completely done by iOS SDKs (call 10)
- The call from the PSP to Apple servers, which is a pre-established and certified integration between the PSP and Apple.
As you see, none of these items are in the POS app or any other merchant related components, which again makes the development of such apps and integration of payment much easier since it doesn’t need any compliance or certification for the merchant.
Woof…this was a long one, but it was worth it! I would like to thank Noor Asser for co-authoring this long long post. His experiece and insight in the POS field was of a lot of value in this post.
To another post!