Handling Payment Information
-
Payment Initiation details
-
Payment Instruction details
-
Payment Transaction details
Each of these concepts is represented by a dedicated interface within the Payment Releaser library:
package com.iconsolutions.ipf.core.releaser.shared;
import com.iconsolutions.ipf.core.shared.domain.context.ProcessingContext;
public interface PaymentInitiation<P> {
P getPayload();
ProcessingContext getProcessingContext();
}
package com.iconsolutions.ipf.core.releaser.shared;
import com.iconsolutions.ipf.core.shared.domain.context.ProcessingContext;
import com.iconsolutions.ipf.core.shared.domain.context.UnitOfWorkId;
public interface PaymentInstruction<P> {
P getPayload();
ProcessingContext getProcessingContext();
UnitOfWorkId getUnitOfWorkId();
UnitOfWorkId getInitiationUnitOfWorkId();
}
package com.iconsolutions.ipf.core.releaser.shared;
import com.iconsolutions.ipf.core.shared.domain.context.ProcessingContext;
import com.iconsolutions.ipf.core.shared.domain.context.UnitOfWorkId;
public interface PaymentTransaction<P> {
P getPayload();
ProcessingContext getProcessingContext();
UnitOfWorkId getInstructionUnitOfWorkId();
}
The Payment Releaser does not dictate specific Payload types.
The users of the library are responsible for implementing these interfaces with their desired Payload message types, ensuring alignment with payment representations throughout their systems.
Default Releaser Implementation
While the Payment Releaser does not enforce specific Initiation, Instruction, or Transaction message types, it provides default implementations of the interfaces above. These implementations are based on the ISO 20022 Payment Model, with Payloads represented by the following Java classes:
-
CustomerCreditTransferInitiationV09 -
PaymentInstruction30 -
CreditTransferTransaction34
Absorbing Payment Adjustments
Processing flows store initial payment details that remain in a pending state until they are selected for the releasing process and executed. During this pending period, payments may be cancelled or have specific details adjusted. Rather than modifying the original payment records, these changes are stored as separate update entries containing the adjustment details.
The Payment Datasource is responsible for incorporating and aggregating these additional adjustments, merging them with the original payment entry details to create a comprehensive payment record.
For a detailed explanation of the payment information aggregation process, please refer to /features/payment-info-aggregation.adoc.