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.

For standard Checkout, 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. Managed Payments uses a different tax flow: saved product discounts are sent to Stripe, which calculates the final customer tax. Verified product net, tax and total amounts are recorded in the WooCommerce order. Inclusive prices retain their inclusive amount; Stripe determines the net/tax split. Inconsistent rounding or coupon totals stop checkout rather than silently changing a price. See the Managed Payments accounting FAQ below.

Yes. The free edition supports an optional Managed Payments path for one-time purchases of eligible automated digital products through Hosted Checkout, Embedded payment page and Embedded popup. It is disabled by default. Activate the service in your Stripe account, then open Checkout Settings > Managed Payments and review the merchant acknowledgement before enabling it. Each purchased simple product or variation must be virtual, opted in, assigned an accurate supported digital tax category and covered by the product eligibility confirmation. Variations can inherit the parent's complete classification, use their own complete settings or be excluded. The product editor's configuration status is not Stripe approval; saving a product does not submit an approval application or synchronize a permanent Stripe catalog. Stripe decides account, product and transaction eligibility. This integration does not make every product, service, business or country eligible. Read Stripe's eligibility requirements. Start in a sandbox and verify payment, return handling and signed webhook delivery before live use.

Managed Payments uses one payment model for the entire cart. Its supported scope excludes physical items, subscriptions, shipping and additional fee lines. Quantities are fixed once Stripe Checkout opens; customers can change them in the WooCommerce cart beforehand. Stripe controls Managed Payments payment-method availability, so the plugin's ordinary payment-method selection and adjustable-quantity settings do not override it. This initial Managed Payments flow also does not forward the plugin's standard Checkout branding, language, optional phone-number or terms-checkbox settings. Stripe's applicable defaults control those aspects of its interface. Configure and test Managed Payments separately from standard Checkout. The default mixed/ineligible-cart policy blocks checkout and asks the customer to adjust the cart. Alternatively, you can explicitly choose standard Stripe Checkout for the entire cart and acknowledge the merchant and tax responsibilities. No item in that fallback transaction uses Managed Payments. The plugin does not split the payment or silently switch to standard Checkout after a Stripe rejection. Eligible WooCommerce coupon discounts applied in the cart are allocated to the saved product amounts. Coupons with per-customer limits need a known customer identity before checkout; a guest without a usable saved billing email may need to sign in. Coupon eligibility, reservation and exact rounding checks still apply. There is no live WooCommerce coupon recalculation inside Managed Payments.

After verification, the order records Stripe's final customer net, tax and gross in its original integration currency. If Stripe presents another currency to the customer, the verified presented amount is shown separately; it does not replace or add to the order total. The pre-discount WooCommerce subtotal is a comparison amount, not a Stripe tax invoice. The Managed Payments accounting panel provides a per-order customer-amount ledger, not a settlement or tax-remittance report. Customer tax does not establish how much Stripe withheld or the merchant's own liability. Tax-coverage exceptions apply; review Stripe's tax guidance. Stripe/Link supplies transaction documents and applicable tax invoices. WooCommerce confirmations remain order/fulfilment records; review third-party invoicing integrations to avoid duplicate tax invoices. Eligible verified payments use the same full/partial amount-only refund panel. Refunds do not restock products, revoke downloads or allocate reversals to item or tax lines, including after a full refund. Original item/tax accounting remains unchanged and needs reconciliation with Stripe/Link documents. Signed refund events and Refresh Stripe status can reconcile independently issued refunds. Pending, unknown or conflicting outcomes require review before another refund is requested.

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.

Setup & health provides a checklist for saved Stripe settings, the selected checkout experience, payment-page configuration, HTTPS and webhook setup. Refresh checks reads local settings and any cached connection result. Check Stripe connection makes one read-only Stripe account request; it does not create a payment or verify every restricted-key permission, payment method or wallet. The webhook indicator records recent verified Checkout delivery for the matching configuration and test/live mode. A received event is not proof that an order was paid, and sandbox delivery does not verify live delivery. Complete a sandbox checkout and confirm its order status as part of setup. Copy support report includes version information and diagnostic states, excluding API keys, signing secrets, site addresses and customer/order details. Review the report before sharing it with support.

Open an eligible paid order and find the Stripe refunds panel. Select Refresh Stripe status to verify the original payment and existing refunds. Enter a partial amount or choose Use remaining amount, then review the amount, currency and original payment mode before confirming. Opening the panel and refreshing status do not request a refund. WooCommerce records the refund only after Stripe confirms success. Refunds are amount-only: they do not restock products, allocate amounts to product, fee, shipping or tax lines, or revoke downloads. Keep the original payment's test/live API credentials available, including permissions to read the original payment and create/read refunds. The panel requires a matching saved Checkout Session, payment reference and order snapshot; older orders without these records cannot be refunded automatically. If a refund is pending, unknown or requires review, refresh its status and inspect the original payment in Stripe. Do not create another refund or add a manual WooCommerce refund for the same Stripe refund. An uncertain request is not automatically resubmitted; an available retry uses the saved request identity. Resolve review warnings before requesting more money back. Stripe-initiated refunds can be synchronized for eligible plugin orders through the configured refund events or Refresh Stripe status.

Yes, for standard Checkout. 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. Managed Payments uses Stripe's own available payment methods instead of this selection. 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, for standard Checkout 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. Managed Payments always keeps quantities fixed once checkout opens. 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. For refund synchronization, also subscribe to refund.created, refund.updated and refund.failed. A verified refund event triggers a check of Stripe's refund records; it does not count as Checkout-delivery health evidence. Verify refund-event delivery separately in the matching environment before relying on automatic updates. Use a publicly reachable HTTPS endpoint and verify successful delivery in Stripe. Signed webhooks allow order updates when the customer does not return to your store. They are required for Managed Payments, 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.