Payment Gateway Integration in 2026: API, Hosted Checkout, and SDK Options Compared for E-Commerce Merchants

Call Bridge Capital Partners now: 866-305-6454

Choose the payment gateway integration path before development begins.

The decision affects:

• Checkout control.
• Conversion management.
• Development time.
• Online credit card processing.
• Recurring billing.
• Refund handling.
• Fraud controls.
• PCI DSS scope.
• Merchant account underwriting.
• Long-term operating costs.

Three options dominate e-commerce builds in 2026:

1. Direct API integration.
2. Hosted checkout or hosted payment page.
3. SDK, hosted fields, or drop-in components.

Each option solves a different business problem.

The lowest-friction option is not always the best option. The most flexible option is not always the safest option. The right choice depends on how card data moves through the customer journey and your technology environment.

Start with the payment data path

Do not select an integration based only on the user interface.

Map the card data path first.

Ask these questions:

• Where does the customer enter card details?
• Does the browser send card data directly to the payment provider?
• Does the merchant server receive the card number?
• Does merchant-controlled JavaScript run on the payment page?
• Does the gateway return a token or raw payment data?
• Does the system support recurring billing?
• Does the system handle refunds and partial refunds?
• Does the merchant need a custom checkout?
• Does the merchant operate in a high-risk industry?
• Which party confirms PCI scope?

A payment gateway transmits payment information for authorization. A processor handles transaction processing. An acquiring bank supports settlement. A merchant account supports the business relationship that allows card acceptance.

These functions may be provided through one connected stack. They are not the same function.

Review the payment gateways and credit card processing options before selecting a development path.

Comparison at a glance

Integration path	Customer payment experience	Raw card data on merchant server	Typical PCI direction	Development effort	Checkout control
Hosted redirect	Customer leaves the store for a provider-hosted page	No	Often SAQ A, subject to eligibility	Low	Low
Hosted payment page or hosted fields	Payment experience is hosted or embedded by the provider	Usually no	SAQ A or SAQ A-EP, depending on implementation	Low to medium	Medium
SDK or drop-in component	Payment fields appear inside the merchant checkout	Usually no	Often SAQ A-EP, subject to eligibility	Medium	High
Direct API with server-side card handling	Merchant controls the full payment flow	Yes	SAQ D direction	High	Very high
Direct browser-to-gateway tokenization	Merchant page starts the payment flow; provider receives card data	No	Commonly SAQ A-EP direction	Medium to high	High

The table is a planning tool. It is not a compliance determination.

PCI SSC eligibility criteria apply to the complete environment. The acquiring bank or payment brand may require additional validation.

Option one: direct API integration

A direct API integration connects the merchant application to gateway endpoints.

The merchant controls the transaction request. The application may create an authorization, capture a payment, issue a refund, store a token, or manage recurring billing.

The phrase “direct API” describes a technical connection. It does not automatically describe the PCI scope.

The critical question is whether raw card data reaches the merchant environment.

Server-side card handling

In the highest-scope model, the customer submits card details to the merchant’s website. The merchant server receives the data. The server then sends the card data to the gateway.

The merchant environment transmits cardholder data.

This creates a broad cardholder data environment. The merchant must address the applicable PCI DSS controls for systems that store, process, or transmit account data.

This model generally points toward SAQ D or a Report on Compliance, depending on the merchant’s validation level and acquiring requirements.

Expect requirements involving:

• Network security.
• Access control.
• Encryption.
• Key management.
• Vulnerability management.
• Secure software development.
• Logging.
• Monitoring.
• Incident response.
• Administrative access.
• Data retention.
• Segmentation.
• Testing.
• Change control.

Avoid this architecture unless the business has a clear reason to retain that level of control.

Potential reasons may include:

• A specialized legacy system.
• A complex enterprise orchestration layer.
• A controlled call-center environment.
• A proprietary payment workflow.
• A regulated operational requirement.
• A need to connect multiple payment systems through a central server.

Even in these cases, tokenization should be evaluated before raw card data is accepted.

Browser-to-gateway API tokenization

A different model uses a merchant-hosted checkout page. The browser collects card information through a payment provider’s JavaScript or API. The payment provider returns a token. The merchant server receives the token, not the raw card number.

This reduces exposure to raw card data.

It does not remove all compliance obligations.

The merchant controls the payment page. Merchant scripts may affect the page. Third-party analytics, tag managers, plugins, and content-management systems may also affect the payment flow.

