Payment Gateway Types: Hosted, API-Based, Redirect, and Integrated Checkout Explained

A payment gateway can connect a business to payment infrastructure in several different ways. The customer might complete payment on a separate hosted page, remain on the merchant’s website, or interact with a checkout built directly into an application.

These differences are not necessarily about how the payment is ultimately processed. They are primarily about how payment functionality is integrated into the customer experience and the merchant’s technology. Understanding these payment gateway types helps businesses choose an implementation approach that fits their technical resources, checkout requirements, and desired level of control.

What Are Payment Gateway Integration Types?

A payment gateway integration determines how a merchant’s website or application connects customers to payment functionality.

The most common approaches include hosted payment pages, redirects, embedded checkout, hosted fields, and API-based integrations. Some providers combine several of these approaches.

The important distinction is that the integration model is not the same thing as the payment gateway itself. Two businesses can use the same gateway while presenting payment to their customers in completely different ways.

For example, a small online retailer might use a provider-hosted checkout, while a large SaaS platform could use APIs and embedded payment components. The underlying payment infrastructure can be similar. The customer experience and technical responsibilities are different.

Hosted Payment Pages

A hosted payment page is a payment interface operated within the payment provider’s environment.

The customer begins the purchase on the merchant’s website and is directed to a payment page where they enter their payment information and complete the transaction.

Consider an online store selling a $300 television.

The customer adds the product to their cart and clicks Continue to Payment. Instead of entering card details directly into the store’s checkout, the customer is taken to a hosted payment page. After completing the transaction, they may be returned to the merchant’s website.

This approach can reduce the amount of payment-interface development required from the merchant. It can also help separate sensitive payment-data collection from the merchant’s own application, depending on how the provider’s solution is designed. The main trade off is control. A merchant may have fewer options for customizing the payment interface and customer journey than with a deeply integrated solution.

Redirect-Based Checkout

A redirect-based checkout moves the customer from the merchant’s website or application to another payment environment to complete a transaction.

The basic journey is:

Merchant Checkout → Payment Environment → Payment Result → Merchant

Redirects and hosted payment pages are closely related, but they describe slightly different aspects of the experience. A hosted payment page refers primarily to where the payment interface is hosted. A redirect describes how the customer is moved from one environment to another.

For example, a customer might click Pay Now, leave the merchant’s checkout, complete authentication or payment on another page, and then return to the merchant’s website.

The simplicity of this model can be attractive to businesses with limited development resources. However, the transition away from the merchant’s own checkout can make the payment journey feel less integrated.

Embedded Checkout

An embedded checkout keeps the payment experience within the merchant’s website or application. Instead of sending the customer to a separate page, payment fields can appear as part of the merchant’s existing checkout.

Imagine an ecommerce website with:

Shipping Address
↓
Payment Details
↓
Review Order
↓
Place Order

The customer remains within the same overall interface throughout the process. This can provide greater control over branding, layout, and the overall customer journey.

However, an embedded payment experience does not automatically mean that the merchant’s application handles raw payment credentials itself. Depending on the implementation, secure components supplied by the payment provider can handle sensitive fields while the merchant controls the surrounding interface.

That distinction matters when evaluating security and compliance responsibilities.

Hosted Fields

Hosted fields provide a middle ground between a fully hosted checkout and a completely merchant-built payment form. The merchant can design the surrounding checkout while the payment provider supplies secure fields for sensitive information such as card details.

For example, a merchant might control the entire visual layout of its checkout but use provider-managed fields for:

• Card number
• Expiration date
• Security code

From the customer’s perspective, these fields can look like part of the merchant’s website. Technically, however, the sensitive input can be handled by the provider’s infrastructure rather than passing directly through the merchant’s application. This approach can offer a useful balance between customization and specialized payment-data handling.

The exact technical and compliance implications vary by implementation, so businesses should examine the provider’s architecture rather than assuming every hosted-field solution works identically.

API-Based Payment Integration

An API-based payment integration allows a merchant’s software to communicate programmatically with payment infrastructure.

Instead of relying primarily on a predefined checkout page, the application can send payment-related requests through an API and receive structured responses.

A simplified flow might look like:

Customer → Merchant Application → Payment API → Payment Infrastructure → Response → Merchant Application

Imagine a SaaS company charging customers $49 each month. Its application could use an API to initiate a payment-related action, receive the result, update the customer’s account, and respond to subsequent payment events.

The major advantage is flexibility. Developers can build payment functionality around the application’s existing workflows and user experience. The tradeoff is greater technical responsibility. API-based implementations typically require developers to manage authentication, requests, responses, error handling, testing, and appropriate security practices.

Which Payment Gateway Type Is Right for a Business?

There is no single payment gateway integration that is best for every business.

• A small ecommerce company with limited development resources may prefer a hosted payment page because it can simplify implementation.
• A growing retailer may prefer embedded checkout or hosted fields because maintaining a consistent customer experience is important.
• A SaaS company with an established engineering team may choose an API-based approach because payment functionality needs to interact closely with its own software.

The decision should therefore begin with the business’s requirements. Important considerations include:

• How much checkout customization is needed?

• How much development capacity is available?

• How important is a seamless branded experience?

• Which payment methods need to be supported?

• What security and compliance responsibilities will the merchant assume?

• Does payment functionality need to interact closely with internal software?

• How much flexibility will the business need as it grows?

These factors also become important when choosing a payment gateway.

A Simple Example

Consider three businesses selling a $100 product.

• Business A has a small technical team and wants a straightforward implementation. It chooses a hosted payment page.
• Business B wants customers to remain on its website throughout checkout. It uses embedded payment functionality with hosted fields.
• Business C operates a large software platform and needs payment functionality to interact with its internal systems. It chooses an API-based integration.

All three businesses can connect customers to payment infrastructure.

What changes is how that connection is implemented and how much control the merchant has over the payment experience.

This is why the question should not simply be, “Which payment gateway is best?” A better question is:

“Which integration model fits the way this business operates?”

Does the Integration Model Affect Security?

It can affect where payment information is collected and which systems handle it.

• With a hosted payment page, sensitive payment information may be collected within the provider’s environment rather than directly by the merchant’s application.
• With hosted fields, sensitive fields can be supplied and managed through provider-controlled components while the merchant controls the surrounding checkout.
• With an API-based architecture, the merchant’s development environment may have more responsibilities around authentication, secure communication, credentials, and data handling.

None of these models is automatically secure or insecure. Security depends on the provider’s architecture, the implementation, configuration, access controls, and the merchant’s own practices.

Payment Gateway Type vs. Payment Gateway Provider

Another important distinction is between the gateway provider and the integration model.

Choosing a provider does not necessarily lock a business into one checkout architecture. A provider may offer hosted checkout, embedded components, hosted fields, APIs, or several of these options. Therefore, businesses should evaluate both questions separately:

Which payment infrastructure meets our requirements?

and

How should that infrastructure be integrated into our website or application?

The second question becomes especially important when moving from an implementation decision to the actual technical process. 

The Bottom Line

Payment gateway types primarily describe how payment functionality is presented and connected to a merchant’s website or application.

Hosted and redirect-based approaches generally prioritize simplicity. Embedded checkout and hosted fields provide greater control over the customer experience while using provider-managed payment components. API-based integrations offer extensive flexibility but usually require greater technical involvement.

There is no universally superior model. The right approach depends on the business’s technical capabilities, checkout requirements, desired level of customization, security responsibilities, and long-term needs.

Understanding these differences allows a business to evaluate payment integrations based on how they actually work – not simply on the labels used to describe them.