Host-to-host card payments: when direct card data is worth the PCI cost

Some payment teams want the whole card payment in their own code: their screens, their servers, their logic, with a provider’s API behind it. Host-to-host (H2H) gives them that. It also moves card numbers onto their systems, and with them a PCI DSS workload that a hosted checkout avoids almost entirely.

This article compares H2H with hosted fields and hosted checkout, explains which self-assessment questionnaire (SAQ) each one points to, sets out what attestation costs in money and effort, and shows how secure tokens give most of the control with far less of the burden. It closes with when H2H is really worth it. For what SAQ A covers and what merchants still do under it, see our article on PCI DSS 4.0.1 and SAQ A. For the build effort on each side, see hosted checkout vs direct API integration.

What is a host-to-host card payment?

In an H2H card payment, the customer types their card details into a form you control. Your server receives them and sends them to the payment provider in an API call. The provider’s response comes back to your server. There is no hosted page, and no provider component on your site.

The attraction is control over every pixel and every step. A direct integration also means your own screens must handle authentication steps such as 3-D Secure, and your own systems now hold or pass through a card number, which is the fact that decides everything below.

How do H2H, hosted fields and hosted checkout compare?

The test is simple: who produces the payment form, and does the card number reach your systems? PCI SSC’s FAQ on direct post draws the first line. With an iframe or redirect, the provider produces the page that accepts card data. With a direct post, the merchant’s website produces some or all of it.

Integration	Who serves the card form	Card number reaches your servers	Usual questionnaire
Hosted checkout, by redirect or iframe	Provider	No	SAQ A
Hosted fields embedded in your page	Provider, field by field	No	SAQ A
Your own form posting straight to the provider	Your website, at least in part	No	SAQ A-EP
H2H with raw card data	You	Yes	SAQ D, or a Report on Compliance at Level 1
H2H with secure tokens	Provider, for the card entry step	No	Depends on how the token is created: confirm with your acquirer

Provider documents show the same map. Stripe’s PCI guide lists Checkout and Elements under SAQ A, an older Stripe.js form under SAQ A-EP, and a direct API integration under SAQ D. Checkout.com lists its hosted options and Frames under SAQ A, and its Full Card API on a merchant’s own platform under SAQ D.

These are the usual outcomes, not rulings. PCI SSC’s bulletin on the v4.0.1 SAQs tells merchants to confirm eligibility with the entity that receives the SAQ, which is usually the acquirer.

Which SAQ applies to H2H?

For raw card data, SAQ D for Merchants. PCI SSC’s form describes it as the questionnaire for merchants that are eligible to self-assess but do not meet the criteria of any other SAQ, and its examples include e-commerce merchants that accept cardholder data on their website. SAQ A-EP does not stretch to this case: the form is written for websites that do not themselves receive account data, and its criteria say the merchant does not electronically store, process or transmit any account data on its systems.

We read PCI SSC’s published v4.0 editions of both forms. Version 4.0.1 is current, and PCI SSC’s bulletin lists eligibility clarifications for SAQ A, A-EP and C-VT, but not for SAQ D. Check the current edition in PCI SSC’s document library before you file.

Volume can rule out self-assessment altogether. Stripe’s guide says Level 1 merchants need an annual Report on Compliance completed with a Qualified Security Assessor (QSA), and that at Level 2, SAQ A, A-EP and D must be signed by a QSA or an Internal Security Assessor. Confirm your own level with your acquirer.

What does attestation cost in money and effort?

More than the questionnaire suggests, because the form is the end of the work. The work is making its answers true.

The scope. Stripe says a business handling sensitive card data directly might have to meet more than 300 security controls, which can mean buying and maintaining dedicated security software and hardware and hiring external auditors. PCI SSC’s v4.0 SAQ D runs to 118 pages, against 84 for SAQ A-EP. Beyond the website controls in SAQ A-EP, it adds items such as making stored card numbers unreadable (3.5.1), protecting and managing cryptographic keys (3.6.1 and 3.7.1) and internal penetration testing (11.4.2).

The money. Published prices are vendor estimates, and they vary widely. Secureframe’s guide, which is undated, gives the following figures. Treat them as a planning guide, not a quote.

Item	Secureframe’s estimate
SAQ, general	USD 15,000 to 50,000
Report on Compliance, Level 1 enterprise	USD 50,000 to 200,000
ASV external scans	USD 150 to 200 per IP address a year
Internal vulnerability scanning	USD 3,000 to 5,000 a year
Penetration testing	USD 3,000 to 30,000