This arrangement often moves toward SAQ A-EP rather than SAQ A. Confirm the final classification with the acquirer and the provider.

Advantages of direct API integration

Direct API development can provide:

• Full control over payment states.
• Custom authorization and capture logic.
• Flexible order management.
• Custom recurring billing.
• Multi-step payment workflows.
• Complex refund rules.
• Custom fraud review.
• Detailed transaction metadata.
• Integration with enterprise resource planning systems.
• Integration with subscription platforms.
• Custom reconciliation.
• Multi-gateway routing.
• Custom customer-service tools.

The merchant can design the payment system around its business model.

Risks of direct API integration

The risks are also substantial.

Common problems include:

• Larger PCI scope.
• Longer development cycles.
• More testing requirements.
• Higher security responsibility.
• More complex incident response.
• Poor handling of failed transactions.
• Duplicate charges.
• Incorrect retry behavior.
• Weak webhook verification.
• Incorrect refund states.
• Incomplete reconciliation.
• Exposure from server logs.
• Accidental storage of sensitive data.
• Greater reliance on internal developers.

A direct API also creates operational responsibility after launch. The merchant must maintain the integration when the gateway changes an endpoint, authentication method, webhook format, or security requirement.

Use direct API when control justifies the burden

Choose direct API development when the business needs a custom payment engine and has the resources to secure it.

Do not select it only because it appears more professional.

A custom payment page does not automatically improve conversion. It can introduce more failure points. It can also create more PCI responsibility.

For most small and mid-sized e-commerce merchants, tokenization through a provider-controlled component offers a better balance.

Option two: hosted checkout and hosted payment pages

Hosted checkout places the payment page on the gateway or processor’s environment.

The customer may leave the merchant website. The payment provider handles the card-entry page. The merchant receives transaction results and may receive a token for future use.

A hosted page can use a full redirect, a payment link, or a provider-hosted checkout session.

Full redirect

The customer selects checkout. The merchant sends the customer to a payment page hosted by the provider.

The provider controls the payment form.

The customer submits card information on the provider’s page. The provider returns the customer to the merchant after payment or sends a status update through a webhook.

A full redirect commonly supports the lowest PCI scope among the three primary paths. It often aligns with SAQ A when all eligibility requirements are met.

The merchant still must secure its own website and verify the provider’s compliance status. The merchant also must confirm that its implementation matches the provider’s documented method.

Hosted payment link

A payment link can be created for:

• One-time purchases.
• Invoices.
• Deposits.
• Service appointments.
• Membership fees.
• Telephone orders.
• Customer balances.
• Manual payment requests.

Payment links reduce development effort.

They may not support a fully customized shopping cart. They may also provide less control over product selection, fulfillment logic, and post-payment workflows.

Use a payment link when speed and operational simplicity matter more than a fully integrated checkout.

Hosted page advantages

Hosted checkout can provide:

• Faster deployment.
• Lower development cost.
• Reduced raw card-data exposure.
• Provider-managed payment fields.
• Mobile-ready layouts.
• Built-in payment method support.
• Standard fraud controls.
• Standard error handling.
• Easier gateway updates.
• Clear separation between merchant and provider systems.

Hosted checkout can also help a startup begin processing without building a payment system from scratch.

Hosted page limitations

The tradeoffs include:

• Less control over checkout design.
• A domain change during payment.
• Possible customer confusion.
• Reduced control over page performance.
• Less flexibility for custom offers.
• Limited payment-state customization.
• Dependence on provider availability.
• Potentially weaker brand continuity.
• More difficult experimentation.

A redirect can create friction when the customer does not recognize the provider domain. The checkout page must explain the transition clearly.

Use consistent branding. Display the business name. Explain the payment step. Return customers to a clear confirmation page.

Hosted checkout and recurring billing

Hosted checkout may support subscriptions and recurring transactions.

Confirm the following before implementation:

• Whether the provider stores a payment token.
• Whether the merchant receives only the token.
• Whether the token can be used for recurring payments.
• Whether customer consent records are retained.
• Whether the first transaction is marked correctly.
• Whether recurring transactions use the required indicators.
• Whether customers can update payment details.
• Whether failed recurring payments trigger retries.
• Whether customers receive cancellation controls.
• Whether refunds can be issued against recurring charges.

Do not assume that a one-time hosted payment page supports a complete subscription operation.

Recurring billing requires customer communication, cancellation procedures, retry controls, and accurate account records.

Hosted checkout for high-risk merchants

A high-risk merchant account may require additional underwriting before the gateway is activated.

