Valid Pain.001 messages

The sample application uses the same process to handle all of the valid pain.001 test messages because the only difference between the messages is the number of transactions in the batch. This section uses the test message in the pain.001.001.03_3Pmts.xml file to describe the process for all of the valid pain.001 messages.

The message in this file is a Pain.001.001.03 message with a single PmtInf that contains three CdtrTrfTxInf elements. When this is mapped to ISF, there will be a batch of three payment origination transactions.

After submitting the Pain.001.001.03 message, you should be able to search for and list the transmission, transaction, and batch objects. Transmission search results: three payment batch shows the search results for the transmission objects. Transaction search results: three payment batch shows the search results for the transaction objects. Batch search results: three payment batch shows the search results for the batch objects.

Note: Before submitting the larger messages, validate the operation using the small messages. The larger messages may, depending on the system hosting FTM, take a long time to process and may also require database configuration or tuning changes to support successful processing. The database must have enough space allocated to store all the data, be configured to auto extend the space allocation, or both. Also, consider the database transaction log size because larger batches demand a significantly larger unit of work when mapping the inbound batch.

Figure 1. Transmission search results: three payment batch

Figure 2. Transaction search results: three payment batch

Figure 3. Batch search results: three payment batch

Payment origination batch: state history shows the state transitions for the batch object. These state transitions should relate to the ones defined in Payment origination batch: basic lifecycle.

Figure 4. Payment origination batch: state history

Figure 5. Payment origination batch: basic lifecycle

Reviewing the details of all the objects and their relationships shows that they are very similar to the single payment case in Object relationships - batch payment. The most noticeable difference for the batch case is that the acknowledgment sent to the client is now related to the batch object because there is a single acknowledgment per batch. Payment origination batch: related objects shows the related objects for the batch.

Figure 6. Object relationships - batch payment

Figure 7. Payment origination batch: related objects

Payment origination batch: extended values shows that the batch mapper stores computed batch totals as additional data that can be viewed on the extended values tab.

Figure 8. Payment origination batch: extended values