Fixed: order_description sent to the Solidgate hosted Payment Page is now prefixed with the WooCommerce order number (e.g. “Order #123: T-Shirt x1, Coffee Mug x2”), so a Solidgate dashboard order can be matched back to the WooCommerce order that created it without cross-referencing the generated Solidgate order_id. Not applied to the Integrated form’s REST init call, which fires before the WooCommerce order exists and has no order number yet.
Fixed: All string fields sent to Solidgate (order_description, order_id, customer_email) are now clamped to their documented API maximum length (255, 255, and 100 characters respectively) before submission, preventing error 2.01 (length validation) responses.
2.8.4
Fixed: customer_first_name and customer_last_name are now omitted from the Solidgate API request when empty, preventing error 2.01 “cannot be blank” for guest checkouts where billing name fields are not filled.
2.8.3
Security: payment init endpoint (/wp-json/solid/v1/init) now always reads amount and currency from the server-side WC cart — client-provided values are ignored. Previously a visitor with a valid WP REST nonce could send {“amount”:1} to obtain a $0.01 Solidgate payment form for any cart total.
Security: payment init token is now bound to the WC session customer ID via a hash stored in the transient. A token created in one browser session cannot be consumed by a different session.
Security: auth_ok webhook handler now skips orders already in processing/completed/refunded state, preventing redundant processing on duplicate webhook deliveries.
2.8.2
Fixed: Added a missing/misplaced translators: comment for two translatable strings with placeholders in class-wc-solid-gateway.php (refund pending-confirmation notice and refund-failure order note), per WordPress.org Plugin Check.
Fixed: Shortened the 2.8.0 and 2.6.0 Upgrade Notice entries to comply with WordPress.org’s 300-character limit.
2.8.1
Changed: In Integrated form mode, the native WooCommerce “Place order” button is now hidden on the classic checkout while Solidgate is the selected payment method. The SDK’s own PAY button already authorizes the card and auto-submits the checkout on success, so the native button never did anything useful — it either blocked with an error before the card form was completed, or was redundant after. Hidden/shown dynamically as the customer switches payment methods or WC re-renders the payment box.
2.8.0
Changed: Plugin renamed from “Solidgate Payment Form for WooCommerce” back to “Solidgate Payment Gateway for WooCommerce”. Slug, main plugin file, and text domain updated to solidgate-payment-gateway-for-woocommerce to match. Existing merchant settings (stored under the solid gateway ID) are unaffected.
2.7.4
Fixed: A refund submission that came back “pending” (see 2.7.3) left no trace on the order and nothing stopped a second click on Refund from submitting a duplicate request to Solidgate. process_refund() now writes an order note for every outcome (submitted/pending, confirmed, declined, or request error), and blocks a new refund attempt while an earlier one is still awaiting confirmation, with a clear note explaining not to retry. The webhook handler clears that pending marker once it confirms the refund’s final status, so a genuinely new refund attempt afterward isn’t blocked.
2.7.3
Fixed: Admin-initiated refunds (WooCommerce > Orders > Refund) were confirmed as soon as Solidgate’s refund API responded with any order object, without checking whether the refund transaction itself had actually cleared. For APM methods (iDEAL, confirmed in testing) the API response is frequently still “processing” at that point, so WooCommerce recorded the refund as successful before Solidgate had confirmed it. process_refund() now only reports success once the refund transaction’s status is “success”; a “processing” result is reported back to WooCommerce as a pending error (so WooCommerce does not record a premature refund) and the confirmed refund is created automatically by the webhook handler once Solidgate reports “success” (see 2.7.2). A “fail” status is reported to the admin immediately.
Note: because WooCommerce’s refund screen is synchronous, a “pending” result surfaces as a WooCommerce error notice rather than a success message, even though the refund was actually submitted and accepted by Solidgate — the order will show as refunded automatically once the webhook confirms it, with no action needed.
2.7.2
Fixed: process_webhook_charge_refunded() created the WooCommerce refund as soon as a refund webhook arrived, even though the refund transaction itself could still be “processing” (or later fail) — e.g. an iDEAL refund isn’t final the moment it’s initiated. Now waits for the refund transaction’s own status to reach “success” before creating the WC refund; a “fail” status is logged as an explicit order note instead of being silently ignored, and pending statuses are logged and left for a follow-up webhook.
Added: idempotency guard against duplicate refund webhooks (Solidgate’s own webhook docs note duplicates can occur) — each processed refund transaction ID is recorded on the order so a repeated “success” webhook for the same refund can’t create a second WooCommerce refund on a partially-refunded order.
2.7.1
Fixed: APM (BLIK, iDEAL, etc.) refunds initiated from the Solidgate Hub never appeared in WooCommerce. Unlike card refunds, alt_gate refund webhooks never change order.status to “refunded” — it stays at the order’s last payment status (e.g. “approved”) — and only add a type: “refund” entry to the transactions array. The dispatcher now checks for that entry before treating an “approved”/”settle_ok” webhook as a new charge, and routes it to the refund handler instead.
Fixed: process_webhook_charge_refunded() read the refund amount and transaction ID from transaction.amount/transaction.id, fields that only exist in card_gate payloads. APM refund webhooks have no singular transaction object, so the refund amount resolved to nothing. Now falls back to the matching transactions[] entry when the singular field isn’t present.
2.7.0
Fixed: Refunds initiated from the WooCommerce admin (Orders > Refund) always called Solidgate’s card API (pay.solidgate.com), regardless of how the order was actually paid. Solidgate’s v1 API uses domain-specific hosts — APM orders (BLIK, iDEAL, MB Way, Bizum, etc.) live on gate.solidgate.com, not pay.solidgate.com — so refunding an APM order returned a “Blocked by WAF” error. The payment method is now parsed from the webhook (order.payment_method for card, order.method for APMs) and stored on the order, so process_refund() routes the request to the correct host: pay.solidgate.com for card/Apple Pay/Google Pay, gate.solidgate.com for everything else.
Fixed: The webhook’s transaction ID capture read transaction.id directly, which doesn’t exist in APM (alt_gate) webhook payloads — only a transactions array does. This meant set_transaction_id() / payment_complete() received an empty transaction ID for every APM order. Now resolves the ID from either shape.
Fixed: The “Solid charge complete” order note always logged “Method: default” for card orders, because it only checked order.method (the APM field name) and never order.payment_method (the card field name).
2.6.5
Fixed: solid_order_success_callback() (the browser redirect to success_url) always re-verified payment with a live status() API call, even when the webhook had already confirmed and completed the order moments earlier. This caused false “Payment could not be verified” rejections on successful APM (iDEAL, tested) payments where the follow-up status() call didn’t return the same result as the webhook. Now checks whether the order is already processing/completed/refunded (webhook-confirmed) first, and only falls back to the live status() call when no completing webhook has landed yet — same server-side verification guarantee, no redirect is trusted blindly.
2.6.4
Debug: solid_order_success_callback() now logs the raw status() API response. Seen in the field: for an APM order (iDEAL, alt_gate), the webhook confirms status “approved” but the browser-redirect status check comes back with an empty status, incorrectly rejecting a successful payment. Root cause not yet confirmed — this logs the actual response shape so the fix can target the real cause instead of guessing.
2.6.3
Fixed: order_description / order_items sent to Solidgate were built with esc_html() (HTML-entity encoding, the wrong tool for a plain-text API field) and a Name ( qty ); format, producing values like Test product ( 1 ); — special symbols like parentheses and semicolons are not safe in these fields. Both the Hosted Payment Page and Integrated form flows now sanitize product names and descriptions to letters, numbers, spaces, and basic safe punctuation only, and use a plain Name xQty format.
2.6.2
Fixed: Webhook handler read the Solidgate event type from $_GET[‘type’], a query parameter Solidgate never sends (the type is sent as the SOLIDGATE-EVENT-TYPE header). This made every incoming webhook resolve to an empty event type, so no webhook was ever processed and paid orders stayed stuck on “on-hold” indefinitely despite the webhook request itself succeeding (200 OK). Now reads the type from the header.
Fixed: The webhook dispatcher only matched the literal event types order.updated / alt_order.updated, but Solidgate’s actual webhook payloads are gate-prefixed (e.g. card_gate.order.updated). Now matches any *.order.updated suffix as well as the older bare values.
2.6.1
Fixed: Hosted Payment Page flow generated its Solidgate order ID as {order_id}_{time()} — second-resolution only, so a quick retry (failed payment, reloaded tab) within the same second could produce a duplicate ID that webhooks use as their order lookup key. Now uses wp_generate_uuid4(), matching the Integrated form flow’s uniqueness guarantee.
Fixed: solid_order_failture_callback() (the browser redirect Solidgate sends the customer to on decline) unconditionally set the order to “failed” with no check of current status. Because the webhook and this browser redirect are independent, unordered channels, a webhook that already completed the order before the browser finished redirecting could get overwritten back to “failed”. The callback now skips orders already in processing/completed/refunded, mirroring the guard added to the webhook handler in 2.6.0.
2.6.0
Changed: Plugin renamed from “Solidgate Payment Gateway for WooCommerce” to “Solidgate Payment Form for WooCommerce”. Slug, main plugin file, and text domain updated to solidgate-payment-form-for-woocommerce to match. Existing merchant settings (stored under the solid gateway ID) are unaffected.
Fixed: Removed a dead webhook route (?wc-api=solid_refund) that was wired to a solid_wh_refund_callback() method that did not exist anywhere in the plugin; refunds are already handled correctly via the main solid_hook webhook route.
Fixed: process_refund() used intval( $amount * 100 ) to convert to minor units, which truncates instead of rounding and can silently refund the wrong amount on certain floating-point totals (e.g. 19.999999999998); now uses (int) round( $amount * 100 ), consistent with the rest of the codebase.
Fixed: A late or duplicate “declined” webhook arriving after an order was already marked processing/completed/refunded by an earlier webhook could incorrectly cancel that already-paid order. process_webhook_charge_declined() now skips orders in those statuses.
Fixed: Blocks checkout and classic checkout used a stale “Visa/Mastercard” fallback title that no longer matched the gateway’s actual default title (“Card payments & Other”); both now use the same default.
2.5.0
Changed: Integrated form mode now renders the card form inline in the payment section immediately when the gateway is selected, instead of opening a modal after clicking Place Order (Stripe/Braintree-style UX).
Changed: Classic checkout no longer depends on jQuery Modal — removed that dependency.
Changed: Both classic and block checkout share the same token-based flow through process_payment().
Changed: /solid/v1/init REST endpoint now reads cart totals from the WC session when called without body parameters (classic checkout), so no extra AJAX is needed for amount/currency.
Added: Loading shimmer animation while the payment form initializes.
Added: Auto re-initialization when cart totals change (coupon or shipping update).
2.4.0
Fixed: Plugin slug renamed to solidgate-for-woocommerce for WP.org compliance.
Fixed: Plugin name updated to “Solidgate Payment Gateway for WooCommerce”.
Fixed: Text domain updated throughout to match plugin slug.