The provider may review:

• Product or service category.
• Customer acquisition method.
• Average ticket.
• Maximum ticket.
• Monthly volume.
• Refund policy.
• Delivery timeline.
• Recurring billing.
• Chargeback history.
• Countries served.
• Supplier information.
• Website terms.
• Marketing claims.
• Fulfillment process.

A hosted payment page does not remove underwriting requirements.

It also does not remove chargeback exposure.

Review the high risk merchant account process before selecting the integration.

Option three: SDK, hosted fields, and drop-in components

SDK and drop-in integrations place provider-managed payment functionality inside the merchant’s checkout.

The customer remains on the merchant website or application. The payment fields may appear as embedded components. The provider’s code sends card data directly to the provider and returns a token or payment method reference.

This approach gives the merchant more control than a full redirect.

It generally requires more planning than a hosted page.

Hosted fields

Hosted fields are payment inputs controlled by the provider.

The merchant may control:

• Page layout.
• Labels.
• Button placement.
• Error placement.
• Product summary.
• Shipping details.
• Promotional messaging.
• Checkout sequencing.

The provider controls the sensitive payment fields.

This separation can reduce exposure to raw card data. It does not necessarily qualify the merchant for SAQ A.

The final scope depends on the implementation, scripts, page security, provider documentation, and acquirer interpretation.

Drop-in components

A drop-in component is a packaged payment interface.

It may provide:

• Card fields.
• Wallet buttons.
• Saved-payment selection.
• Billing address collection.
• Postal-code validation.
• Error handling.
• Loading states.
• Payment confirmation.
• 3-D Secure support.
• Token creation.
• Payment method selection.

Drop-in components can reduce development time while preserving a branded checkout.

They can also limit deep customization.

Mobile SDKs

Mobile SDKs support payment flows inside native applications.

The merchant must review:

• SDK permissions.
• Key management.
• Mobile release controls.
• Certificate handling.
• Application integrity.
• Token storage.
• Device security.
• Deep-link behavior.
• Refund access.
• Customer authentication.
• App update procedures.

A mobile SDK does not automatically eliminate PCI scope.

The app may still affect payment security. Confirm the applicable questionnaire and responsibilities before launch.

SDK advantages

SDKs and drop-in components can provide:

• Stronger brand continuity.
• Better checkout control.
• Faster implementation than raw API development.
• Provider-managed sensitive fields.
• Tokenization.
• Wallet support.
• Standard validation.
• Standard payment states.
• Support for mobile and web.
• Easier upgrades than a fully custom payment engine.

This is often the practical middle path for e-commerce merchants.

SDK limitations

SDKs can create:

• More merchant-controlled code on the payment page.
• More script governance obligations.
• More testing across browsers and devices.
• More dependency-management work.
• Greater exposure to third-party script risk.
• More difficult troubleshooting.
• Provider-version conflicts.
• Mobile release dependencies.
• More complex compliance documentation.

Treat the checkout page as a security-sensitive application.

Remove unnecessary scripts.

Review tag-manager access.

Limit administrative permissions.

Monitor code changes.

Document every payment-page dependency.

PCI scope: SAQ A, SAQ A-EP, and SAQ D

PCI DSS scope follows the payment architecture.

The integration label alone does not determine the correct Self-Assessment Questionnaire.

Use the official PCI DSS v4.0.1 document library for current standards and validation materials.

SAQ A

SAQ A is designed for eligible merchants that fully outsource account-data functions to a PCI DSS-compliant third-party service provider.

A full hosted redirect is the clearest example.

The merchant website sends the customer to the provider. The provider hosts the card-entry page. The merchant does not electronically store, process, or transmit account data in its own environment.

SAQ A eligibility still requires careful review.

The merchant must confirm:

• The provider is PCI DSS compliant.
• The integration matches provider instructions.
• The merchant does not receive raw card data.
• The merchant does not store raw card data.
• The merchant does not transmit raw card data.
• The merchant satisfies the applicable SAQ criteria.
• The acquirer accepts the selected validation method.

PCI SSC’s SAQ A eligibility FAQ clarifies the treatment of embedded payment pages and script-attack protections.

Do not assume that using an iframe automatically qualifies for SAQ A.

SAQ A-EP

SAQ A-EP applies to eligible e-commerce merchants that outsource payment processing but operate a website that can affect the security of the payment transaction.

This often includes:

• Merchant-hosted checkout pages.
• Embedded payment components.
• Hosted fields.
• Provider JavaScript loaded on the merchant domain.
• Browser-based tokenization.
• Direct-post integrations.
• SDK implementations.

