handling card tokens - AEVI-AppFlow/pos-android-sdk GitHub Wiki

Using card tokens to identify a payment card and from that the customer, is a useful way to make the point of sale experience smoother for a customer.

AppFlow supports various ways for payment services to supply card tokens and various ways for value added services and POS applications to retrieve these card tokens. The ideal scenario is for a card token and/or customer details to be available from the post-card-reading stage to allow value added services (such as loyalty schemes) to offer rewards or use of loyalty points before the transaction processing stage.

AppFlow supports a dedicates payment card reading stage in its payment flows. Assuming the payment service and/or the acquirer/host supports generating a token separately, this would be the preferred way to provide a value added service in the post card reading stage with a token. The card details will be passed down to all services in the flow and be available for the POS application in the final response.

A POS application can initiate a dedicated tokenisation request and provided that there is a flow and a payment service that supports this, retrieve a card token that way. The POS app can then use this when initiating a payment in two ways;

• Setting it as the cardToken in the Payment model
• Assigning it to a Customer and pass that in the Payment model

Generally speaking, the first approach here is intended for use by payment services for scenarios such as subscriptions that may be linked to a card token. It is however available for use by any flow service. The second approach is the preferred option for when there is a representation of customer data and is more useful for value added services.

The payment service (possibly via the acquirer host) can provide card details, including a token, in the TransactionResponse created during transaction processing.

This provides any post-transaction flow services access to card details and the POS app can retrieve it from the response once the flow is completed.

The latter two approaches puts a lot more responsibility onto the POS application, as it has to store tokens and/or customer details in order to allow value added services to access the token before transaction processing.