Hosted Checkout vs Native Checkout: Which Should Philippines Merchants Use

When our team in China started scoping a merchant platform for the Philippines, the wallet decision was easy — GCash and Maya were non-negotiable, QRPH was obviously coming. The decision that actually slowed us down was quieter: when a customer clicks "Pay," does the browser leave our page and land on the payment provider's own screen, then come back once the transaction is done? Or does the entire payment form — card fields, wallet buttons, OTP prompts — stay embedded inside our own page from start to finish?

That's the hosted checkout vs native (embedded) checkout decision, and it's not a cosmetic one. It touches your engineering timeline, your security obligations, your conversion funnel, and how much of the payment experience you actually control. I've now sat through this debate twice — once for our own commerce stack, once advising a partner merchant who was convinced native checkout was simply "the professional choice" and talked themselves into a six-week integration they didn't have time for. This article is the framework I wish someone had handed me before either project started.

Two Ways to Take a Payment on Your Own Page

Strip away the marketing language and there are really only two architectural patterns for where the actual payment collection happens.

Hosted checkout means your server creates a checkout session with the payment provider, gets back a URL, and redirects (or opens in an iframe/popup) the customer to a page the provider owns, styles, and secures. The customer enters card details or authorizes a wallet payment on that page, and the provider redirects them back to your site with a result.

Native checkout (sometimes called embedded or direct checkout) means the payment form itself — card input fields, wallet deep-link buttons, QR rendering — lives inside your own page, built with the provider's SDK or raw API calls. The customer never technically leaves your domain. Visually, and often technically, your brand owns the entire moment of payment.

Both models end up calling the same underlying rails — GCash, Maya, QRPH, card networks — the difference is entirely about where the UI and the sensitive data capture happen, not which channels you can reach.

What Each Model Actually Asks of Your Team

With hosted checkout, your integration work is mostly server-side: create a session, pass order metadata, receive a redirect URL, and later verify a webhook or callback to confirm the result. Your frontend team barely touches payment logic — there's no card field validation, no handling of wallet-specific redirect quirks, no keeping up with SDK version bumps. For a merchant shipping their first Philippines storefront, or a lean team split across time zones, this is usually the realistic starting point: you can go from zero to a working checkout without a dedicated payments engineer.

The trade-off is the moment of departure. The customer sees a different URL, possibly a different visual design, for the seconds it takes to pay. On mobile, a redirect to a wallet app and back can feel like an extra step, especially on a slow connection. For some customer segments this barely registers; for others, especially ones unfamiliar with a given wallet's redirect flow, it introduces a point where attention — and sometimes the transaction — is lost.

Native checkout keeps the customer inside your page, which means you control every pixel of the payment moment: your fonts, your button copy, your error states, your loading animation. For merchants where brand consistency or a tightly choreographed conversion funnel matters — a subscription signup flow, a high-end retail experience — that control is worth real effort.