The merchant may not receive raw card data. The merchant website can still affect the payment page.

That distinction matters.

SAQ A-EP can require extensive controls for the website, application, scripts, access, vulnerability management, and change control.

The merchant should maintain:

• A payment-page script inventory.
• Script authorization records.
• Provider documentation.
• Change-management procedures.
• Access reviews.
• Secure deployment procedures.
• Vulnerability scans where applicable.
• Monitoring for unauthorized changes.
• Incident response procedures.
• Evidence of provider coordination.

PCI DSS v4.0.1 includes specific attention to payment-page scripts and unauthorized changes. Review the official PCI DSS v4.0.1 standard.

SAQ D

SAQ D applies when the merchant stores, processes, or transmits cardholder data, or when the merchant does not qualify for another applicable SAQ.

A server-side direct API integration that receives raw card data commonly points toward SAQ D.

SAQ D can require controls involving the full technology environment.

The merchant may need to address:

• Network segmentation.
• System inventories.
• Data-flow diagrams.
• Encryption.
• Secure configuration.
• Malware protection.
• Vulnerability scanning.
• Penetration testing.
• Application security.
• Authentication.
• Access reviews.
• Logging.
• Monitoring.
• Incident response.
• Data retention.
• Key management.
• Vendor oversight.

The cost is not limited to completing the questionnaire.

The merchant must operate the controls throughout the year.

Use the acquirer’s interpretation

Payment providers can describe their integrations differently.

One provider may classify a hosted iframe as SAQ A under a specific implementation. Another may classify a similar embedded flow as SAQ A-EP.

The difference may involve:

• Who controls the iframe.
• Whether merchant scripts run on the page.
• Whether the provider protects the page from script attacks.
• Whether the merchant hosts the surrounding page.
• Whether the provider’s instructions are followed.
• Whether the acquirer accepts the implementation.

Obtain written guidance.

Do not rely on an informal sales statement.

Security requirements for every integration path

Every payment architecture requires security controls.

A hosted page does not excuse weak merchant security. An SDK does not excuse poor script management. A direct API does not justify unnecessary storage.

Apply these controls:

Protect payment pages

Remove unused scripts from checkout.

Restrict tag-manager access.

Review third-party plugins.

Use secure deployment procedures.

Monitor changes.

Keep the content-management system updated.

Separate administrative access from customer-facing access.

Protect tokens

Treat tokens as sensitive operational credentials.

Do not place tokens in public URLs.

Do not expose tokens in browser logs.

Do not include payment tokens in analytics events.

Restrict token access by role.

Keep test tokens out of production.

Document token retention.

Verify webhooks

Webhooks communicate authorization, capture, refund, dispute, and settlement events.

Verify the signature.

Check the event timestamp.

Reject duplicates.

Record the event ID.

Use idempotency controls.

Do not trust the browser to confirm payment success.

The server should verify the final transaction status with the provider.

Control refunds

Define who can issue refunds.

Require approval for large refunds.

Log every refund.

Support partial refunds when required.

Reconcile refunds to the original transaction.

Prevent duplicate refund requests.

Document refund timing.

Reconcile daily

Compare:

• Orders.
• Authorizations.
• Captures.
• Refunds.
• Chargebacks.
• Fees.
• Settlement deposits.
• Gateway reports.
• Merchant-account statements.
• Accounting records.

Payment gateway integration is incomplete until the accounting process works.

Compare the options by business requirement

Choose hosted checkout when speed matters

Hosted checkout is a strong fit when the merchant needs:

• Fast launch.
• Limited development resources.
• Low exposure to raw card data.
• Standard payment flows.
• Basic recurring billing.
• Invoices or payment links.
• Simple product catalogs.
• Minimal checkout customization.

Use it for a first launch or a simpler operating model.

Choose an SDK when checkout control matters

SDKs and hosted fields fit when the merchant needs:

• A branded checkout.
• A consistent customer journey.
• Custom cart logic.
• Wallet support.
• Tokenized saved payments.
• Subscription billing.
• Custom payment states.
• Mobile and web support.
• Better control over error handling.

Plan for additional website and script security responsibilities.

Choose direct API when the business has a clear technical reason

Direct API integration may fit when the merchant needs:

• Complex payment orchestration.
• Multiple processors.
• Advanced routing.
• Enterprise reconciliation.
• Custom authorization logic.
• Specialized transaction workflows.
• Proprietary payment infrastructure.

