Payment Channels, Hubs, Engines and Gateways

Payment channels are the points where customers and businesses start a payment. The most common channels are internet banking, mobile banking, branch counters, call centres, and corporate file upload systems. Newer channels include chatbots, voice assistants, and application programming interfaces that let a corporate treasury system send payments directly. Each channel has its own user experience and its own security, but they all produce the same thing, a payment instruction that the platform must process. The BA documents the channel requirements separately, because the mobile app needs a different journey from a bulk file upload, even though both end up in the same hub. The payment hub is the central routing and orchestration layer, and it is the heart of the platform. The hub receives payment instructions from all channels, validates them against common rules, enriches them with data from the core banking system, and decides which engine should handle each one. The hub also manages the overall state of each payment, so it knows whether a payment is received, validated, screened, sent, or completed. This central state is what lets the bank give a customer a single view of a payment, no matter which channel started it. Without a hub, each channel would need its own tracking, and the customer experience would be inconsistent. Payment engines are the processing units that apply the business logic for a specific payment type. A typical platform has separate engines for domestic transfers, cross-border payments, card payments, direct debits, and bulk payments. Each engine knows the rules for its payment type, such as the message format, the clearing system, the cut-off times, and the fee structure. The cross-border engine, for example, knows how to handle currency conversion, correspondent banking charges, and SWIFT message formats, while the domestic engine knows the local clearing rules. The BA documents the rules for each engine as a separate set of requirements, which keeps the design clean. Gateways and connectors are the layer that talks to the outside world. A gateway takes the internal payment message and converts it into the format the external system expects, such as an ISO 20022 pacs.008 message for a clearing system or for a cross-border correspondent payment under CBPR+. The gateway also handles the communication protocol, the security certificates, and the acknowledgement messages that confirm receipt. When an external system changes its format, only the gateway needs to change, which protects the rest of the platform. The BA works with the gateway team to document the message mappings, and these mappings are some of the most detailed documents in a payments project. The message flow between the four layers follows a clear sequence that a BA should be able to draw on a whiteboard. The channel captures the instruction and sends it to the hub. The hub validates, enriches, and routes it to the right engine. The engine applies the business rules and passes the payment to the gateway. The gateway converts the format and sends it to the clearing system or correspondent bank. The response travels back through the same layers in reverse, and the hub updates the payment status at each step. If any layer fails, the hub knows exactly where the payment stopped, which makes investigation and recovery far easier than in the old siloed systems. For example, a manufacturer in Pune pays 200,000 rupees to a supplier through the corporate banking portal. The portal, which is the channel, sends the instruction to the hub. The hub validates the payment and routes it to the cross-border engine, because the supplier is overseas. The engine applies the currency conversion rules and passes the payment to the gateway, which converts it into the format the correspondent bank expects and sends it onward. The confirmation then travels back through the same layers, and the hub updates the payment status at each step.