How to Set Up Stripe in WooCommerce: Cards, Apple Pay, and Google Pay (2026)

A customer builds a takeaway order, adds extra cheese, chooses collection at 7:15, and reaches checkout. Payment should be the boring part. But a missing wallet button—or a successful charge that leaves the order pending—can turn dinner into a support ticket.

Setting up Stripe in WooCommerce involves more than connecting an account. You need working payment methods, reliable order updates, and checkout buttons that respect everything your restaurant needs to prepare an order. This 2026 guide covers that setup, including the checks that matter before accepting live payments.

What You Need Before Connecting Stripe to WooCommerce

Stripe processes payments between your checkout and the financial institutions involved in approving them. WooCommerce stores the order; Stripe handles payment processing and reports the result. Later, eligible funds move from your Stripe balance to your bank account through payouts.

Your business must be based in a country or region Stripe supports, with an eligible business activity and the required banking details. Customers can often pay from elsewhere, but payment methods, currencies, and restrictions vary. Check Stripe’s current availability and restricted-business documentation rather than assuming every country or restaurant business model qualifies.

Before installation, have these pieces ready:

• A valid HTTPS certificate covering the entire storefront and checkout.
• A functioning WooCommerce checkout with currency, taxes, delivery, and pickup configured.
• A Stripe account with required business verification completed and no outstanding payment-enablement requirements.
• Authorized administrator access to WordPress and sufficient Stripe permissions to connect the business account.
• A recent backup and, preferably, a staging site for compatibility testing.

This tutorial uses the WooCommerce Stripe Payment Gateway extension. WooPayments is a separate payment solution with its own onboarding and management experience, even though it uses Stripe infrastructure. You don’t need both for this setup. Two overlapping gateways can create duplicate card options and make troubleshooting unnecessarily confusing.

Don’t budget from a universal transaction-fee figure. Stripe pricing varies by account country, payment method, and factors such as international cards and currency conversion. Review applicable dispute and refund costs too. Payout timing is separate from payment approval; initial payouts can take longer, and schedules depend on your account and country.

Install the Stripe Extension and Connect Your Account

Identify the correct extension

In WordPress, open Plugins → Add New Plugin and search for “WooCommerce Stripe Payment Gateway.” Check the exact name and that the author is WooCommerce. Several extensions include “Stripe” in their names; installing whichever appears first isn’t a sensible payment-security policy.

Review compatibility information for your WordPress and WooCommerce versions, install the extension, and activate it. If you’re replacing another gateway, keep a record of its configuration and any outstanding authorizations or subscriptions before disabling it. Existing payment arrangements may need a separate migration plan.

Connect the business account

Open WooCommerce → Settings → Payments and find Stripe. Depending on the extension version and onboarding state, you’ll see a setup, connect, or manage action. Use its guided account-connection flow rather than copying keys into unrelated plugins.

Sign in with an authorized Stripe user and carefully select the intended business account. This matters when an agency manages several restaurants or an owner has separate legal entities. Confirm the business identity and account identifier—not merely a familiar display name.

Grant only the access required by the official connection process. Don’t share the owner’s password with a contractor; use individual accounts with appropriate permissions, and remove temporary access after the work is finished. Kitchen staff don’t need payment-configuration privileges.

Check the connection, not just the confirmation message

Return to the extension’s settings and inspect its account, connection, and webhook information. The precise labels and layout change between releases. Look for a connected account, payment eligibility, and any webhook or configuration warnings; complete any remaining Stripe verification requests.

Webhooks are notifications Stripe sends to your site about payment events. Where the connection flow configures them automatically, verify that configuration before adding endpoints manually. A connected account alone doesn’t prove WooCommerce can receive payment updates.

Test and live environments are separate. Test credentials process simulated payments; live credentials process real money. Confirm which environment the extension is using, and don’t assume that a successful test connection proves live webhooks are configured.

Record the WordPress, WooCommerce, and Stripe extension versions used during setup. Any screenshots or staff instructions should be checked against those installed versions, especially the locations of test mode, payment methods, express checkout, and connection diagnostics. Match the function, not an old screenshot’s button position.

[IMAGE: WooCommerce Stripe setup checklist beside an illustrative settings screen highlighting the selected business account, test-mode indicator, and webhook connection status without exposing credentials]

Configure Card Payments, Apple Pay, and Google Pay

Enable cards and make the charge recognizable

In Stripe’s WooCommerce payment settings, enable the gateway and card payments where those controls are available. Save the configuration, then inspect the actual checkout as a customer. An enabled setting isn’t proof that your theme displays it correctly.