The effort is the catch. You're now responsible for rendering and validating payment fields correctly across browsers and devices, handling every wallet's specific authorization flow (some still require a redirect or deep link even in a "native" integration — wallet apps aren't going away just because your checkout is embedded), keeping your SDK current as the provider ships updates, and building your own error-handling and retry logic for a wider surface of failure states. You also inherit a meaningfully larger slice of security responsibility, which I'll come back to.

This is the same shape of trade-off we unpacked when comparing InstaPay vs PESONet for merchant settlement — two paths to the same destination, where the right answer depends on what your team and timeline can actually absorb, not which option sounds more sophisticated on a slide deck.

Hosted vs Native: Side by Side

Factor	Hosted Checkout	Native / Embedded Checkout
Integration effort	Low — mostly server-side session creation and webhook handling	Higher — frontend form rendering, SDK lifecycle, cross-device testing
Security / PCI burden	Minimal — card data never touches your servers or page	Larger — your page renders and/or handles sensitive fields, requiring stricter PCI DSS scope
Conversion impact	Possible drop-off at the redirect moment, especially on slow mobile connections	Can reduce friction and abandonment by removing the page change, if built well
Branding control	Limited — customer briefly sees the provider's own page design	Full — payment UI matches your site end to end
Time-to-launch	Shorter — many merchants can go live without a dedicated payments engineer	Longer — needs engineering ownership of the payment UI and ongoing maintenance
Best fit	New entrants, lean teams, fast market tests	Established merchants with conversion-sensitive funnels and engineering capacity

The Decision Framework: Match the Model to Where Your Team Actually Is

Here's the framework I now use with every merchant who asks me this question, including myself six months ago. Three inputs decide it, in this order of priority.

1. Technical maturity. Do you have an engineer who will own the payment UI long after launch — someone who will notice when a wallet changes its redirect behavior or a card scheme updates its field requirements? If the honest answer is "we have one generalist developer and three other launches this quarter," hosted checkout is not a compromise, it's the correct engineering decision. If you already run a payments or growth engineering function, native checkout is well within reach.

2. Timeline pressure. If you need a working checkout to validate demand or hit a seasonal window, hosted checkout gets you there with far less surface area to test. Native checkout integrations that get rushed tend to ship with the exact edge cases — failed wallet redirects, unhandled timeout states — that cost you support tickets later. If your timeline is tight, don't borrow against it with a native build you can't fully test.

3. Conversion priorities. If your product is genuinely conversion-sensitive — a subscription signup, a high-intent checkout where every extra screen measurably costs you customers — the branding and friction control of native checkout can justify the build cost. If you're an early-stage storefront where the bigger problem is traffic, not checkout drop-off, that engineering investment is better spent elsewhere for now.

Most merchants I talk to overweight branding control and underweight the ongoing maintenance cost of native checkout. The honest version of this framework is: start where your team's bandwidth actually is, not where your ambition is.

I'd also add a fourth, less obvious input: who you're integrating with. Confirm your provider's licensing status before anything else — I always check whether a prospective partner holds a verifiable BSP EMI license, because the checkout model you choose doesn't matter if the entity settling your funds isn't properly authorized to operate in the first place.

SMARTPAY operates under BSP OPS/EMI licensing in the Philippines, which is worth confirming for any provider before you build either checkout model on top of them — the integration pattern is secondary to who is actually holding and moving the funds.

What the Integration Code Actually Looks Like

To make this concrete, here's a simplified comparison of the two patterns. Treat the field names and endpoints as illustrative — your provider's actual documentation will differ in detail, but the shape of the two approaches holds.

Hosted checkout: your server requests a session and gets back a redirect URL.

curl -X POST https://api.example-gateway.com/v1/checkout/sessions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_SECRET_KEY" \
  -d '{
    "order_id": "ORD-20261004-0091",
    "amount": "{{order_total}}",
    "currency": "PHP",
    "success_url": "https://yourshop.example/pay/success",
    "cancel_url": "https://yourshop.example/pay/cancel",
    "channels": ["gcash", "maya", "qrph", "card"]
  }'

# Response
{
  "session_id": "cs_8f2a1e",
  "checkout_url": "https://checkout.example-gateway.com/cs_8f2a1e",
  "expires_at": "2026-10-04T15:30:00Z"
}

Your frontend simply redirects the customer to checkout_url, then listens for the webhook or polls the session status once they return.

Native checkout: your page renders the provider's embedded form or SDK component directly, and you handle the result client-side before confirming server-side.

// Native/embedded form initialization in your own page
const checkout = Gateway.createEmbeddedForm({
  publicKey: "pk_live_xxx",
  container: "#payment-form",
  channels: ["card", "gcash", "qrph"],
  onToken: async (token) => {
    // Token represents the tokenized payment method,
    // never raw card data — sent to your server to complete the charge
    const res = await fetch("/api/charge", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ order_id: "ORD-20261004-0091", token })
    });
    const result = await res.json();
    if (result.status === "authorized") {
      window.location.href = "/order/confirmed";
    } else {
      checkout.showError(result.message);
    }
  }
});
checkout.mount();

Notice the native example still tokenizes before anything touches your server — that tokenization step is what keeps raw card data off your infrastructure even in an embedded flow, and it's the detail most merchants miss when they assume native checkout automatically means "we now store card numbers." You shouldn't, under any integration model.

