v1 to v2 migration - AEVI-AppFlow/pos-android-sdk GitHub Wiki

The second version of these APIs contain some breaking changes that means you will have to adapt your application if it is currently integrated with the first version.

API structure

The in v1 separate APIs payment-service-api and flow-service-api have been merged in this version into a new payment-flow-service-api.

This means you have to update your dependencies accordingly.

There is no longer any major distinction between what was previously known as a flow service (aka VAAs) and payment services. A service simply defines what stages it wants to support and that determines what function(s) they can provide. A traditional payment application is a service that gets called during the transaction processing stage.

API clients

FlowClient has been removed and all methods are now defined in PaymentClient to improve clarity of where to find things (in particular for JavaDocs). In addition, we have the following client changes

  • getSystemSettings(), getFlowServices() and getPaymentServices() replaced by getPaymentSettings()
  • getCurrentRequestStatus() removed - instead just use blockingFirst() on the subscribe method.
  • processRequest() renamed to initiateRequest() to follow initiatePayment() naming
  • subscribeToStatusUpdates() has been removed completely

Manifest changes

Payment services

Payment services, as in services that support transaction processing, which previously used the payment-service-api, no longer needs to define the "configuration-authority" meta-data for the service that implements "com.aevi.sdk.pos.flow.action.PROCESS_PAYMENT".

Instead, your applications needs to update the intent filter for the service info provider to com.aevi.sdk.flow.action.PROVIDE_SERVICE_INFO

Flow services

Flow services also need to update the intent action for their service info provider to com.aevi.sdk.flow.action.PROVIDE_SERVICE_INFO

Service info providers

As the APIs are merged, there is now also a single base service info provider that you need to extend from, and a single builder class to generate your service info.

public class SampleServiceInfoProvider extends BasePaymentFlowServiceInfoProvider

And the builder to use is PaymentFlowServiceInfoBuilder.

Changes to service info data

  • withSupportedRequestTypes() has been replaced with withCustomRequestTypes() and a service now only defines bespoke request types, if any. Example like showLoyaltyBalance, etc which is bespoke to a particular app.
  • withSupportedTransactionTypes() has been removed (flow configs now determine types)
  • Support to set any custom / arbitrary data via withAdditionalInfo()

For payment service migration, note the following changes

  • withTerminalId() renamed to withLogicalDeviceId()
  • New merchants model to represent merchants, use withMerchants(Merchant... merchants)
  • withManualEntrySupport()
  • withPrintsReceipts() can now be set as additional data
  • withSupportsFlowCardReading() is no longer required, apps should set the appropriate filter in the manifest indicating card reading support

Changes to requests

The way flows are managed has changed in order to improve its flexibility. This means that rather than passing a transaction type to the PaymentBuilder or a request type to the Request, you now need to pass the name of the flow that you want to initiate.

There are two ways we expect this to work. In the first case, for most production scenarios, the POS apps will be aware of all the possible flows up-front and most likely hard code what they are. In the second case, for dev, testing, etc, the API can be used to map a type (so the function required) to a list of possible flows. For the most part, it will only be a single flow defined for any given type.

Various other model changes

  • PaymentStage enum is gone and replaced by the FlowStages string definitions
  • TransactionRequest.getPaymentStage() now getFlowStage() and returns a string instead
  • RequestStatus is deleted as the corresponding API method to obtain it has been deleted