Payment Hub

The Payment Hub engine provides a centralized interface where you can view all requests that require integration with third-party systems. It allows you to analyze the responses received for each request and set up business retry rules based on those responses. Thanks to the integration orchestration within the FintechOS platform, you can easily adjust and update configurations. This streamlined approach also gives non-technical users better visibility into the process and system behavior.

Payment Hub Integration Setup

The payment hub engine allow you to orchestrate different integration with 3rd party systems, for example credit card payment processors. The engine works with events generated from different business flows. An event is a notification sent to the payment hub engine when an integration is needed. The events can be generated from different business flows, like invoice generation for new business or renewals, processes triggered by a credit card expiration, client asking to change the card details for a contract.

Before starting to generate events, you first need to configure the event types you will be working with on your environment, as for each event you will have to provide its type.

On event type level you can configure how the integration will be orchestrated - what is the action that will be executed for this type of events (Service Pipes APIs, FintechOS server side methods), when should the action be executed, mappings used by the engine to identify important details in the response objects returned to the engine - and the possible response codes you can receive from the 3rd party system as a response for your request.

The engine is able to support simple processes, where the response you get after initiating a call to the 3rd party system is the final one, or 2 steps processes, where the external system will notify the core solutions of changes happening for a particular request.

After the events are received by the engine and their initial actions are triggered, updates of the events can be received, as some 3rd party systems will send asynchronous updates that should be recorded on event level. The engine allow you to configure retry rules based on the response codes received in the update calls.

Additional details

Pay attention to the following aspects when configuring event types:

  • if Skip Payment Hub Processing = true, the Payment Hub engine will not execute the actions associated with the event; the processing of the event should be covered with custom logic;

  • you should configure either a Service Pipe Endpoint or a Server Side Library Name + Server Side Method as an action for the event type;

  • If Async = true, the event action will not be executed when the event is created (no matter what’s the event date); the job server FTOS_PH_ProcessAsyncEvents will execute the action when the event date is reached or when the other execution conditions are met;

  • if Async = false, the event action will be executed when the event is created only if the event date <= current date; if the event date > current date, the job server FTOS_PH_ProcessAsyncEvents will execute the action when the event date is reached;

  • the job serverFTOS_PH_ProcessAsyncEvents runs every 10 minutes and selects a batch of 500 records, ordered by event date

    • assuming the job will run at 13:00, 13:10, 13:20, an event with event date 13:02 will be processed at 13:10, if it is included in the 500 records batch.