Security and Compliance Burden: Who Is Actually Holding the Risk

This is the section merchants underestimate most. With hosted checkout, the sensitive payment fields render on a page your provider controls, inside their security perimeter. Your PCI DSS scope stays small — often limited to confirming you redirect correctly and don't log anything you shouldn't.

With native checkout, even when you use a provider's tokenizing SDK correctly (and you should always tokenize — never collect raw card numbers into your own form fields without it), you take on a larger slice of responsibility: your page is now part of the payment flow's attack surface, your frontend dependencies need auditing, your team needs to understand what "SAQ A-EP" or equivalent self-assessment category actually applies to you, and you need a process for when the SDK ships a security patch. None of this is prohibitive, but it is ongoing work, not a one-time setup cost. I'd recommend reading through the PCI DSS compliance requirements for Philippine merchants in detail before committing to a native build, specifically to understand which assessment category your architecture will fall into — it changes the native vs hosted calculation more than most people expect.

The licensing status of your underlying processor matters here too, independent of which checkout model you pick. A provider operating without proper authorization doesn't become safer just because you chose the simpler hosted integration pattern on top of them.

A Phased Path: Start Hosted, Earn Your Way to Native

If you're genuinely unsure, the path I now recommend to every merchant I talk to is sequential, not binary. Launch with hosted checkout to get a real, working payment flow in front of customers with minimal engineering risk. Use that period to actually measure your funnel — where in the hosted checkout URLs changes correlate with drop-off, which channels your customers prefer, whether mobile redirect friction is a real problem for your traffic or a theoretical one.

Only once you have that data, and a team with the bandwidth to own an embedded payment surface long-term, does a native checkout rebuild earn its engineering cost. I've seen more merchants waste a quarter building native checkout on a hunch than I've seen merchants regret starting hosted. The reverse — starting native and discovering your team can't keep up with maintenance — is a much more expensive mistake to walk back than starting simple and upgrading later.

This also ties back to broader checkout page design and cart abandonment work: the checkout model is one input into conversion, not the whole story. Payment method ordering, page load speed, and trust signals on the page often move the needle more than the hosted-vs-native choice alone, and it's worth fixing those before assuming a native rebuild is the answer.

Frequently Asked Questions

Does hosted checkout meaningfully hurt conversion compared to native checkout?

It depends heavily on your traffic. Customers already comfortable with wallet redirects (GCash, Maya users switching to their app and back) often don't notice much friction. The impact is largest on unfamiliar flows or slow connections, so test with your actual audience before assuming the redirect is costing you sales.

Can I switch from hosted to native checkout later without rebuilding everything?

Mostly yes, if you've kept your order and session logic cleanly separated from the checkout UI itself. The backend concepts — creating a transaction, verifying a result, reconciling settlement — carry over; it's the frontend layer and your security review process that change.

Does hosted checkout reduce my PCI DSS scope?

Generally, yes, because sensitive fields never render on your page or touch your servers. It doesn't eliminate your compliance obligations entirely, but it substantially narrows what you need to assess and maintain compared to an embedded form.

Is native checkout only realistic for large merchants?

Not exclusively, but it does require sustained engineering ownership, not just a one-time build. A small team can do it well if someone genuinely owns the payment UI going forward — the risk is treating it as a "set and forget" integration.

Does my provider's licensing status change which checkout model I should pick?

No — licensing and checkout architecture are separate questions. Verify your provider's authorization regardless of which model you choose; a clean integration on top of an improperly licensed entity doesn't solve the underlying problem.

Which model is faster to launch for a first-time Philippines merchant?

Hosted checkout, by a wide margin, in my experience. The server-side-only integration work means you can realistically validate your market entry before investing in a payment UI build.

Can I mix both models — hosted for some channels, native for others?

Yes, and some merchants do exactly this: native for card payments where the branding payoff is highest, hosted redirects for wallets where the customer is leaving to their own app regardless. It adds complexity, so only take this path once you understand why you need the split, not by default.

If you're weighing this decision for your own Philippines integration and want to talk through where your team's bandwidth actually sits against your timeline, reach out — @LouisSMARTPAY or [email protected].