In-Store Payments

Merchants have many options when it comes to accepting card payments at the point of sale (POS) from customers who visit their place of business. This article first explains how this card-present process works — such as authorization flow, entry methods, and payer verification — and then covers the various integration solutions we offer to meet the needs of your POS application.

POS environments primarily include “brick and mortar” merchants who want to have their customers (that is, cardholders) pay by swiping an attached terminal device. Application developers who want to use our API to integrate card-present transaction processing into their existing POS application should integrate using our POS options.

Our API uses a REST framework and is designed to connect payments from numerous regions, channels, and payment methods worldwide into a single integration. It’s ideally suited if you want to add in-store payments to your existing online integration, such as an app or website. (For more information on taking online payments, see Online Payments.)

Customers have the option of paying with their card in person at a store (card present) or using their card remotely to pay via some type of technology (card not present). Our API, when implemented in a POS environment, creates a card-present environment, as defined below:

• Card present – The card (and cardholder) is physically present during the transaction, such as an in-person sale.
• Card not present – The card (and cardholder) is not physically present during the transaction, such as via a website or app, or by MOTO (mail order / telephone order).

There are various types of integrations for you to choose from. One of these types of integrations should meet the needs of your POS application. We have solutions for each, which you can discuss with your account manager. The pros and cons of each integration are described in each section below.