Documentation for a newer release is available. View Latest
Esta página no está disponible actualmente en Español. Si lo necesita, póngase en contacto con el servicio de asistencia de Icon (correo electrónico)

Concepts

Payment notification flow diagram

① The Payment Notification Service listens to journal processor events on a Kafka topic. The pain.001 payment message and specific domain events (can be set in routing specification) are consumed and forwarded for further handling. All other messages and events are discarded.

② Upon receiving the initial pain.001 message, all relevant payment parameters are extracted and stored in a distributed cache using the unit of work ID (uowID) and persistenceId. Should the cache ever be lost due to a crash or restart, it can be rebuilt by querying the primary database.

③ Each domain event is routed into the core logic, which queries the configurable processing settings service for exact matches based on both the event’s name and the flow that generated it. It may find no matches or a single match.

The configurable processing settings allow the following pain.002 fields to be defined:

  • txSts

  • prtry

  • cd

  • addtlInf

Each matching configuration specifies how to transform the event into a payment status notification and the destination for that notification. The destination endpoints can be defined in the configurable processing settings. A single domain event can produce several distinct notifications, each tailored and directed according to its own transformation rules.

For every configuration found, the system creates a message bundle containing the original domain event, the specified transformation metadata, and default values for status (txSts), proprietary fields (prtry), code (cd), and additional information (addtlInf). These bundles are handed off to the “generate notification” component.

④ The generate notification message builds the pain.002 message. Most of the data is retrieved from cache. It uses the suffix of the persistence ID (everything after the “|” character) as the cache key. Next, it enriches the message with any configurable fields that have been defined. Finally, the fully assembled notification is published to the appropriate payment status notification topic (e.g. via ActiveMQ, Kafka, etc.), using both topic and transport details supplied by the same configurable settings service.

Further reading

  • Data Flows - The Notification Service essentially has two key data flows to show how various components are linked together to provide a solution which can produce notifications.

  • Resequencer - The Resequencer Pattern is used for reordering of messages before processing to ensure pain.002’s are published in the correct order.