SA Hosted Checkout for WooCommerce

Yes. When the plugin is enabled and configured and the cart requires payment, supported cart and mini-cart buttons take customers to the selected Stripe Checkout experience. Direct visits to the ordinary checkout page also open Stripe Checkout instead of displaying the standard WooCommerce form. Both classic Checkout shortcode pages and WooCommerce Checkout block pages are supported by this replacement flow. Customers do not need to fill in two checkout forms. The plugin replaces the standard form rather than adding a payment-method choice inside the WooCommerce Checkout block. JavaScript must be enabled. Empty carts, orders with no payment due, order-payment links, receipt pages and API requests are not taken over by the ordinary checkout-page replacement. The separate classic gateway remains available for supported existing-order payment flows. Custom checkout buttons, themes and checkout extensions require compatibility testing. In popup mode, intercepted cart-button clicks do not emit WooCommerce's cart_proceed_to_checkout event, so extensions that depend on this event need separate testing.

Yes. In Stripe Settings, choose Hosted Checkout, Embedded payment page, or Embedded popup. Hosted redirects to Stripe and remains the default for existing installations. Embedded page and popup display Stripe's payment interface within your website. Some payment methods still redirect customers to their bank or payment provider for authorization. Embedded Checkout needs a publishable key from the same Stripe account and mode as the configured secret or restricted key. Use HTTPS in production. Apple Pay and Google Pay also depend on Stripe payment-method domain registration, an eligible account, browser and device.

Use Automatic to create a dedicated payment page when you save Stripe Settings. Alternatively, publish a page containing the [sahcfwc_checkout] shortcode and select it. The page must not be password protected or assigned as the WooCommerce Cart, Checkout or My Account page. Customers reach it through a private order-payment link; adding the shortcode alone does not create a payable order. Popup checkout uses the same payment page for existing-order payment links and returns from payment providers. Closing the popup does not cancel the order or create another payment session; customers can reopen it while the session remains payable. Exclude the payment page and its query-string URLs from page caching. After an administrator changes the checkout mode, an existing popup session may continue on the dedicated payment page instead of being replaced. If payment has already been verified for the shopper's unchanged cart, reopening checkout returns the existing order receipt. If the paid cart cannot be matched safely, checkout stops with a review notice instead of starting another payment.

Yes. Enable Checkout branding in Stripe Settings to set the checkout display name, background and button colors, font and corner shape. Leave individual fields empty, or disable the override, to use Stripe Dashboard branding. Custom logo overrides apply to Hosted Checkout only. Stripe's Embedded Checkout does not accept per-session logo or icon overrides, so those images are not sent in Embedded page or popup mode. A Hosted logo must be a publicly accessible HTTPS image with a URL path ending in .png, .jpg, .jpeg, .jfif, .pjpeg, .pjp or .svg. Query strings are allowed. WebP, localhost, private-network and password-protected images cannot be used. Branding changes apply to new checkout sessions and do not change your Stripe account settings, receipts or invoices. An already-open session retains its existing settings. Stripe controls the payment interface, so arbitrary WordPress CSS cannot style the inside of its protected payment frame.

WooCommerce calculates the cart before Stripe Checkout opens. The plugin creates an order and uses that saved total, including eligible discounts, fees, shipping and taxes, for payment. Positive fees and taxes are shown as separate lines, with shipping shown as a separate charge. Changing an address on Stripe Checkout does not recalculate WooCommerce shipping or taxes. Optional quantity changes affect eligible product amounts, but leave these charges and existing discount amounts fixed. Stores with address-dependent shipping, tax or discount rules should test their calculation and checkout paths before going live.

Yes. To use coupons, enable "Enable the use of coupon codes" under WooCommerce > Settings > General and save your changes. The plugin respects this setting; it does not enable or disable coupons automatically. Customers apply coupon codes in the WooCommerce cart before opening Stripe Checkout, and eligible discounts are included in the payment total. This does not add coupon-code entry to Stripe Checkout. Coupon eligibility and usage restrictions still apply. Coupons limited to one use per customer require login. For higher per-customer limits, guests must have a valid billing email available before applying the coupon; otherwise, they must log in.

