App Filtering - AEVI-AppFlow/pos-android-sdk GitHub Wiki

When FPS receives a request, it will match the request data against the service info details provided by each application defined in the active flow to ensure only eligible applications are called for that request.

If there is a single match after filtering, that application will be automatically selected. If there are more than one match, a dialog will be shown to allow the operator/merchant to select. If there are no matching applications, an error will be returned to the calling POS app.

Payments

Payment requests are filtered against application manifest data and the PaymentFlowServiceInfo data as follows

• Enable state -> Is the flow service installed and enabled on the device
• API version -> Is the flow service integrated with the same major API version as FPS
• Flow stage -> Does the flow service have an entry point for the current flow stage defined or not
• Flow type -> Does the flow service support the flow type
• Currency -> Does the flow service support the request currency

If any of these checks fail, the flow service will be deemed ineligible for handling the request in the current flow stage.

In addition, for the TRANSACTION_PROCESSING stage, a check will be made to ensure only the relevant payment application is called for cases where a card token has been specified.

Generic requests

For generic Request cases, the following data is used for filtering

• Enable state -> Is the flow service installed and enabled on the device
• API version -> Is the flow service integrated with the same major API version as FPS
• Flow stage -> Does the flow service have an entry point for the current flow stage defined or not
• Request type -> Does the flow service support the flow type, or has it defined as a custom request type
• Target app id -> If the request specified a flow service, and the above criteria is met for that flow service, it will be selected automatically