Independent Store Payment Architecture: Self-Built, SaaS, and Hosted Checkout Trade-Offs

Independent Store Payment Architecture: Self-Built, SaaS, and Hosted Checkout Trade-Offs

Payment architecture is not a question of technical taste. It is a one-time answer to three questions: who touches card data, who carries compliance responsibility, and who controls the checkout experience. Answer those and the architecture is essentially fixed; what remains is implementation detail. This article covers the payment structure only, with no discussion of themes, templates, or merchandising. For a feature-level comparison of platforms, see the ecommerce platform comparison, and for digital product delivery and licensing see the digital products payment guide. No rates, volume thresholds, or settlement days appear here; wherever a number is involved, the platform's and channel's current official policy governs.

1. Three Store Models and the Architecture Each Implies

1.1 Defining the Three Models

The useful split is not which model is better but who hosts the checkout page. First, self-built: server, code, and checkout are all yours. Second, SaaS platforms: site and checkout are hosted by the platform, and payment options are bounded by what it supports. Third, hosted checkout: however the front end is built, the checkout step is handed entirely to a third-party page. The three can be combined, for example a self-built front end with a hosted checkout page, which is how many teams actually ship.

1.2 The Three Layers Must Be Discussed Separately

The most common mistake is treating the acquiring layer, the gateway layer, and the checkout layer as one thing. Acquiring decides whose account receives the money and who carries chargeback and settlement liability. The gateway layer decides technical interfaces, callbacks, and token management. The checkout layer decides where the buyer enters payment details and who controls that experience. Each can be selected independently, and using one party's acquiring, another's gateway, and a third's checkout page is a perfectly legitimate combination, in fact the most common compromise between control and compliance cost.

2. Payment Layering on a Self-Built Store

2.1 Acquiring Layer: Fix the Entity Before the Technology

The first step is not choosing a gateway but deciding in whose name you acquire. A domestic entity, an offshore entity, or several entities acquiring separately each determines which acquirers you can contract with, which account settles, how tax is filed, and who handles chargebacks. Get this wrong and the whole technical selection is redone, because different entities can contract different channels and reach different local methods. Teams that pick a plugin first and sort out the entity later end up rebuilding during underwriting.

2.2 Gateway and Checkout Layers: Trading Control for Cost

The gateway layer is the technical interface, in three shapes: direct API, embedded iframe components, and hosted payment pages. The checkout layer is what the buyer actually sees. A direct API gives the most control while pulling card data touchpoints into your own systems. An embedded component keeps sensitive fields on the channel's side while preserving the site's look. A hosted page is the least work, at the cost of redirect drop-off and brand continuity. The usual self-built pattern is an embedded component for the primary channel and a hosted page for backups, balancing control against integration cost. Common self-built foundations include WooCommerce and Magento, and the plugin mechanism plus checkout rendering details of the former are covered in the WooCommerce payment gateway setup guide.

3. Where SaaS Platforms Draw the Payment Boundary

3.1 Default Benefits of a Platform-Hosted Checkout

A SaaS platform hosts the checkout page and hands the merchant several defaults: card data never passes through merchant systems, so compliance scope is minimal; checkout compliance updates are the platform's job rather than yours; and method display and localization are handled centrally. For small teams with limited resources these benefits are substantial, because they turn a continuous investment into part of the platform service.

3.2 What the Limits Look Like

The price is that payment options are boxed in by the platform. Four shapes recur: the platform's own payment service is open only in some markets; using a third-party provider triggers an extra platform fee; some local methods simply cannot be connected; and subscription or installment shapes must run through apps the platform allows. Read these as product boundaries rather than technical defects. The Shopify side is fully unpacked in the Shopify payment options guide, and differences among other common platforms such as Shopify, BigCommerce, Wix Stores, Squarespace Commerce, and Ecwid concentrate on which markets their own rails cover and how flexible third-party integration is.

4. The Hosted Checkout Trade-Off

4.1 Minimal Compliance Scope Is the Biggest Gain

Hosted checkout places the payment form on a third-party page, so merchant systems never touch card numbers and the self-assessment scope drops to the lightest tier. For a business without a dedicated security team, that is often worth more than the experience loss, because compliance is continuous work rather than a one-off task. Outsourcing checkout effectively converts part of that engineering cost into part of the channel fee.

4.2 Giving Up Experience Control

