intro to payment apps - AEVI-AppFlow/pos-android-sdk GitHub Wiki

Payment applications are responsible for processing transactions and establising the outcomes. There are no restrictions as to what payment methods these applications choose to use for processing the payment - be it a traditional card payment, mobile, cryptocurrencies, etc.

There can be multiple payment applications available, offering different payment methods or simply connected to different acquirers / payment gateways.

There are two ways in which a request is narrowed down to a single payment application for processing.

The first is the flow configuration, which will determine what applications are eligible to receive the request.

Secondarily, there are matching algorithms that will match request data to payment application support info. As an example, if the request has specified GBP as the currency, and one of the payment applications only supports EUR, then that application is not a candidate to process this payment and will be filtered out.

Once the filtering has completed, the system will automatically progress with any single application that remains eligible. If however there is still more than one option, the merchant and/or customer will be presented with a selection UI on the device to choose which application to use.

This implementation supports the concept of payment adapters, which means that payment services developed against other APIs could be used to handle AppFlow requests.

As an example, AppFlow requests can be converted to Square Register requests via a Square payment adapter, which proxies the request onto the Square system for processing and then convert the result back to AppFlow at the end of it.

AppFlow comes with such an adapter pre-defined for communicating with AEVI Simple Payment API (previous generation SDK) payment apps.

AppFlow supports the concept of a payment card reading stage that is separate from the transaction processing step. This would allow flow applications to act based on card data and potentially augment the transaction before the processing step. The main use case for this is to provide flow services with a card token that can be used to identify the customer for purposes such as loyalty. However, other information such as card scheme (VISA, MASTERCARD, etc), BIN range, expiry date, could also be useful for flow services.

This stage is optional for payment applications to support. It is not necessarily even possible to achieve on all types of payment terminals.

Whether or not this stage can be separate from the processing also comes down to which of the three methods of presentation is used.

For magstripe (swipe), this is normally trivial as once the tracks have been read, any interaction with the card is done. A card token can be generated and the scheme, etc is known. It may however require a double swipe in cases where the payment application is not allowed to store the track data between the stages due to PCI rules, etc.

For contact (chip / insert), it is technically possible to stop after EMV application selection and then resume the session at the transaction processing stage, provided that the payment device (APIs, hardware, kernels, etc) allow for a long timeout for the session.

For contactless, the session is generally over and the outcome from the kernel is delivered in one step. There are some exceptions where the session is stopped after PPSE (such as for Carte Bancaire in France), but for the most case, it is a one step process. It is therefore assumed that for this to work with contactless, it would have to be a double-tap process (one tap for this stage, another tap for processing stage).

Whether or not the separate reading can be supported for any given payment service / acquirer is up to the developers of that payment application to determine. The flow configuration in use will also determine whether the stage is defined at all or not.