Free Stripe Checkout for WooCommerce

They are redirected. When the shopper presses Place Order, the plugin creates a Stripe Checkout Session and sends them to Stripe's own hosted payment page. They enter their card there, and Stripe returns them to your WooCommerce order-received page. The plugin renders no card fields at any point, so card numbers never touch your server. This is the design of the plugin rather than a setting — there is no embedded or inline mode to switch on.

It is a real trade-off and we will not pretend otherwise. What you give up is on-site funnel control. What you get back is a payment page Stripe maintains and optimises continuously — mobile-tuned, localised, with autofill and whichever methods your Stripe account has enabled — plus a card form your theme can never break. If a customer backs out of the Stripe page they land on the WooCommerce order-pay form and can retry or choose another method, so an abandoned redirect is not immediately a lost order; the Stripe session lasts an hour, after which it expires and the order is cancelled. If you run high volume and measure every step of an on-site funnel, an embedded gateway is the better fit and we would rather you used one.

Yes to both. The plugin ships a dedicated Blocks payment-method integration with its own client bundle, so it appears on the block checkout as well as the classic shortcode checkout, and it declares compatibility with both the checkout blocks and custom order tables, so WooCommerce will not list it as an incompatible extension. Return-leg reconciliation runs on the block Order Confirmation as well as the classic template. It is skipped for a visitor who cannot view the order's details, in which case the webhook confirms the order as usual.

No plugin can make a store PCI compliant, and any plugin that says it can is overselling. What this one does is reduce the surface: because the payment page is delivered entirely by Stripe, no cardholder data is entered on, processed by, or stored on your server. Merchants whose payment page comes wholly from their provider are generally in SAQ A territory, while embedding a gateway's JavaScript to tokenise cards on your own checkout page generally puts you in SAQ A-EP, which since 31 March 2025 carries PCI DSS requirements 6.4.3 and 11.6.1 in full — covering every script on your payment page, including analytics and chat widgets. SAQ A was revised in January 2025 to drop those two requirements, but it added an eligibility criterion in their place: you must confirm your site is not susceptible to script-based attacks. Your acquirer and the SAQ text decide your actual eligibility, and outsourcing the payment page does nothing to secure the rest of your WordPress install.

Yes, and it is not optional. The redirect back to your site is a courtesy; the webhook is the authoritative message that money moved. The plugin subscribes to five events: checkout.session.completed, checkout.session.expired, checkout.session.async_payment_succeeded, checkout.session.async_payment_failed and charge.refunded. Without a valid signing secret saved in the plugin, every delivery is rejected and orders rely entirely on the fallback re-check that runs when the customer lands back on your site — which only rescues orders that are still pending at that moment. You can create the endpoint with one click from the gateway settings, or follow the manual instructions shipped inside the settings screen, which print the exact event list and the endpoint URL for each mode.

Work through it in this order. First, is the webhook endpoint registered for the mode you are in — a live endpoint will not confirm test orders, and mixing test and live keys or endpoints is by far the most common cause. Second, is the signing secret saved and correct. Third, can Stripe actually reach your site: a security plugin, firewall or HTTP-auth-protected staging site will silently swallow deliveries. Fourth, is this a delayed-notification method such as a bank debit or a voucher, in which case the order is correctly on-hold until the funds settle. The gateway settings carry a webhook health panel showing a traffic-light status, when the last delivery arrived, the last event type, and the last result with a categorised rejection reason and a specific fix hint — clock skew, a wrong or missing secret, an unreadable signature header, an unreadable payload, or a non-Stripe caller each get their own. One honest limit: that panel only reports deliveries that actually reached your site, because Stripe publishes no delivery-history API. For deliveries that never arrived, check the Stripe Dashboard's own delivery attempts.

Whatever you have enabled in your Stripe Dashboard. The plugin does not specify a method list at all, so Stripe's own page decides what to show based on your account, the order's currency and the customer's location. That is the quiet advantage of the hosted model — turning a method on is a Stripe Dashboard change, not a plugin update or a per-method settings screen. One caveat: eligibility for methods like Klarna, iDEAL or Bancontact depends on your country, currency and Stripe account. Wallets need no work on your side, because the payment page is on Stripe's own domain, so there is no domain to register. Note also that the plugin adds exactly one payment row to your WooCommerce checkout rather than a row per method, and it adds no express-checkout buttons to your cart or product pages.

Yes, and we would recommend it. The plugin accepts rk_ keys as well as sk_ keys, in both test and live mode, and the settings screen prints the scopes it asks for next to the key field: Checkout Sessions Write, Payment Intents Read, and Refunds Write. Webhook Endpoints Write is only needed if you want the plugin to register or remove the endpoint for you. Decline it and set the endpoint up by hand from the instructions in the same screen.

No to both, and that is a design boundary rather than a gap we are about to close quietly. Every Checkout Session the plugin creates is a one-time payment; it never stores a payment method for reuse, and it declares support only for products and refunds. Automatic renewals need a stored, reusable payment method that can be charged off-session, which a hosted redirect does not produce. If you sell subscriptions or memberships, use a tokenising gateway instead.

Either, and they stay in sync. Full and partial refunds issued from the WooCommerce order screen are sent to Stripe against the order's PaymentIntent in the order's own currency, and each is recorded as an order note carrying the Stripe refund ID. Refunds you issue in the Stripe Dashboard come back the other way through the charge.refunded webhook and become real WooCommerce refunds, de-duplicated by refund ID so nothing is created twice. Two limits worth knowing: an order can only be refunded through WooCommerce if it carries a stored PaymentIntent ID, so orders paid before you installed this plugin cannot be; and Dashboard-side refunds only sync onto orders in processing, completed, on-hold or refunded status.

The plugin starts in test mode and stays there unless the mode setting reads exactly live, so a corrupted setting can never switch real money on. Test and live credentials are stored as separate pairs — API key plus webhook signing secret each — and switching mode never discards the other pair. Paste your test key, press Test connection, register a test webhook endpoint (test mode needs its own endpoint and its own secret), then place an order using one of Stripe’s test cards. Watch the order move to processing — or completed, for downloadable products — and the webhook health panel go green.

The plugin is free. There is no per-transaction cut taken by us, no premium tier, no gated payment methods, no license key and no upsell. Separately, Stripe charges you its own processing fees directly; those vary by country and payment method and are published on Stripe’s pricing page. Nobody else is in the middle.

The difference is architectural, and everything else follows from it. The official extension embeds Stripe Elements in your own checkout page; this plugin hands the whole payment off to Stripe's hosted Checkout page. That means no card-collection JavaScript on your storefront, nothing to re-theme when your checkout changes, a smaller PCI scope, and payment methods governed from your Stripe Dashboard rather than per-method plugin settings. The honest cost is that customers do leave your site, and that you give up subscriptions, saved cards and express-checkout buttons. Running both plugins at once is not recommended: overlapping gateways make refunds and webhook routing ambiguous. Orders already paid through another gateway keep their history untouched.

Download the ZIP from this page, go to Plugins → Add New → Upload Plugin, and activate it; WooCommerce must already be active. After that, updates behave like any other plugin: they appear in your normal WordPress updates screen and install with one click, served from the PimiPay update endpoint at w4dev.com. No license key is requested, nothing is activated, and the updater adds no admin menu of its own. This is the same mechanism every commercial WordPress plugin uses.