Payment Entries Processor
Introduction
The IPF Payment Entries Processor is a core component, designed to be a part of a Scheduled Payments solution. This component is built in a generic way, with the purpose of being able to resiliently process Payment Entries in multiple different ways.
It is currently possible to:
-
Release stored Transaction/Instruction for payment execution
-
Cancel stored Transaction/Instruction
Payment Entries Processor has three main functions exposed as an API:
-
Prepare Instruction
-
Process Instruction
-
Process Transaction
Its main role is fetching stored payment details, creating valid Processing Requests, and Releasing or Cancelling them in a client-specific way.
How Releasing process works
Prepare Instruction for Release
To prepare for the release of an Instruction (Batch), this operation can be called. It indicates that the Instruction is ready to be released and gives an opportunity for downstream components to initialise before the instructed transactions are triggered for release.
When prepareInstruction is called with an Instruction UnitOfWorkId, the system will retrieve the stored Instruction and send it on to the defined receiving component.
The retrieving component is expected to, but not required to, release the transactions for the Instruction when it is ready
| The act of preparation does not trigger the release of the transactions. |
This method, if used, should be called in advance of processInstruction(UnitOfWorkId, ProcessingActionType, SupportingContext).
For releasing instructions and/or transactions, the ProcessingActionType can be specified as RELEASE.
However, it is not a pre-requisite to call this method if there is no preparation to be done; in this case the caller can directly call processInstruction(UnitOfWorkId, ProcessingActionType, SupportingContext).
Release Instruction (Batch Transaction Release)
To trigger the Instruction (Batch) release process, you must provide the UnitOfWorkId of the stored Payment Instruction whose child Payment Transactions should be sent for Execution.
| Payment details are stored as Initiation (Bulk), Instruction (Batch), and Transaction payment information. |
After a trigger containing the Payment Instruction’s UnitOfWorkId and appropriate ProcessingActionType is received, the Payment Entries Processor will:
-
Retrieve stored Payment Instruction information
-
Try to retrieve relevant stored Payment Initiation information if there is one present
-
Fetch all relevant Payment Transaction information, and for each of them:
-
Enrich the Transaction information with additional details from parent Instruction and Initiation information as well as any supporting data provided for the execution
-
Create a valid Payment Request representing a single Payment Transaction
-
Send the created Payment Request to the Execution Service
-
Store the release progress in the local store to keep track of how far along the processing has gone for each instruction being processed
-
-
Finally, send a notification of completion to the data source to allow for any mop-up activities
| Fetching and processing the relevant Payment Transactions can (and should) be done in configurable sized batches to have a better performance. |
Release Transaction (Single Transaction Release)
To trigger the Transaction release process, you must provide the UnitOfWorkId of the stored Payment Transaction that should be sent for Execution.
After a trigger containing the Payment Transaction’s UnitOfWorkId and appropriate ProcessingActionType is received is received, the Payment Entries Processor will:
-
Retrieve stored Payment Transaction information
-
Retrieve relevant stored Payment Instruction information
-
Try to retrieve relevant stored Payment Initiation information if there is one present
-
Use the retrieved information to create a valid Payment Request representing a single Payment Transaction
-
Send the created Payment Request to the Execution Service
| Payment Entries Processor expects a Transaction to have a related Instruction in the data store. Payment Initiation information is not mandatory to be present This is required to create a payment request. See the processing request creator Concept page for further information on Payment Request creation. |
Structure
Payment Entries Processor consists of multiple modules:
-
core module holds a data agnostic implementation of resilient processing functionality
-
datasource module consisting of:
-
datasource-api module which specifies the contract for fetching payment information
-
datasource-warehouse module with reference implementation, providing payment data from the Payment Warehouse
-