Following completion of initial validations, the orchestration layer in the payment platform is designed to support a flexible and highly configurable sequence of processing steps. Each step represents a discrete validation, enrichment, decision, or action required to ensure the integrity, compliance, and successful delivery of a payment. These steps can be configured per customer, flow type, and instrument, and are executed in a modular and auditable fashion.
Below is a summary of the core orchestration steps available in the PagoNxt Payments Hub platform. These components enable the platform to enforce regulatory and business rules, interact with external systems, manage risk and compliance checks, and ensure successful routing, processing, and finalisation of payments:
Step Name | Step definition |
|---|---|
Semantic validation | Allow the application of CORE semantic validations to stop or continue the flow (eg. cancel request on a payment already returned) and Customer semantic validation (eg. customer account is valid). |
Payment enrichment | Enrich information required for the processing and scheme exchange of the payment. Eg. calculate routing, add settlement instructions, enrich parties data (LEI, BIC, accounts), etc. |
Supervision and authorisation | Ability to configure criteria based on the payment data to stop payments for manual investigation and 2, 4 or 6 eyes check. |
Fraud | Connect with fraud systems to validate the messages. |
Regulatory validation | Check regulatory validations, eg. payment data quality (EU847). |
FX | Connection to Forex exchange systems to calculate the exchange rate for those payments that are settled in a currency different than the customer currency. |
Accounting | Ability to call external systems to perform accounting posting on a payment. There could be several accounting steps inside the same flow (customer accounting, scheme accounting, reverse accounting, withhold, etc.). |
Screening | Connect with screening systems to validate the messages (sanctions, anti-money-laundering). |
Reachability | Check if the instructed agent or creditor agent of a payment is reachable in the scheme where the payment is going to be sent. This validation is performed against the reachability directories published in the industry. |
Scheme validation | Validate the payment meets the scheme format rules. Usually this check is performed against the XSD documents published by the different schemes plus a set of internal rules defined in the scheme connector. |
Send to scheme | Connection to internal scheme connectors that are connected with external schemes to interchange messages with the industry. |
Scheme response handling | Reception and handling different type the responses from the schemes (acknowledge, scheme acceptance, scheme rejection, etc.). |
Notification | Communication of payment status updates to external systems. |
Exception handling | Ability to deal with exceptions during the processing of the messages and send to an exception handler to be manually investigated. |
Payment finalisation | Determine when the processing of a payment is internally finished. |