If your version exposes a checkout title or description, use plain language such as “Credit or debit card.” Some checkout components control their own wording, so not every label will be editable. Avoid internal names such as “Stripe Main Account.” They mean nothing to someone ordering a burger.

Configure a recognizable statement descriptor in the relevant Stripe business settings, and review any descriptor-suffix option exposed by the extension. Stripe and card networks impose formatting restrictions, and banks can display descriptors differently. Use a permitted version of your trading name rather than an unfamiliar holding-company name.

Choose capture behavior deliberately

Immediate capture is usually the simpler choice for prepaid takeaway orders: an approved payment is captured without a separate staff action. Authorization-only processing instead places a temporary hold that must later be captured through a supported workflow.

An authorization is not a completed charge. It can expire, and capture deadlines vary by payment method and transaction circumstances. Don’t build a process around the assumption that every hold lasts a fixed number of days.

If you authorize first so staff can accept an order before charging, test the entire acceptance, capture, cancellation, and expiry workflow. Also confirm which enabled payment methods support that behavior. A kitchen ticket printing successfully doesn’t demonstrate that funds were captured.

Enable express checkout and verify domain requirements

Find the extension’s express-checkout settings and enable the available Apple Pay and Google Pay options. Depending on the release, these may appear within a shared express-checkout configuration. Choose button locations deliberately; we’ll cover restaurant-specific placement next.

Your payment pages need HTTPS. Stripe’s web-wallet integrations can also require payment-method domain registration, with Apple Pay requiring domain verification. The extension may handle parts of this automatically, but check its diagnostics and Stripe’s payment-method domain settings rather than assuming registration succeeded.

Check each actual checkout hostname, including relevant subdomains and staging domains used for testing. Redirects, maintenance pages, or security rules can interfere with verification.

Wallet visibility is conditional. The shopper’s device, browser, country, saved eligible cards, and wallet configuration all matter. Apple Pay testing needs a supported Apple Pay environment; Google Pay needs a supported browser/device configuration and payment setup. Neither button is guaranteed to appear for every visitor, so keep ordinary card checkout available.

Make Express Checkout Work for Restaurant Orders

A wallet can supply payment and contact details quickly. It can’t decide whether a pizza should be gluten-free or whether a customer meant delivery rather than collection. That’s where an otherwise successful Stripe installation can fail operationally.

For a WooCommerce restaurant, my default would be to start with express payments on the checkout page, then consider cart and product-page buttons after testing. Even checkout-page placement needs validation: the wallet flow must respect required fields before the payment completes.

FoodMaster’s WooCommerce restaurant ordering system is a natural fit for the ordering layer, bringing delivery, pickup, and dine-in orders together with POS, kitchen display, QR table ordering, and automatic printing. Stripe handles payment processing alongside that ordering workflow. Test the combination on your installed versions rather than treating either plugin’s feature list as a compatibility guarantee.

Keep required choices ahead of payment

Map the fields your restaurant actually needs: meal size, required modifiers, delivery address, fulfillment method, and scheduled time. Decide which are essential and verify that server-side validation rejects incomplete orders. A field marked with an asterisk in the browser isn’t enough.

Tipping needs the same attention. If you use custom or preset WooCommerce checkout tips, confirm the selected amount reaches the final order total and wallet payment sheet. An express button placed before the tipping controls may make the tip option effectively invisible.

Check whether your checkout uses the WooCommerce Checkout Block or classic checkout. The Stripe extension, ordering tools, modifiers, and tipping controls must support your chosen format and enabled features. Classic checkout customizations don’t automatically work in Blocks.

Test a takeaway order with moving parts

Build an example order: a large pizza, a paid topping, collection at 7:15, and a £2 tip. Change the topping, switch fulfillment method, and then open the wallet sheet. Compare its total with the cart, including taxes and any delivery fee.

Complete payment and inspect the order details, kitchen output, and collection time. Then deliberately omit a required modifier. If product-page express payment can complete an incomplete order, leave that placement disabled. Fewer shortcuts beat faster mistakes.

[IMAGE: Restaurant checkout test showing a customized pizza, collection time, optional tip, and wallet payment total, with matching order details displayed on a kitchen ticket]

Test Successful Payments, Declines, Refunds, and Order Updates

Enable test mode in the extension and confirm you’re viewing the corresponding test environment in Stripe. Use test orders with addresses and email accounts you control. On staging, prevent simulated orders from reaching production kitchen printers, delivery dispatch, or live customer notifications.

