Loading tutorials…
Loading tutorials…
Most Woo owners install the Stripe plugin, see 'Connected,' and assume Apple Pay just works. Then mobile CR sits at 28% because the Payment Request Button never registered the domain. Here is the full gateway setup including Blocks Checkout compatibility.
Who this is forWooCommerce owners launching a new store, or anyone with existing payment friction — declined transactions, missing Apple Pay button on iOS, or PayPal that opens in a broken popup. If your monthly revenue is over $5K and mobile CR is below 45%, broken payment UX is almost certainly part of it.
What you'll need
Step 1
Pick a primary card processor (Stripe or WooPayments) + PayPal as secondary + native wallets (Apple Pay, Google Pay) on top. Avoid running 3+ card processors in parallel.
WooCommerce supports unlimited gateways simultaneously, but every active gateway adds checkout-page load weight and customer confusion. Three is the sweet spot: one card processor, PayPal, and native wallets layered on the card processor.
Option A — WooPayments (Automattic native). Cheapest path for new US/UK/EU stores: 2.9% + 30¢, no monthly fee, native Apple Pay + Google Pay. Best if you are starting from zero.
Option B — Stripe via the official "Stripe Payment Gateway for WooCommerce" plugin. Best for owners who already have Stripe in their broader stack (subscriptions, Stripe Tax, Stripe Connect).
Option C — PayPal Payments (PayPal-native plugin, not the legacy PayPal Standard). Should ALWAYS be a secondary option — PayPal adds 5-10% to mobile CR but cannot be the only option for first-time card-only buyers.
Recommendation: WooPayments OR Stripe as primary + PayPal Payments as secondary + Apple/Google Pay layered on the primary. Avoid the legacy "PayPal Standard" plugin — it redirects to PayPal.com and loses 30%+ of mobile shoppers.
Step 2
WordPress Admin → Plugins → Add New → search "Stripe for WooCommerce" (by WooCommerce) → install + activate. Then WooCommerce → Settings → Payments → Stripe → Manage.
Install the official Stripe Payment Gateway for WooCommerce — not a third-party Stripe plugin. The official plugin is the only one that fully supports Blocks Checkout and the latest Stripe payment methods (Klarna, Afterpay, Cash App Pay, Link).
Go to WooCommerce → Settings → Payments → Stripe → Manage. Click "Connect to Stripe" and authenticate with OAuth. This is preferred over manually pasting API keys — OAuth handles webhook setup automatically.
Enable: (a) "Card payments," (b) "Payment Request Buttons (Apple Pay, Google Pay)," (c) "Link" (Stripe one-click checkout). For most stores, also enable: Klarna, Afterpay/Clearpay (region-dependent).
Critical: ensure "Enable test mode" is OFF before going live. Test mode keys silently accept fake cards and produce no revenue. This is the #1 launch-day disaster on Woo.
In Stripe Dashboard → Settings → Payment methods → Apple Pay → Web domains: verify your domain. The Stripe plugin attempts this automatically but the verification file occasionally fails — confirm at https://yourdomain.com/.well-known/apple-developer-merchantid-domain-association returns a long token, not a 404.
Step 3
Install the "PayPal Payments" plugin (by WooCommerce) — NOT the legacy "PayPal Standard." Connect via OAuth. Enable Smart Buttons + Pay Later messaging.
Plugins → Add New → "PayPal Payments" by WooCommerce. Activate. Then WooCommerce → Settings → Payments → PayPal Payments → Manage.
Click "Connect to PayPal." The flow opens PayPal in a popup — sign in with your PayPal Business account and approve permissions.
On the settings screen, enable: "Standard Payments" (card + PayPal balance), "PayPal Smart Buttons" (the dynamic button that shows Venmo/Pay Later when eligible), and "Pay Later messaging" (the "from $20/mo" widget that lifts AOV 8-12%).
Disable "Standard Card Fields" if you are using Stripe for cards — running both creates two card forms on checkout and confuses shoppers.
In the Vault settings, enable "Save PayPal accounts for repeat purchases." This is what makes returning-shopper checkout one click via PayPal.
Step 4
Apple Pay is the highest-leverage payment method on WooCommerce — but it only works if domain verification, HTTPS, and the Payment Request Button are all green. Test on a real iPhone.
Open your store on a real iPhone in Safari (Apple Pay does NOT work in Chrome on iOS). Add a product → Cart → Checkout.
On the Blocks Checkout, the Apple Pay button should appear ABOVE the email field, branded black with the Apple logo. If you only see the standard card form, Apple Pay registration failed.
On Android in Chrome, the same flow should show a Google Pay button if the device has cards saved.
Common Apple Pay failures: (a) domain not verified at Stripe (Step 2), (b) HTTPS misconfigured (mixed content from an old plugin loads an http:// image), (c) the Payment Request Button toggle in Stripe settings is off, (d) the merchant identifier in Stripe does not match the live domain after a domain change.
Validate with a real Apple Pay test: complete a $1 purchase. Refund yourself afterward. Confirm in WooCommerce → Orders that payment method shows "Apple Pay (via Stripe)" — not "Stripe (card)."
Step 5
WooCommerce 8.3+ ships Blocks Cart/Checkout by default. Some legacy gateways force a fallback to Classic Checkout — verify yours does not.
In WordPress Admin → Pages → Checkout, confirm the page uses the "Checkout" block (Blocks-based), not the legacy [woocommerce_checkout] shortcode. The block icon shows in the editor.
If you migrated from older WooCommerce or installed a third-party page builder, the page may still use the shortcode. Add a new Checkout block and delete the shortcode — but back up the page first.
On the live checkout page, every active gateway must render correctly. If one gateway shows "This payment method is not supported" or fails to load, it is not Blocks-compatible.
Common offenders: older Authorize.net plugins, legacy "PayPal Standard," some regional gateways. Either upgrade the plugin to its Blocks-compatible version or disable it.
The Blocks Checkout is significantly faster (300-500ms TTI improvement) and required for some Stripe payment methods (Link, Cash App Pay) to work at all.
Step 6
Stripe and PayPal both need webhooks pointing at your WooCommerce site to update order status (paid → processing → completed) reliably. The OAuth connection handles this — verify.
In Stripe Dashboard → Developers → Webhooks, you should see one endpoint pointing at https://yourdomain.com/wc-api/wc_stripe/ with events: payment_intent.succeeded, charge.refunded, customer.subscription.deleted, etc. The Stripe plugin creates this automatically via OAuth.
In PayPal Developer Dashboard → My Apps & Credentials → your live app → Webhooks, verify the endpoint exists.
Run a $1 test transaction. Within 60 seconds, the WooCommerce order should auto-update from "Pending payment" → "Processing." If it stays "Pending payment," the webhook is broken — usually a security plugin (Wordfence, iThemes) blocking POST requests to /wc-api/.
Whitelist /wc-api/ in any security plugin. Also whitelist Stripe + PayPal IP ranges if you use a WAF (Cloudflare, Sucuri).
Verify Action Scheduler is processing jobs: WooCommerce → Status → Scheduled Actions. Stale "Pending" actions older than 1 hour indicate a cron issue that will also break order emails and abandoned-cart flows.
Step 7
Run a $1 test through every active gateway, on iPhone + Android + desktop. Verify order status, payment method label, and email confirmation in all 9 combinations.
Build a checklist: 3 gateways (Stripe card, Apple/Google Pay, PayPal) × 3 devices (iPhone Safari, Android Chrome, desktop Chrome) = 9 test transactions.
For each, verify: (a) payment completes without errors, (b) order appears in WooCommerce → Orders with correct gateway label, (c) customer confirmation email fires within 60 seconds, (d) you receive the "New order" admin email.
Refund each test transaction from inside WooCommerce → Orders → Refund. Verify the refund actually moves money in Stripe/PayPal dashboards — not just in WooCommerce.
Document any failed combination in a spreadsheet. Fix one at a time, re-test. Do not launch publicly until 9/9 pass.
This is tedious. It is also the difference between a launch day that produces revenue and one that produces customer-support tickets.
Common mistakes
Using the legacy "PayPal Standard" plugin
What goes wrong: The legacy plugin redirects shoppers to PayPal.com to complete payment, losing 25-35% of mobile shoppers in the redirect. It is also not Blocks Checkout compatible and forces a fallback to Classic Checkout for everyone.
How to avoid: Uninstall "PayPal Standard." Install "PayPal Payments" by WooCommerce. The new plugin keeps shoppers on your site via Smart Buttons.
Apple Pay domain not verified
What goes wrong: Apple Pay button silently doesn't render on iPhone. Mobile CR sits 8-15% lower than it should because the fastest checkout method is missing. You never know it's broken because the admin dashboard shows Stripe as 'Connected.'
How to avoid: Stripe Dashboard → Settings → Payment methods → Apple Pay → Web domains → add and verify your domain. Confirm /.well-known/apple-developer-merchantid-domain-association returns a long token via curl.
Test mode keys live in production
What goes wrong: Customers think they bought; Stripe accepts the test card silently; no revenue arrives. By the time you notice (usually via a customer complaint), 5-50 fake orders have shipped.
How to avoid: Stripe → Settings → Payments → confirm "Test mode" is OFF. Run a real $1 purchase with a personal card to verify money actually moves before opening to traffic.
Running both Stripe card and PayPal card fields
What goes wrong: Checkout shows two separate card forms (one from Stripe, one from PayPal). Shoppers do not know which to use, bounce rate climbs 15-20% on the payment step.
How to avoid: In PayPal Payments settings, disable "Standard Card Fields" if Stripe is your card processor. Keep PayPal balance + Smart Buttons as the PayPal-specific path.
Webhooks blocked by security plugin
What goes wrong: Wordfence or iThemes blocks POST requests from Stripe/PayPal IP ranges. Orders stay in "Pending payment" forever. Customers email asking where their order is. You blame WooCommerce.
How to avoid: Whitelist /wc-api/ in the security plugin firewall. Add Stripe IP ranges (https://stripe.com/docs/ips) to allowlist. Re-test webhook delivery from Stripe → Webhooks → Send test event.
Skipping Blocks Checkout because of plugin incompatibility
What goes wrong: You stay on Classic Checkout because one legacy plugin demands it. Result: 300-500ms slower page load, no access to Stripe Link / Cash App Pay, and worse mobile CR.
How to avoid: Audit which plugin forces Classic. Upgrade or replace it. Blocks Checkout is the future of WooCommerce — Classic is on a deprecation path.
Recap
Done — what's next
How to set up WooCommerce tax and shipping zones
Read the next tutorial
Hand it off
Most WooCommerce payment setups look 'done' but ship with Apple Pay broken on iOS and webhooks half-configured. A vetted WooCommerce specialist will wire Stripe + PayPal + Apple Pay + webhooks end-to-end and validate on real devices in 1-2 sessions. From $14-16/hr — typical setup engagement is $300-600 one-time.
See specialist rates
If you are starting from zero and don't have Stripe in your broader stack, WooPayments is simpler — same processor under the hood (Stripe), but managed entirely from inside WordPress with no separate dashboard. If you already use Stripe for subscriptions, Stripe Tax, or other apps, install Stripe directly so everything is in one Stripe account.
Five usual culprits: (1) you tested in Chrome on iOS — Apple Pay only works in Safari. (2) Domain not verified in Stripe → Settings → Apple Pay. (3) Site has mixed content (an http:// image breaks HTTPS). (4) Payment Request Buttons toggle is off in the Stripe plugin settings. (5) You changed domains and the merchant identifier still points at the old one.
Strongly recommended for WooCommerce 8.3+. Blocks is faster (300-500ms TTI improvement), supports newer payment methods (Stripe Link, Cash App Pay, Klarna messaging), and is where all future Woo development happens. Classic Checkout still works but is on a deprecation path.
HPOS stores orders in dedicated database tables instead of wp_posts. Required for stores doing 1,000+ orders/month — it dramatically improves admin dashboard speed and queries. Enable in WooCommerce → Settings → Advanced → Features → toggle 'High-Performance Order Storage.' All modern gateways support HPOS; legacy plugins might not.
Stripe and WooPayments: 2.9% + 30¢ per US card transaction (international + premium cards higher). PayPal: 3.49% + 49¢ for PayPal balance/cards on small businesses. Apple Pay / Google Pay: same as the underlying card processor (no additional fee). No monthly fees on any of the three for standard processing.
Yes, but requires a third-party plugin like 'Conditional Payment Methods for WooCommerce.' Common use case: hide PayPal for subscription products, hide credit cards in a B2B store that requires invoicing. Use sparingly — every hidden gateway is a lost potential conversion.
WooCommerce
Tax and shipping is where most Woo stores ship broken. Wrong sales-tax rates trigger audits; wrong shipping rates cost 5-15% of completed checkouts. This walks the full configuration including automated tax via WooCommerce Tax and zone-based rate tables.
WooCommerce
Customer says 'checkout did not work.' You test and it seems fine. The order is stuck in 'Pending payment' or never created at all. This is the diagnostic sequence Woo specialists run — payment, webhook, plugin conflict, theme override, Blocks vs Classic.
WooCommerce
Most Woo owners install the Meta Pixel via the official plugin, see 'Connected,' and assume iOS shoppers are tracked. They are not. Without server-side Conversions API + event_id deduplication, you lose 30-50% of attribution. Here is the full setup.
WooCommerce
DIY WooCommerce is a great idea — until your plugin count crosses 30, your checkout breaks intermittently, and PageSpeed sits at 35. This is the honest framework: when the cost of self-managing exceeds the cost of hiring, and how to tell which side you're on.
WordPress
Most WordPress GTM installs are wrong in subtle ways — snippet in the wrong position, missing <noscript> tag, or hardcoded into a theme that updates monthly. This walks through the install that actually survives.