transactions - AEVI-AppFlow/pos-android-sdk GitHub Wiki

Transactions in AppFlow are a bit more complex than most SDKs due to the support for split transactions and the ability for multiple applications in a transaction to pay portions of the requested amounts.

When a Payment is received by FPS, it will create an initial Transaction instance representing the total requested amounts. For non-split scenarios, this will be the only Transaction instance created. For split scenarios, a new instance of Transaction will be created for each split, reflecting the amounts the split application has requested.

The Transaction represents the flow journey from PRE_TRANSACTION to POST_TRANSACTION, during which a number of flow services may add amounts, pay amounts, etc. For each application that is called throughout a transaction, a request that reflects the current state and is appropriate for that stage is created. All transaction stages receive a TransactionRequest object except for POST_TRANSACTION, which receives a TransactionSummary object.

Any stage that receives a TransactionRequest has the ability to indirectly generate a TransactionResponse. Eligible flow services may do so via paying off amounts, which is the case for example loyalty applications and payment applications. Others, like in the PAYMENT_CARD_READING stage, may lead to a declined transaction. In addition, a split application, may in the SPLIT stage, pay off an entire Transaction in one go. Typically via offering a customer the ability to pay via cash. FIXME Errrr...do we call POST_TRANSACTION for this!?

It is important to know what ids to use for what as there are a number of functions that require applications to read or specify ids;

• For multi-stage applications to track a transaction through the stages
• To create id-based requests such as reversals
• To look up the correct responses for a given request

The following unique ids are generated, all available via the getId() method for each model;

• One for each Payment and PaymentResponse pair to represent that payment
• One for each Transaction, which uniquely identifies that transaction throughout all the stages,
• One for each TransactionRequest and TransactionResponse pair (where a response is applicable)

In addition,

• The TransactionSummary.getId() will return the id of the Transaction it represents (as it extends it)
• Each TransactionRequest has a getTransactionId() method that represents the Transaction that it was created for, allowing flow services to identify the same transaction throughout unique requests for different stages