Run a payment test matrix

Stripe documents these card numbers for its test environment. Use a future expiry date and a valid-format CVC; provide other requested details in the required format. Never enter real card details into test-mode card fields.

• Successful card payment: 4242 4242 4242 4242. Check the amount, currency, order reference, and resulting WooCommerce status.
• Insufficient-funds decline: 4000 0000 0000 9995. Confirm the customer receives an understandable error and the order isn’t treated as paid.
• 3D Secure authentication: 4000 0000 0000 3220. Complete the simulated challenge, then separately test failed or abandoned authentication.
• Guest checkout: repeat a successful payment without signing in, if your store permits guest purchases.
• Interrupted return: close the customer tab after payment completion and verify that the payment notification still updates the order.

These examples come from Stripe’s documented testing scenarios; check its current testing documentation when running additional cases. Wallet testing has separate device, domain, and provisioning requirements. You can’t simply add the 4242 test card to a normal consumer wallet; follow the documented wallet-testing procedure for your integration.

Follow the payment into WooCommerce

A typical paid physical-food order moves to Processing, not automatically to Completed. Authorization-only payments may remain On hold until capture. Exact behavior can vary with extensions and order configuration, so inspect the order notes alongside the status.

In Stripe, locate the corresponding payment and examine its amount, currency, payment status, and associated PaymentIntent identifier. In WooCommerce, compare the order’s transaction reference and notes. Webhook delivery records should show that the relevant notification reached the store successfully.

Test an actual gateway refund

Open a paid test order, choose Refund, enter a partial amount, and select the gateway refund action rather than a manual bookkeeping-only refund. Confirm the refund appears against the payment in Stripe and in WooCommerce’s order notes and refund totals.

A partial refund doesn’t necessarily change the whole order to Refunded. Check delivery charges, taxes, and tips according to your refund policy. If staff will issue refunds directly in Stripe, test that separate path too—don’t assume every line-item detail will synchronize back.

Switch to live mode carefully

Disable test mode, verify the live account and webhook connection, and check for outstanding account restrictions. Confirm wallet domains and enabled payment methods in the live configuration. Don’t rely on the test badge disappearing as your only check.

For a permitted live validation, place a small genuine order using an authorized payment method and reconcile it in both systems. Any refund may still leave processing costs under your pricing agreement. This is a real transaction, not a place for test-card numbers.

Troubleshoot Missing Wallet Buttons and Payments That Stay Pending

Start with the symptom and one affected order or device. Changing six settings at once may make the problem disappear, but it also makes the cause impossible to identify.

• Apple Pay or Google Pay is missing: check express-checkout settings and selected button locations, then test a supported device/browser with an eligible wallet. Verify HTTPS, domain registration, and the active payment environment. Investigate JavaScript errors and optimization tools that delay payment scripts.
• Authentication fails or loops: reproduce the challenge in test mode. Check browser errors, blocked scripts, redirects, and extension conflicts on staging. A customer declining or abandoning authentication isn’t necessarily a technical fault.
• The account appears disconnected: confirm the selected Stripe account, current permissions, and unresolved verification requirements. Use the extension’s connection flow to restore access rather than pasting credentials into random settings.
• Webhook delivery fails: inspect Stripe’s delivery attempts and HTTP responses. Maintenance mode, firewall rules, password-protected staging, and server errors can prevent delivery. Exempt the required endpoint appropriately without disabling site-wide security.
• Stripe shows success but WooCommerce stays pending: match the exact payment to the order and confirm capture status. Check webhook delivery, WooCommerce errors, and any relevant failed scheduled actions before changing the order manually.

WooCommerce logs are available under WooCommerce → Status → Logs. Look for Stripe-related entries around the transaction time; enable the extension’s diagnostic logging if needed. In Stripe’s developer event and webhook tools, inspect the matching payment events and delivery attempts. Dashboard navigation can change between versions.

Keep checkout, cart, and customer-specific payment responses out of full-page caching. When requesting help, provide plugin versions, timestamps with time zone, order references, and redacted error messages. Remove secret keys, webhook signing secrets, client secrets, authorization headers, and unnecessary customer information from screenshots and logs.

Most importantly, staff should verify an existing payment before asking a customer to pay again. “Pending in WooCommerce” doesn’t prove that no charge occurred.

The setup is ready when payment, order details, and kitchen instructions agree—not merely when a wallet button appears. Keep a short regression checklist and rerun it after significant checkout updates. That’s how payment stays the boring part of ordering dinner.