Payment Flows Overview

info

EMV stands for Europay-Mastercard-Visa and is used as a catch-all term for payment cards which are issued by a bank, credit, or charge card issuer. Payter handle the authorization of these cards through certified and regulated processes and methods.

In this section we illustrate how to take payments with the Payter Session Protocol.

For most Integration Controllers, this is the primary purpose of the Payter terminal and PSP. It is important to realise however that Payter's role is somewhat limited. Integration Controllers should be aware at this stage exactly how and when they want to initiate a request for a payment card.

The user journey and experience should be considered carefully, and ideally is already well established at this point.

When to Request a Card Read

There are two main times that a Card Read should be requested:

• The terminal is always scanning for a card. The integration controller requests a new Start Session following the completion of the previous card payment.
• The terminal requests a card following a Human interaction event. The local controller is aware, sometimes via the Payter terminal itself, that a human is present and wishes to present their card.

Always Scanning Approach

Sometimes called "tap to start", it can be efficient to simply capture card details first and use that as a trigger to drive further Human-Machine Interfacing (HMI).

Examples

A cardholder taps their card on an EV Charger. This 'wakes' the EV Controller which requests Authorization via PSP whilst informing the Cardholder via their own screen/HMI on what to do to begin charging the vehicle.

A cardholder taps their card on a Smart Fridge. The local controller authorizes the payment of €10 and uses PSP to send a User Interface request to the Payter Apollo terminal confirming the next steps; To open the fridge and remove the chosen product(s).

Always Scanning relies on the Integration Controller clearly telling the cardholder what to do first, and also needs to employ logic to ensure the same cardholder is not repeatedly charged if they tap their card erroneously.

Read Card on Demand

In this approach, other means are used to detect that a Human wants to scan their card, and the Integration Controller triggers this on-demand.

Examples

A cardholder selects the 'pay by card' option on a vending machine. The controller then knows to send a Start Session request to the terminal, potentially using the Setup Flow prior to this and also on demand.

A cardholder presses a button on a Payter Apollo terminal UI screen labelled "Start". The Integration Controller receives this UI Event message via PSP and sends the Start Session request back.

Read Card relies on the Integration Controller being able to detect the Cardholder, typically through a combination of messaging and Human-Machine Interfaces.

Complexity

Combinations of both approaches are also valid. It is highly recommended that the User Journey is visually mapped out by the Integration Controller, especially where complex Human interactions are expected or required.

Payter can assist with this to some extent, and our Best Practice section can also be a useful reference point.