Enter the appropriate Stripe API credentials and webhook signing secret in Stripe Settings, select the matching test or live mode, and enable checkout. Start in test mode and check any setup notice if checkout remains unavailable.

Yes. In Payment Methods, keep the default card-only mode or select a custom set of methods from the supported catalog. Examples include Cards, Link, iDEAL | Wero, Klarna, SEPA Direct Debit, ACH Direct Debit and USD bank transfer. Card brands such as Visa and Mastercard are included under Cards, not separate payment-method choices. USD bank transfer and ACH Direct Debit are different methods. Enable the relevant methods in your Stripe account. Stripe determines availability using the account, business and customer countries, currency, order amount and other eligibility rules; selecting a method does not guarantee it will be displayed. See Stripe's payment-method support. Link requires Cards to be selected. Canadian pre-authorized debit also requires a Personal or Business mandate type in the plugin settings. Delayed-payment methods require a configured, working Stripe webhook.

Yes. In Checkout Settings, use automatic browser-language detection or select one of the Stripe languages listed by the plugin. This changes Stripe Checkout, not the language of your WordPress site or product names.

Yes, when you enable the free "Allow quantity changes in Stripe Checkout" option. It is disabled by default and requires a working Stripe webhook. Eligible simple products and variations can be adjusted within the allowed limits. Sold-individually products and product lines that need split prices are not adjustable. Carts containing fractional quantities keep fixed quantities. Customers cannot remove a product by reducing its quantity to zero, and discounts can impose a higher minimum. WooCommerce discount amounts, shipping charges, fees and taxes stay fixed when quantities change in Stripe Checkout. Coupon rules and other cart pricing rules are not recalculated. Enable only if these fixed charges are appropriate for your store. For example, an existing percentage coupon's calculated discount amount does not grow when the customer adds more units in Stripe. The maximum defaults to 10 per eligible product and can be set from 1 to 999999. A higher quantity already in the cart is preserved, and available stock may lower the allowed maximum. For stock-managed products, the allowed maximum is reserved while checkout is open, not just the starting cart quantity. Choose a cap appropriate for your inventory. Verified final quantities and totals are synced to WooCommerce after checkout is submitted. A submitted checkout is not proof of payment: delayed payments remain on hold until Stripe confirms payment. If the plugin cannot verify the final quantities or stock reservation, the order requires review before fulfillment.

Copy the webhook endpoint URL shown in Stripe Settings and configure it in the matching Stripe test or live environment. In Stripe Workbench > Webhooks, create an event destination for Your account, use the Snapshot payload format, and choose Webhook endpoint as the destination type. The route is /wp-json/sahcfwc/v1/webhooks/stripe-listener on your site's URL; copy the plugin's displayed Webhook URL rather than the WordPress admin address or a guessed URL, particularly if WordPress is installed in a subdirectory. Subscribe to checkout.session.completed, checkout.session.async_payment_succeeded and checkout.session.async_payment_failed, then save that endpoint's signing secret in the plugin. A webhook signing secret is separate from an API key. Test and live endpoints have separate signing secrets. The plugin also accepts payment_intent.succeeded and charge.succeeded as payment-confirmation events. You do not need to select every Stripe event. Use a publicly reachable HTTPS endpoint and verify successful delivery in Stripe. Webhooks allow order updates when the customer does not return to your store. They are required for delayed-payment methods and quantity adjustment; keep them working for ordinary card payments as well.

Basic checkout branding is free, including the display name, colors, font and corner shape, plus a custom logo for Hosted Checkout. The premium version provides additional custom text and text, number and dropdown fields.

The premium edition includes a session-management screen for sessions created by this plugin, with customer, order and payment-status details. In either edition, you can also review payment activity in your Stripe Dashboard.