Blog5 min read

Clover Hosted Checkout vs Embedded Card Fields on WooCommerce

Clover Hosted Checkout redirects shoppers to a Clover page. Embedded card fields keep them on your WooCommerce checkout. Here are the pros and cons of each, plus a plain guide to the Clover API.

Clover Hosted Checkout vs Embedded Card Fields on WooCommerce

Most owners pick a Clover checkout by asking which one looks nicer. That is the wrong question. Clover Hosted Checkout and embedded card fields both take a card payment and nothing more. Neither one syncs stock, customers or kitchen printing, so the real choice is how shoppers pay and what you build around that payment.

My take is simple. Use the redirect for a plain payment button. Embed the fields when checkout design and a one-page flow matter, as they do for most restaurants. CloverWoo takes the embedded route, and this post explains why and where the redirect still wins. Card payments work in the US and Canada only.

Table of Contents

Clover Hosted Checkout, Plainly Explained

Clover Hosted Checkout sends the shopper to a page that Clover hosts. They enter the card there, then come back to your site. It runs on the Ecommerce API, which is for card-not-present payments and needs no Clover hardware, according to Clover's ecommerce FAQs.

Clover Hosted Checkout, Plainly Explained - clover hosted checkout

Your store creates a checkout session through that API. Clover returns a URL. The amount goes in as integer cents, with line items alongside it.

What it does well

  • Card entry sits on Clover's page, so less card data touches your site.
  • It fits a payment button, an invoice or a donation page.

Where it hurts

  • The shopper leaves your branded checkout.
  • A return to your success URL is only a page visit. It does not prove the payment settled.

Wait for Clover's signed webhook before you mark the WooCommerce order paid. A shopper can close the tab after paying and never reach your success page. A shopper can also type the success URL by hand. The webhook is the only signal you can trust.

Know the plain limits too. Hosted Checkout is a payment page, not a catalogue, stock or kitchen system. Clover's docs list other limits, such as how it handles customer records, service fees and ACH, so read them before you build.

Put Card Fields on Your Own Checkout

Clover's iframe SDK places secure card fields inside your own WooCommerce checkout page. The shopper never leaves your site. Clover serves the fields, and the card data goes to Clover, not to your server.

The upside is a checkout that looks like your store. There is no redirect and no return-URL step. The order is created and paid in one flow, which suits a restaurant where every extra click loses an order.

The downsides are real. The fields load from Clover, so your page and theme must load them cleanly. Plugin conflicts at checkout are more likely than with a plain redirect. You still confirm payment on the server, never in the browser.

Pro Tip: Test your checkout with your full plugin stack switched on. Caching, optimisation and checkout-editing plugins cause most iframe problems.

CloverWoo uses this method. It adds product, stock, order and customer sync and kitchen printing around the payment, which the card fields alone never do.

A short rule of thumb. Pick Hosted Checkout for a simple button or a custom site. Pick embedded fields when design and a one-page flow matter.

Which Clover Checkout Fits Your Store?

Start with four questions. Do you need payment only, or full sync? How much control do you want over the checkout look? How much developer time do you have? How much do you want to maintain?

Which Clover Checkout Fits Your Store? - clover hosted checkout

Here is how that plays out by shop type:

  • One-location cafe, payment only: Hosted Checkout or Clover's own WooCommerce plugin is enough.
  • Retail shop selling the same SKUs in store and online: You need a stock rule, not just a payment page.
  • Restaurant that needs paid orders to print in the kitchen: Payment is one piece of five.
  • Developer on a custom site: The direct API with Hosted Checkout gives you the most control.

Be honest about the first case. If you only need a payment button, you do not need more. But if you want one menu, one stock count and automatic kitchen printing, a payment method cannot give you that.

Separate payment security from everything else. Hosted Checkout and embedded fields both keep card entry with Clover. Neither syncs products, stock, customers or kitchen printers. That takes a connector.

The order lifecycle on WooCommerce

  1. Create the WooCommerce order.
  2. Collect payment through Clover.
  3. Confirm the payment through the signed webhook.
  4. Reduce stock.
  5. Print the kitchen ticket.

Steps 1 to 3 are payment. Steps 4 and 5 are where most stores break. A sale at the Clover counter and an online sale of the same item can collide, so you must choose a source of truth for stock. Totals matter too. If tax, tips, service fees or discounts differ between Clover and WooCommerce, the two orders will disagree.

Clover API for Online Payments

People search for the Clover API in three ways: clover api integration, clover pos api and clover developer api. They are mostly the same question with different names.

Clover API integration

For online card payments, the route is the Ecommerce API. It covers both Hosted Checkout and the iframe SDK. You need a merchant ID plus public and private tokens, as Clover's docs describe.

Clover POS API versus developer API

The REST API for POS data, such as inventory and orders, is a different workspace. It is not the same as the Ecommerce API. Check docs.clover.com for the exact scope of each before you build.

The developer API lets you create sessions, take payments and read data. It does not write your stock rules or route tickets to a kitchen printer. You build that yourself, or you use a plugin that does.

Sandbox versus production

Test accounts and keys are separate from live ones. When you go live, you swap in the production credentials. The full test routine is in Clover Sandbox: Test Payments Before You Go Live.

Before launch, confirm these:

  • Your return and redirect URLs use HTTPS.
  • The webhook secret is set and matches.
  • You are using the right token type.
  • You close the browser mid-payment on a test order and see what happens.

That last test tells you whether your store trusts the webhook or the browser. Also try a retried checkout and a stock change at the counter.

If you want one plugin for Clover payments plus product, stock, order and customer sync with WooCommerce, with free setup help after purchase, see CloverWoo pricing and start with a single store licence.

Run Clover + WooCommerce as one system

CloverWoo — sync, payments, and POS operations in one plugin for $60/month.