The cost lands on experience: a redirect interrupts the buyer's flow, the page style diverges from the site, return and state recovery after a failure depend on parameters and polling fallbacks, and some custom promotion logic cannot be expressed on the hosted page. A simple test decides whether that is acceptable. If conversion is highly sensitive to brand consistency and field order at checkout, hosted checkout is wrong. If tickets are large, decision cycles are long, and buyers do not mind redirects, the loss is negligible.

5. Collection Layouts Across Markets and Entities

5.1 Where the Single-Entity Line Sits

Single-entity collection is structurally simple, keeps reconciliation definitions unified, and centralizes tax filing, but it limits access to cross-border acquiring and settlement paths in some markets. Multi-entity collection unlocks local acquiring eligibility, local settlement accounts, and better-fitting local methods, at the cost of multiplying entity maintenance, audit, tax, and cash pooling complexity. The line is usually drawn at whether revenue from one market covers the fixed cost of an additional entity, not at whether you want to expand.

5.2 Four Common Layouts and Their Costs

On channels specifically, cross-market operations usually need both global and local acquiring: Stripe and Checkout.com are quick to roll out, while Adyen goes deeper on regional coverage and local acquiring. Digital goods and subscription businesses can also evaluate models that absorb tax and subscriptions together, such as Paddle and Lemon Squeezy. Within the self-built ecosystem, the extension ecosystems of Adobe Commerce, PrestaShop, and OpenCart are worth weighing too. The full merchant of record comparison is in the merchant of record platforms guide.

6. How Architecture Drives Compliance and PCI Scope

6.1 Architecture Determines the Self-Assessment Type

PCI scope is not a yes-or-no decision but an outcome, and architecture decides it. Fully hosted checkout maps to the lightest self-assessment, embedded components sit in the middle, and a direct form is the heaviest. Many teams assume moving to hosted checkout removes responsibility entirely, but merchants still complete baseline self-assessment and annual confirmation, simply within a much narrower scope. For tiers and evidence preparation, see the practical PCI DSS compliance guide.

6.2 Licensing Is a Separate Constraint

Beyond card network data security requirements, acquiring eligibility is itself regulated: in what capacity you collect, whether a local license is required or a licensed partner is needed, and how cross-border funds are declared. Those answers bind to entity structure, not to front-end architecture. Architecture selection must therefore lock the compliance position at the same time, or you end up technically live with no compliant way to pool the funds. For routes through that landscape, see the payment compliance and licensing guide.

7. Cost Structure and the Small-Scale Disadvantage

7.1 Separate Fixed From Variable Costs

The three models differ sharply in cost structure. A self-built store carries high fixed costs across development, operations, security, and compliance, with comparatively controllable variable costs. A SaaS platform converts fixed cost into subscription fees with variable cost growing with volume. Hosted checkout and merchant of record models have the lowest fixed cost but a higher per-transaction share. Compare by spreading fixed cost across expected volume rather than comparing headline rates, because at small scale fixed cost routinely overwhelms the rate difference.

7.2 What Being Small Actually Costs

The disadvantage of small scale is not just weak negotiating power but three more concrete problems: compliance and operations cost per order is higher; you fall short of acquirer risk and settlement terms that larger merchants receive; and you lack the data volume to attribute success-rate or chargeback changes. The sensible small-scale strategy is usually to start hosted and reduce fixed cost, then move to self-built once a single market's revenue is stable and control is worth paying for, rather than pursuing full autonomy from day one. For operating success rate as a long-term metric, see the payment success rate optimization guide.

8. An Architecture Decision Checklist

8.1 Five Questions That Must Be Answered

First, how many markets produce revenue, and is it concentrated? Second, does the business need local methods the platform does not cover? Third, can the team sustain ongoing security and compliance investment? Fourth, how sensitive is conversion to checkout experience, and are redirects acceptable? Fifth, will multi-entity or local incorporation be needed within two years? The combination of answers usually leaves exactly one architecture. Two adjacent considerations: payment shapes for membership and subscription businesses are covered in the membership site platform guide, and the coverage gradient of local methods across markets is in the global local payment methods overview, with cross-border channel trade-offs in the cross-border payment selection matrix.

8.2 Conclusions for Three Typical Businesses

Once architecture is fixed, swapping channels is a manageable operation, but changing architecture is close to a rebuild, which is why answering those three questions early beats optimizing later. For channel-level migration steps see the payment gateway migration guide, and for multi-currency accounts and settlement structure see the multi-currency collection account guide. If you are still comparing store builders themselves, see the website builder platform comparison. More collection topics are collected under the Payment category.

Source: 16IDC original. Product capabilities, pricing and eligibility requirements follow the relevant providers’ official documentation and contract terms.