These are mostly external costs. The larger bill is often internal: engineering time to keep card data contained, reviews of every change to systems in scope, and staff who own the evidence all year. We found no reliable public figure for that, so estimate it from your own team.

The paperwork with each provider. Attestation is also a gate. Stripe says raw card data APIs are for businesses whose servers handle card data, and that they must provide documentation each year: a written description of the systems that handle card data, plus a current SAQ D or, for Level 1, an Attestation of Compliance for Onsite Assessment. Stripe accepts SAQ A only where a compliant third party handles the card data. Checkout.com asks SAQ D compliant merchants to contact its team before processing full card payments. Plan for this with every provider you connect directly.

The limits on what you can keep. PCI DSS Requirement 3.3.1 prohibits storing sensitive authentication data after authorisation, even if encrypted, and that includes the CVC. PCI SSC’s FAQ adds that PCI DSS sets no time limit for holding such data before authorisation, but it must be protected, and the payment brands decide whether it may be stored before authorisation at all. H2H gives you the card number. It does not give you the right to keep everything.

Can secure tokens replace raw card data?

Usually, yes, and for most teams this is the better design. A token stands in for the card number. Your backend sends the token, the provider or orchestration layer resolves it, and your systems never hold the real number.

The important question is where the card number first lands. Stripe’s guide to tokenisation makes three points that decide whether a token helps.

• Any system that handles a card number before it is tokenised stays in scope. If the number reaches your server first, even briefly, that server stays in a broader scope, however strong the tokenisation is afterwards.
• A token must be irreversible. If someone can calculate the card number from the token using known logic, it does not reduce scope.
• Tokenisation does not qualify you for SAQ A by itself. Stripe warns against assuming any tokenisation solution does. The vault also still needs full compliance, so a third-party vault must have its own PCI DSS validation.

So a token created in your own backend from a raw card number buys little. A token created by a provider-hosted field, before the number touches your systems, buys a lot. The customer still sees your page, your layout and your flow. The card entry itself runs on the provider’s component, and your server only ever sees the token.

Saved cards work the same way. If you want to compare provider tokens with scheme tokens, see network tokens vs PSP tokens. If moving tokens between providers matters to you, see card token portability.

When is H2H really worth it?

Work through these in order. If you answer no to all of the first group, you probably do not need raw card data.

Reasons that can justify it:

1. You already hold the attestation. If your business already validates at SAQ D or a Report on Compliance for other reasons, the extra cost of H2H is much smaller.
2. You need card numbers for a business function. Some operations need access to the number itself, and a token will not do. Name the function in writing. If you cannot, this reason does not apply.
3. You have a channel where a provider’s component cannot run. The test is a real technical blocker, not a preference.
4. You have the people. Someone must own scope, evidence and audits all year, not only at renewal.

Reasons that do not justify it:

• “We want our own design.” Hosted fields and secure tokens leave layout and flow in your hands.
• “We have a native app.” Stripe’s guide says its mobile SDK fits SAQ A if you use its official UI components.
• “We want several providers.” Orchestration connects them behind one integration, without card data on your servers.
• “It will raise approval rates.” We found no published evidence that sending raw card data from your own server raises approval rates by itself.

If you do choose H2H, keep the card data path as small as possible: separate it from the rest of your systems, and treat every log, trace and support tool as a possible leak.

What are the common mistakes?

• Filing the wrong SAQ. A server that receives card numbers does not fit SAQ A or A-EP, even if it passes them on and stores nothing.
• Assuming “we do not store it” ends the matter. PCI DSS covers transmitting and processing, not only storage.
• Treating encryption as an exit. Stripe says encrypted values still count as cardholder data.
• Tokenising too late. A token made on your server leaves that server in scope.
• Logging card data by accident. Request logs, error trackers and debugging tools can capture what passes through them.
• Keeping the CVC. Requirement 3.3.1 applies even if it is encrypted.
• Forgetting the yearly cycle. Attestations expire, and providers ask for current ones.
• Budgeting for the audit only. The cost that lasts is the work between audits.

What does Omno offer merchants who want their own card checkout?

Most merchants who look at H2H want their own checkout, not card data. Omno Card Fields give them that. You build your own branded checkout and embed three secure Omno card fields for card number, expiry and CVV, styled to match your page. Card data goes straight to Omno and never touches your servers. That can significantly reduce your PCI DSS scope, though your assessor decides your final level.

Each payment then follows your Omno routing rules. If a provider is unavailable or rejects the request, the payment moves to the next provider in the rule until one accepts. Shoppers stay on your checkout, although some card payments still need a 3-D Secure check with the bank.

If your company already holds its own PCI DSS attestation and needs raw card data, ask Omno about host-to-host processing.