What are hosted payment fields?

Hosted payment fields are card-entry controls supplied by a payment provider and embedded within a merchant's checkout. They can look like part of the surrounding form, but the sensitive input elements are delivered from the provider's environment, commonly through inline frames. The merchant usually designs the page around those fields and sends order details through its approved integration, while the provider handles the card data entered into the hosted controls.

How hosted fields fit into checkout

A hosted-fields checkout combines two layers. The merchant's page can contain the cart summary, customer details, shipping choices, labels, buttons, and overall layout. The payment provider supplies designated controls for information such as the card number, expiration date, security code, or postal code. The exact field set varies by product and configuration.

When the customer submits payment information, a provider's implementation may exchange the sensitive values for a temporary payment reference or token that the merchant's application can use in a later request. Braintree's current Hosted Fields documentation, for example, describes provider-rendered iframes and a one-time-use payment method nonce. That is one product example, not a universal protocol: merchants should follow the documentation for the provider and software version they actually use.

For the surrounding transaction sequence, see how online credit card payments work.

Hosted fields are not the same as every hosted checkout

Hosted payment fields

Selected payment inputs are embedded within the merchant's checkout. The merchant retains substantial control over the surrounding page, while the provider supplies the sensitive entry controls.

Fully hosted payment page

The customer is redirected to, or shown, a larger provider-hosted payment form. Authorize.net's current Accept Hosted documentation illustrates both redirect and embedded-form options.

Merchant-built card form

The merchant's page creates the card inputs and passes data according to the chosen integration. This is technically and operationally different from provider-hosted inputs.

Names are not perfectly consistent across providers. A product called hosted checkout may be a full page, while another product may inject separate hosted controls. Ask for a data-flow diagram and inspect the implementation guide instead of deciding from the marketing name alone.

What the merchant still controls

Hosted fields do not turn the rest of checkout into a provider-managed experience. The merchant may still control the page's content, scripts, order total, accessibility, error messages, submit behavior, confirmation flow, analytics, and connections to inventory or order systems. Those responsibilities make implementation quality important.

Clear labels: each visible field needs an understandable label, instructions, and error state.
Responsive layout: the embedded controls and their containers need to remain usable at mobile, tablet, and desktop widths.
Submission control: disable repeated submissions where appropriate and connect every order to durable transaction references.
Failure handling: plan for field-loading errors, validation errors, interrupted sessions, declines, and uncertain order states.
Change management: review checkout scripts and provider SDK updates through a documented release process.

The Ecommerce & Online Payments FAQ provides more national, provider-neutral planning guidance.

Security scope requires verification

Hosted fields can change where card data is collected, but embedding them does not by itself prove that a merchant has met any security standard. PCI Security Standards Council guidance explains that, for a merchant evaluating SAQ A eligibility with an iframe, all fields and web elements associated with capturing payment card data must be contained within the provider-supplied iframe, along with the other eligibility criteria. PCI SSC also emphasizes current payment-page protections against unauthorized scripts and changes.

That distinction is why a merchant should not rely on a screenshot, product name, or sales statement. Confirm which party delivers every payment-page element, whether merchant code can access sensitive values, which scripts execute on the checkout, how the integration returns a safe reference, and what ongoing controls apply. The merchant should obtain written scope guidance from its acquirer, payment provider, and qualified security adviser for its actual environment.

Hosted fields may reduce a merchant application's direct exposure to raw card details when implemented as documented, but the merchant website, access controls, checkout code, and operational procedures still require protection. Never copy full card numbers, security codes, passwords, bank credentials, or secret API keys into analytics, logs, support tickets, chat, email, or general contact forms.

Questions to ask before choosing an approach

Which exact fields are hosted, and from whose domain are they delivered?
Does the merchant's browser or server ever receive raw card data?
What payment reference is returned, how long is it usable, and what may it be used for?
Which checkout layouts, browsers, devices, and accessibility behaviors are currently supported?
How are loading, validation, duplicate submission, and network errors presented to customers?
Who owns monitoring, software updates, script review, incident response, and provider-status checks?
What documentation supports the merchant's security-scope determination for this exact configuration?

Merchants can place these answers beside the broader roles described in how credit card processing works.

A practical evaluation path

Start with a checkout diagram showing the customer browser, merchant page, hosted controls, merchant server, provider endpoint, and order system. Mark the owner of each element and the direction of every data exchange. Next, test the checkout with ordinary success and error scenarios using the provider's designated test environment. Check keyboard navigation, focus, readable error feedback, mobile behavior, interrupted submissions, and the handoff from payment response to order status.

Finally, compare the observed flow with current provider documentation and the merchant's security review. Do not assume a field is provider-hosted merely because it is visually styled like the other hosted controls. A reliable review follows the source, behavior, and data path of each element.

If token references are part of the chosen flow, the wallet tokenization overview offers useful background while keeping wallet-specific and hosted-field implementations distinct.

Common questions

Can hosted payment fields match a merchant's design?

Often, within the options a provider exposes. The outer containers and page layout may be merchant-controlled, while allowed styles inside the hosted fields depend on the specific SDK. Verify responsive and accessibility behavior rather than assuming every CSS rule will cross the frame boundary.

Do hosted fields guarantee PCI compliance?

No. A hosted-fields product can be part of a reduced-scope design, but eligibility and compliance depend on the complete implementation and all applicable criteria. Confirm the environment with the merchant's acquirer, provider, and qualified adviser.

Are hosted fields the same as a payment gateway?

No. Hosted fields describe a way to collect payment details within checkout. A gateway or payment service may offer hosted fields, but the visible inputs are only one part of the broader transaction workflow.

Map the fields before selecting the integration

Identify which checkout elements the provider hosts, which elements the merchant controls, and what data crosses each boundary. Then verify supported behavior, security scope, accessibility, and error handling against current documentation for the exact product version. Payments Max can help organize evaluation questions without claiming that any one integration fits every merchant.

Explore ecommerce payment guidance

Privacy reminder: do not send cardholder data, passwords, bank credentials, complete account numbers, or secret API keys through a general contact form.

To learn more about how TSYS can help improve the way your organization accepts payments, markets to new customers, or manages its HR responsibilities, get in touch by calling 585-981-8463 to get started.