Payment Processor

When an authorisation request leaves the acquirer, the processor routes it through the card network (Visa, Mastercard, etc.) to the issuing bank. The network applies interchange rules and scheme-level fraud checks; the issuer responds with approval or decline; the processor relays the response back through the chain to the merchant.

Beyond authorisation, the processor handles clearing, the end-of-day reconciliation of approved transactions into net settlement files, and coordinates with card networks to move funds from the issuing bank to the acquiring bank. This is the settlement leg of the transaction lifecycle.

Processors maintain connectivity to card network rails, keep BIN tables mapping card numbers to issuing banks, and handle message formatting per ISO 8583 or modern API equivalents. Their technical reliability and network reach directly affect transaction success rates.

Many processors also serve as acquirers or work closely alongside dedicated acquiring banks. The distinction between processor and acquirer matters most in markets where the two roles are held by separate regulated entities, as is common in parts of Europe and Asia.

Processing failures produce authorisation declines that are difficult to diagnose without granular reporting: processor timeouts look similar to issuer declines in summary reporting but require different responses.

Processor pricing is embedded in MDR but negotiable at volume. Direct processor relationships offer more cost transparency than layered arrangements where processor fees are bundled into an opaque margin.

Processor uptime and network redundancy determine whether transactions reach the issuer at all. Merchants should confirm their processor maintains primary and backup network paths for Visa and Mastercard.

Retry rules are governed at the processor level: processors must enforce card scheme retry restrictions. Merchants need visibility into retry behaviour to avoid inadvertent scheme rule violations and associated fines.