H2H banking explained: host-to-host connections and H2H processing

Short answer: H2H banking (host-to-host) is a direct, automated connection between a company's systems and its bank, used to send payment files and receive statements without logging into online banking. In payment processing, "H2H" has a second meaning: a server-to-server API integration between a merchant and a payment provider, where the customer never leaves the merchant's checkout. Both share the same idea, system talking to system, but they solve different problems and carry different security and compliance duties.

This glossary article explains both meanings, the technologies behind them, when each makes sense and what to check before you build one.

H2H in corporate banking

In corporate banking, a host-to-host connection links a company's ERP, treasury or accounting system directly to the bank's back office. Instead of uploading payment batches manually through an online-banking portal, the company's system sends files automatically and receives status reports and statements back.

Typical flows over a banking H2H channel:

• Outgoing payments: supplier runs, payroll and refunds sent as payment initiation files.
• Status reports: acknowledgements and rejections for each payment.
• Statements: end-of-day and intraday account statements for reconciliation.
• Notifications: credit and debit advices as funds arrive or leave.

Common formats and protocols

• ISO 20022 XML: pain.001 for credit transfer initiation, pain.002 for payment status reports, camt.053 for end-of-day statements and camt.054 for debit and credit notifications.
• Legacy SWIFT MT formats: MT940 and MT942 statements are still widely used.
• Transport: SFTP with file-level encryption and signing (often PGP), bank-specific APIs, EBICS in several European countries, and SWIFT FileAct for multi-bank corporates.

When banking H2H makes sense

• You make many payments a day and manual uploads create errors or delays.
• You need intraday visibility of balances and incoming funds for treasury or liquidity planning.
• You run payouts at scale, for example a marketplace or payment provider settling to merchants.
• You want straight-through reconciliation between bank statements and your ledger.

The trade-offs are set-up effort and responsibility: certificates, key rotation, file validation and monitoring become your job. Many companies start with one bank and later add a multi-bank connectivity provider.

H2H in payment processing

In the payments industry, and especially among PSPs and P2P processors, "H2H" describes an integration in which the merchant's server calls the provider's API directly and renders the payment interface itself. The customer stays on the merchant's site or app, and the provider returns payment details or a result through the API and webhooks.

This contrasts with:

• Hosted payment page (HPP): the customer is redirected to a page operated by the provider.
• Embedded fields or SDK: the provider's components sit inside the merchant's checkout but collect sensitive data on the provider's side.

Advantages of H2H processing

• full control of the checkout design, language and flow;
• fewer redirects, which can improve conversion on mobile;
• easier to combine several providers behind one cashier;
• richer data for routing and anti-fraud decisions.

Responsibilities that come with it

• PCI DSS: if card data passes through your servers, you are in full PCI DSS scope. Many merchants use H2H only for non-card methods such as bank transfers, wallets or local methods, and keep cards on hosted fields.
• Security: request signing, IP allow-lists, secret rotation and webhook verification are mandatory.
• Error handling: timeouts, retries and idempotency keys must be designed so that a retry never causes a double payment.
• Support: without a provider-hosted page, your support team must explain statuses and failures to customers.

You can find providers that offer server-to-server integration in the H2H processing section of the catalog, alongside card acquiring and gateways and P2P processing.

Security architecture of an H2H channel

Whichever meaning applies, a production H2H channel usually combines several layers of protection:

• Mutual authentication: client certificates or SSH keys on both sides, so each system knows exactly who it is talking to.
• Message integrity: digital signatures on files or request bodies (for example PGP for bank files, HMAC signatures for API calls and webhooks), so a changed amount or account number is detected.
• Encryption: TLS for transport and, for bank files, encryption of the file itself so it remains protected at rest on intermediate servers.
• Network controls: fixed IP addresses, allow-lists and, for banks, sometimes dedicated VPN tunnels.
• Segregation of duties: the person who creates a payment batch should not be the person who approves and releases it; many companies keep a dual-approval step even when the transport is automated.
• Audit trail: every file, request and response stored with timestamps and hashes, so disputes and reconciliation breaks can be investigated later.

Moving from manual uploads to H2H: a step plan

1. 1.Inventory current flows: which payments, statements and notifications you exchange today, with volumes and cut-off times.
2. 2.Pick the first flow: statements are a low-risk start because they are read-only; outgoing payments come next.
3. 3.Agree the specification with the bank or provider: format versions, field mapping, character sets and naming rules.
4. 4.Build validation before transmission: reject a file locally if totals, IBANs or currencies do not match your ledger.
5. 5.Run in parallel: keep manual uploads as a fallback for several cycles and compare results.
6. 6.Switch over and monitor: alerts for missing statements, rejected files and unusual totals.

Banking H2H vs processing H2H at a glance

• Who connects: a company and its bank, versus a merchant and its payment provider.
• Main purpose: sending payment files and receiving statements, versus accepting customer payments and payouts in real time.
• Typical formats: ISO 20022 and MT files over SFTP or EBICS, versus JSON over HTTPS APIs with webhooks.
• Key risks: file tampering and key management, versus card-data scope, duplicate payments and webhook spoofing.

Checklist before building an H2H integration

1. 1.Confirm which meaning your counterparty uses. "H2H" in a bank proposal and in a PSP price list are different products.
2. 2.Get the full specification: formats, endpoints, authentication, environments and cut-off times.
3. 3.Decide who holds keys and certificates, and how they are rotated.
4. 4.Design idempotency and reconciliation first, not after launch (see webhook duplicates and event order).
5. 5.Agree on monitoring and incident contacts on both sides.
6. 6.Test failure scenarios: rejected files, partial batches, timeouts and late statuses (payment integration test matrix).
7. 7.For card payments, confirm your PCI DSS scope before choosing H2H over hosted fields.

FAQ

What does H2H mean in banking?

Host-to-host: a secure, automated connection between a company's systems and its bank for sending payment instructions and receiving statements, usually via SFTP, EBICS or bank APIs using ISO 20022 or MT formats.

What is H2H processing?

A server-to-server integration between a merchant and a payment provider, where the merchant shows its own checkout and communicates with the provider through an API instead of redirecting the customer to a hosted payment page.

Is H2H more secure than a hosted payment page?

Not automatically. A hosted page moves much of the security burden to the provider. H2H gives more control but makes you responsible for securing data, keys and messages.

Do I need PCI DSS for H2H?

If cardholder data passes through your systems, yes, at the full scope. For non-card methods, PCI DSS may not apply, but security obligations from your provider's contract still do.

Where can I find H2H providers?

Browse the H2H processing section on Nominal hub and compare providers' methods and regions. For bank connectivity, look at business account and BaaS providers.