Confirm the security budget first.

Confirm the PCI scope first.

Confirm the operating team first.

Cost considerations in 2026

The lowest published gateway fee does not equal the lowest total cost.

Review:

• Processing markup.
• Interchange.
• Gateway fees.
• Monthly platform fees.
• API fees.
• Tokenization charges.
• Recurring billing fees.
• Chargeback fees.
• Refund fees.
• ACH costs.
• Cross-border costs.
• Currency conversion.
• Compliance expenses.
• Development cost.
• Maintenance cost.
• Monitoring cost.
• Downtime exposure.

A custom API can reduce some provider constraints while increasing engineering and compliance costs.

A hosted page can reduce engineering costs while limiting customer-experience control.

An SDK can balance the two.

Review transparent credit card processing pricing before comparing providers. Request a statement-level analysis. Compare the full payment stack.

High-risk and card-not-present considerations

High-risk merchants often need a payment architecture that supports underwriting controls from the first release.

Review:

• Product restrictions.
• Customer age or identity checks.
• Chargeback monitoring.
• Reserve requirements.
• Recurring billing.
• Delivery timelines.
• Refund controls.
• Manual review.
• Transaction limits.
• Geographic restrictions.
• Descriptor accuracy.
• Customer support records.

The integration must support operational decisions.

For example, the merchant may need to:

• Hold an order for review.
• Delay capture.
• Restrict a customer account.
• Cancel an authorization.
• Issue a partial refund.
• Stop recurring billing.
• Suspend a product category.
• Route transactions to an approved account.
• Reconcile reserve deductions.

A basic hosted page can process a transaction. It may not manage every risk workflow.

A custom API can manage more workflows. It may create broader PCI scope.

An SDK can provide a middle path if the provider supports the required controls.

Call 866-305-6454 before finalizing the payment architecture for an elevated-risk business.

Implementation checklist

Complete this checklist before production launch.

Business requirements

• Identify customer payment channels.
• Identify card-not-present transactions.
• Identify telephone or MOTO transactions.
• Identify recurring billing.
• Identify ACH or eCheck requirements.
• Identify average and maximum ticket.
• Identify expected monthly volume.
• Identify countries served.
• Identify refund timing.
• Identify delivery timing.
• Identify chargeback responsibilities.

Integration design

• Select hosted checkout, SDK, or API.
• Map the payment data path.
• Confirm whether raw card data reaches merchant systems.
• Confirm token behavior.
• Confirm authorization and capture behavior.
• Confirm refund behavior.
• Confirm recurring billing behavior.
• Confirm wallet support.
• Confirm webhook format.
• Confirm idempotency support.
• Confirm outage procedures.
• Confirm reporting access.

PCI review

• Identify the likely SAQ.
• Review PCI SSC eligibility criteria.
• Obtain the provider’s PCI documentation.
• Confirm the provider’s implementation requirements.
• Review payment-page scripts.
• Review third-party tags.
• Document change management.
• Confirm vulnerability scanning obligations.
• Confirm monitoring obligations.
• Ask the acquirer to confirm the validation path.

Testing

• Test an approved payment.
• Test a declined payment.
• Test an expired card.
• Test an incorrect security code.
• Test a duplicate submission.
• Test a timeout.
• Test a webhook delay.
• Test a webhook replay.
• Test a full refund.
• Test a partial refund.
• Test a recurring payment.
• Test a failed recurring payment.
• Test a customer cancellation.
• Test a chargeback notification.
• Test reconciliation.
• Test gateway downtime.

Make the integration decision now

Use hosted checkout when speed and reduced scope are the priority.

Use an SDK or hosted fields when the merchant needs a branded checkout with tokenization.

Use a direct API when custom control justifies the development and security burden.

Do not choose the integration path in isolation.

Match it to:

• Merchant account requirements.
• Gateway capabilities.
• Customer experience.
• Recurring billing.
• Refund operations.
• Fraud controls.
• High-risk underwriting.
• PCI DSS responsibilities.
• Reporting.
• Reconciliation.
• Long-term maintenance.

Bridge Capital Partners supports e-commerce payment processing, online credit card processing, gateway selection, high-risk merchant accounts, ACH processing, recurring billing, and custom payment integrations.

Call 866-305-6454 now.

Review the payment gateway integration options for e-commerce merchants and PCI DSS 4.0.1 compliance considerations before development begins.

Confirm the final PCI validation path with the payment provider, acquiring bank, or qualified security assessor.