Title: GivePayments for WooCommerce Author: GiveCorporation Published: April 14, 2025 Last modified: June 17, 2026 --- Search plugins ![](https://ps.w.org/givepayments-for-woocommerce/assets/banner-772x250.png?rev= 3272520) ![](https://ps.w.org/givepayments-for-woocommerce/assets/icon-256x256.png?rev=3272520) # GivePayments for WooCommerce By [GiveCorporation](https://profiles.wordpress.org/givecorporation/) [Download](https://downloads.wordpress.org/plugin/givepayments-for-woocommerce.1.0.22.zip) * [Details](https://wordpress.org/plugins/givepayments-for-woocommerce/#description) * [Reviews](https://wordpress.org/plugins/givepayments-for-woocommerce/#reviews) * [Installation](https://wordpress.org/plugins/givepayments-for-woocommerce/#installation) * [Development](https://wordpress.org/plugins/givepayments-for-woocommerce/#developers) [Support](https://wordpress.org/support/plugin/givepayments-for-woocommerce/) ## Description GivePayments for WooCommerce is a robust and secure payment gateway plugin that integrates the GivePayments system with your WooCommerce store. This plugin provides a seamless transaction process and lets you manage your payment settings directly from your WordPress dashboard. #### Key features include: * **Seamless Integration:** Easily connect your WooCommerce store with the GivePayments system. * **User-Friendly Configuration:** Configure payment options via a streamlined admin interface. * **Enhanced Security:** Robust measures to ensure the protection of customer payment data. * **Comprehensive Support:** Detailed documentation, FAQs, and dedicated support channels are available. ### External Services This plugin connects to the GivePayments payment processing API to facilitate credit and debit card transactions for your WooCommerce store. #### GivePayments API * **Service purpose**: Processes credit and debit card payments for your WooCommerce store. * **Data transmission**: - During connection testing: API key, merchant ID, and environment settings are sent to verify credentials. - During payment processing: Customer payment details (card information, billing information), order details, and transaction amounts are transmitted securely to GivePayments for processing. - All data is transmitted securely using SSL encryption. * **Frequency**: Data is transmitted when: - A connection test is performed in the admin dashboard - A customer initiates a payment at checkout - A refund is processed through the WooCommerce order management system * **Terms of Service**: [GivePayments Terms of Service](https://portal.givepayments.com/terms_of_service) * **Privacy Policy**: [GivePayments Privacy Policy](https://portal.givepayments.com/privacy) Note: You will need a GivePayments merchant account to use this plugin. Visit [GivePayments Merchant Portal](https://givepaid.givepayments.com/signup) to sign up or access your account. ### Support For support, documentation, or troubleshooting, please visit: [GivePayments Support Page](https://merchants.givepayments.com/support/home) Alternatively, you can email us at support@givepayments.com. ## Installation 1. Upload the entire `givepayments-for-woocommerce` folder to your `/wp-content/plugins/` directory. 2. Activate the plugin via the **Plugins** menu in WordPress. 3. Navigate to **WooCommerce > Settings > Payments** and select the GivePayments gateway to configure your settings. ## FAQ ### How does GivePayments Gateway for WooCommerce work? Once activated, the plugin adds a new payment gateway option to your WooCommerce checkout, enabling customers to choose GivePayments during the payment process. ### How do I configure the plugin? After installation, go to **WooCommerce > Settings > Payments**, select the GivePayments option, and follow the on-screen instructions to complete the setup. ## Reviews There are no reviews for this plugin. ## Contributors & Developers “GivePayments for WooCommerce” is open source software. The following people have contributed to this plugin. Contributors * [ GiveCorporation ](https://profiles.wordpress.org/givecorporation/) [Translate “GivePayments for WooCommerce” into your language.](https://translate.wordpress.org/projects/wp-plugins/givepayments-for-woocommerce) ### Interested in development? [Browse the code](https://plugins.trac.wordpress.org/browser/givepayments-for-woocommerce/), check out the [SVN repository](https://plugins.svn.wordpress.org/givepayments-for-woocommerce/), or subscribe to the [development log](https://plugins.trac.wordpress.org/log/givepayments-for-woocommerce/) by [RSS](https://plugins.trac.wordpress.org/log/givepayments-for-woocommerce/?limit=100&mode=stop_on_copy&format=rss). ## Changelog #### 1.0.22 * Fixed: webhook reliability for stores that share a single GivePayments API key/ Merchant ID across multiple sites (multi-store). Order payment confirmations ( capture/settle) now reliably reach and update the correct site instead of being misrouted or dropped. * Fixed: webhook deliveries that arrive from a superseded or stale GivePayments registration are now self-healed — the plugin re-verifies the delivery against the live provider event (requiring a verified order, charge, or subscription identifier) and processes it for the correct order/subscription instead of dropping it. * Fixed: the webhook endpoint URL is now derived deterministically, so it no longer drifts between the pretty-permalink and `index.php?rest_route=` forms between requests. * Fixed: webhook deliveries are no longer stranded when the same API key / Merchant ID is added to additional sites — superseded registrations are reconciled and misrouted deliveries are self-healed so each order is confirmed on the correct site. * Changed: superseded webhook registrations are now cleaned up, and the “Re-register Webhook” action updates the existing registration in place (keeping its id and signing secret) instead of creating a duplicate. * Added: a “Webhook health” panel in the gateway settings showing the active webhook registration (id), the secret fingerprint, and the resolved endpoint URL. #### 1.0.21 * Fixed: customers no longer receive the “Processing order” confirmation email while a payment is still being authorized — or when it is ultimately declined. An order now stays in “Pending payment” until the card is genuinely approved ( authorized or captured) and only then moves to “Processing”, so a declined card no longer triggers a premature order-confirmation email. In-flight payments can still be voided from the order screen. * Fixed: automatic payment reversals (such as a pre-settlement void by the GivePayments risk system) are no longer mislabeled in the order history as a “refund” attributed to an unrelated WordPress user. These reversals now show no user, carry a clear note that GivePayments initiated them, and no funds are implied to have moved when none did. * Changed: a void is now described as “Payment reversal processed via GivePayments” instead of “Refund processed via GivePayments platform”, so a pre-settlement void (including an automated fraud void) is never mislabeled as a customer refund. * Changed: when a merchant voids a payment from the order screen, the resulting reversal entry is now correctly credited to the admin who performed it. #### 1.0.20 * Added: the originating store URL (`source_url`) is now included in the integration source metadata sent with outbound payment and subscription-renewal requests, so each transaction can be attributed to the storefront that initiated it. #### 1.0.19 * Added: partial refunds for GivePayments orders. Merchants can now enter a specific amount on the WooCommerce refund screen and refund it through GivePayments, instead of being limited to refunding the full order. Multiple partial refunds can be issued until the order is fully refunded. * Changed: for captured (pre-settlement) payments the order screen now offers both“ Refund” (for an amount-specific partial or full refund) and “Void full amount”( for a full pre-settlement reversal). Authorized/created payments remain void- only, since partial voids are not supported. * Fixed: refund accounting for partial refunds. A partial refund — whether started from WooCommerce or from the GivePayments platform — is now recorded once for the exact amount returned, and no longer marks the whole order as refunded or creates duplicate refund records when GivePayments sends multiple refund status updates. * Added: email verification (OTP) support at checkout. When GivePayments flags a donor email for verification, the API emails a 6-digit code instead of charging the card. The plugin now detects the `email_verification_required` response, reveals a hidden OTP input in the checkout form (classic and Blocks), and retries the payment with the verified code. Invalid or expired codes re-prompt the customer without failing the order. * Added: integration source metadata is now attached to all outbound mutating API requests (payments, refunds, and subscription renewals). Each request carries plugin name and version, WordPress version, and WooCommerce version, along with a `channel` field that distinguishes direct checkout charges (`official_plugin`) from scheduled subscription renewals (`subscription_renewal`). A `givepayments_integration_source` filter allows site developers to extend or override the metadata. * Added: “Enable Email Validation” setting in the gateway configuration (on by default). When turned off, the plugin tells GivePayments to skip the customer email-validation gate for this store’s checkout payments — the flag is sent per request, so the toggle takes effect immediately on save without any portal or merchant-account change. #### 1.0.18 * Added: merchants can now choose the WooCommerce order status applied after a GivePayments payment settles. The new “Order Status After Settlement” setting defaults to “Completed” to preserve existing behavior, with “Processing” available for physical-goods stores and fulfillment integrations such as ShipHero that treat “Completed” as already fulfilled or shipped. * Changed: immediate settled payment responses and `payment.settled` webhooks now use the configured settled order status while keeping the internal GivePayments payment state as `settled`, so refund and void eligibility remain unchanged. #### 1.0.17 * Fixed: orders that have settled in GivePayments no longer keep showing the “Void” button with the Refund option blocked. When the order screen is opened the plugin now checks the live payment status from GivePayments, so a settled payment correctly offers Refund — even if the settlement notification (webhook) was never delivered or failed to arrive (e.g. a stale webhook registration, signature mismatch, or downtime). The live check is gated to pre-settlement orders only, throttled to once per order per 90 seconds, time-bounded, and fails safely (the existing state is kept) if GivePayments cannot be reached. * Fixed: attempting to Void a payment that has already settled now returns a clear“ use Refund instead” message rather than sending a void the provider would reject. * Fixed: a late or duplicated payment notification can no longer downgrade an order’s recorded payment state (for example flipping an already-settled payment back to “captured”), which previously re-showed the Void button and blocked refunds on a settled order. Recorded state now only moves forward along the payment lifecycle; terminal states (voided/cancelled) and reversals still apply normally. * Fixed: editing a paid GivePayments order in the WooCommerce admin and clicking“ Recalculate” or “Update” no longer clears line item quantities and shipping, which could incorrectly set the order total to $0.00. #### 1.0.16 * Fixed: strengthened duplicate-charge protection at checkout. Customers can no longer be charged twice for the same order if the site experiences a brief server hiccup, timeout, or interruption while a payment is being processed. * Fixed: the order’s transaction reference is now saved as soon as the payment is approved, so the order is reliably protected against a second charge even if a later step (such as saving the card on file or updating the order status) runs into a problem. * Fixed: rapid double-clicks of the “Place order” button, fast retries, and “Confirm form resubmission” / back-button submissions on the block-based checkout no longer slip through and create duplicate charges. * Fixed: when two checkout attempts arrive at exactly the same time for the same order, the second attempt now shows a clear “a payment is already in progress, please wait a moment” message instead of risking a duplicate charge. * Fixed: stuck checkouts caused by an interrupted payment now recover automatically after a short cooldown, so customers are not left with an order that can never be paid. * Fixed: subscription renewals are now protected by the same safeguards as checkout payments. Renewal charges scheduled by WooCommerce Subscriptions, Flexible Subscriptions, WP Swings SFW, and YITH can no longer be billed twice if the renewal job runs more than once. * Fixed: the test connection and webhook registration calls now send the same ` Origin` header that the checkout flow sends, so API keys configured with an ` allowed_origins` restriction no longer pass payments but fail the admin-side test connection and webhook registration. #### 1.0.15 * Added: checkout now blocks payment submission when the customer’s card brand is on the merchant’s blocked list, as configured in the GivePayments platform. The GivePayments API is never called for a blocked brand — the customer receives a clear notice to use a different card. * Added: real-time card brand validation on the checkout form — as the customer types their card number, an inline error is shown immediately beneath the field if their card brand is not accepted, without waiting for form submission or a server round-trip. * Added: card brand configuration is fetched once at page load and cached for 24 hours per environment, so there is no additional API call per checkout request. * Fixed: UnionPay cards (BIN prefix 62) were not detected by the card brand identifier and could not be matched against the merchant’s blocked or accepted brand list. UnionPay is now correctly identified. #### 1.0.14 * Added: the GivePayments API is now fully authoritative for recurring subscription scheduling — subscription status changes (cancellation, completion, payment failure, re-activation) are driven by GivePayments webhooks and reflected automatically in WooCommerce. * Added: cancelling a subscription in WooCommerce now also cancels the recurring billing instruction in GivePayments for all supported subscription plugins (WooCommerce Subscriptions, Flexible Subscriptions, WP Swings SFW, and YITH). * Fixed: cancelling a subscription in one place (WooCommerce or GivePayments portal) no longer triggers a redundant cancel attempt in the other, preventing confusing duplicate notes and unnecessary API calls. * Fixed: Flexible Subscriptions (FSB) subscriptions can now be cancelled correctly— the plugin now follows FSB’s required cancellation flow instead of attempting a direct status jump that FSB rejects. * Fixed: WP Swings SFW subscriptions now show as cancelled in the WPS SFW interface after a webhook-driven cancellation, not just in the WooCommerce order screen. * Fixed: YITH subscriptions created at checkout now correctly inherit the GivePayments recurring billing reference, ensuring webhook-driven status updates and cancellations work for YITH from the first billing cycle. * Fixed: YITH subscriptions created before this update are automatically healed on the next webhook delivery — the plugin locates the correct subscription via the parent order and repairs the missing reference so future events are handled without manual intervention. * Fixed: a fatal PHP error that could occur on Flexible Subscriptions admin screens when WooCommerce Payments is also active, caused by a type incompatibility between the two plugins. * Fixed: subscription metadata is now stored correctly on stores using WooCommerce’s High-Performance Order Storage (HPOS), preventing silent data loss on HPOS-enabled setups. #### 1.0.13 * Fixed: voided payment webhook now acquires the shared refund accounting lock ( gp_refund_acct_) instead of a separate gp_void_acct_ key, preventing a concurrent voided + refunded delivery from each winning an independent lock and creating duplicate WooCommerce refund records. * Fixed: transition_order_to_refunded() re-reads the order status after winning the status mutex so a second concurrent delivery that waited for the lock does not fire update_status(‘refunded’) on an already-refunded order, preventing duplicate woocommerce_order_status_refunded hook invocations. * Fixed: voided payment webhook now deletes the gp_refund_pending_note_ option set by a preceding refund.created event, preventing a stale wp_options row when a refund attempt is abandoned and the payment is voided instead. * Fixed: refund.created webhook now guards against terminal order statuses (refunded/ cancelled/failed) before calling GIVEPAYMENTS_Refund_Guard::mark_pending(), preventing refund-pending meta from being written on already-resolved orders and corrupting the can_refund_order() predicate. * Fixed: amount arithmetic in the refunded webhook handler now uses wc_format_decimal() instead of raw float subtraction, matching the precision used by the chargeback and pre-chargeback refund paths and eliminating rounding drift on stores with non-standard decimal settings. * Added: pre-chargeback refund events handling — pre_chargeback_refund.created, pre_chargeback_refund.approved, pre_chargeback_refund.settled, and pre_chargeback_refund. voided are now fully handled, triggering the appropriate WooCommerce refund record and order status transitions. * Added: warning log entry when a webhook payload arrives without an event id, clearly flagging that duplicate-delivery protection is disabled for that request. #### 1.0.12 * Fixed: chargeback.created and chargeback.settled webhook events now create a WooCommerce refund record matching the full order amount, preventing the refunded amount from displaying as $0 on the order screen. * Fixed: refund accounting lock for chargeback events is now ownership-safe — a unique token is stored with the lock and verified before release, preventing a stalled process from accidentally releasing a lock held by a concurrent delivery. * Fixed: money arithmetic in refund accounting now uses wc_format_decimal() instead of raw float casts, eliminating rounding drift on stores with non-standard decimal configurations or multi-currency setups. * Fixed: wc_create_refund() failure during chargeback webhook processing now returns a negative handler result so the webhook pipeline signals an unresolved delivery( allowing provider retry) instead of silently drifting into an unreconciled state. * Fixed: plugin settings (API keys, webhook secrets, environment config) are no longer deleted on plugin deactivation — they are now only removed when the merchant explicitly deletes the plugin, preventing config loss during plugin updates. * Added: uninstall.php — cleans up all plugin options when the merchant deletes the plugin via the WordPress admin. #### 1.0.11 * Added: GivePayments logo icon is now displayed next to GP-originated order notes in the WooCommerce order admin screen. Notes written directly by the plugin ( payment, refund, void, renewals, webhooks) and side-effect notes generated by WooCommerce core during those operations (status transitions, payment-complete confirmation) are automatically tagged. Legacy notes containing “GivePayments” in their text are tagged as a fallback. #### 1.0.10 * Fixed: duplicate charge prevention — a cross-order dedup sentinel now blocks repeat submissions when a payment API timeout leaves the charge state ambiguous( cURL error 28 / `WP_Error`). * Fixed: WooCommerce Blocks draft-order session pointer is now cleared on API timeout and on synchronous declines so the next checkout attempt creates a clean order instead of reusing the stale pending one. * Fixed: orders marked with `_givepayments_pending_timeout` are now excluded from the WooCommerce auto-cancel unpaid orders cron, preventing the “sale went through then failed” email sequence. * Fixed: $0 order guard — order totals are recalculated before the payment request and, if a prior transaction exists, the confirmed amount is recovered from the API before blocking the submission. * Fixed: per-order checkout mutex prevents concurrent payment submissions for the same order from duplicate Blocks events or browser back-navigation. * Fixed: card brand is now detected from the IIN/BIN and included in the dedup key, preventing false-positive blocks when two cards share the same last-4 digits but differ in network (e.g. Visa vs Mastercard). * Fixed: encryption key generation uses an atomic `add_option()` call instead of a read-then-write pattern, eliminating a race condition that could overwrite the key under concurrent plugin activations. * Fixed: synchronous payment declines (2xx with terminal `processingState`) now clear the Blocks session pointer, matching the behaviour already applied to HTTP 4xx declines. * Fixed: checkout payment errors now follow Stripe-style handling by returning checkout failure with a shopper-visible notice and clearing stale checkout order pointers before retry. * Fixed: HTTP 422 `Invalid Input` payment failures now surface provider field-level validation details when present, instead of only showing a generic invalid input message. * Fixed: failed payment order notes now include the backend/provider error message or explicitly state when no provider message was returned. * Fixed: invalid billing phone numbers are now blocked during checkout when provided, while optional empty phone values remain allowed. * Added: `givepayments_api_timeout` filter allowing merchants and developers to override the HTTP timeout per endpoint and method without patching plugin code. * Improved: POST `/payments` timeout raised to 45 s to reduce false-timeout errors on slower acquiring-network responses. * Improved: dedup sentinel TTL reduced to 5 minutes (was 10) to shorten the customer retry window when a genuine server error occurs with no charge. * Improved: payment error messages are now normalised through a dedicated `GIVEPAYMENTS_Api_Response:: parse_error()` pipeline — field-validation errors (`invalid_input`) are surfaced to customers with human-readable field labels; all other provider error codes and messages are written to order notes only to prevent leakage of fraud scores or internal rule names. * Improved: codebase refactored into focused domain classes (`Payment`, `Refund`,` Webhook`, `Checkout`, `Http`, `Crypto`, `Subscription`) for improved maintainability and testability. #### 1.0.9 * Changed: successful in-flight POST `/payments` responses (`created`, `authorized`,` captured`, `processing`, `processing_issue`) now move orders to WooCommerce ` processing` immediately while webhooks remain authoritative for final reconciliation. * Changed: `refund.created` and `refund.pending` webhooks now mark orders `refunded` in WooCommerce per merchant policy and mirror WooCommerce refund accounting for custom captured / processing_issue void actions. * Changed: refund webhooks that confirm plugin-originated `Void` actions now use payment reversal wording in order notes. * Fixed: captured webhooks now add a visible captured order note even when the order was already `processing`. * Changed: admin actions now show `Void` for `authorized`, `captured`, and `processing_issue` payments; native WooCommerce `Refund` is reserved for `settled` payments. * Fixed: duplicate pending refund notes and duplicate refunded status-transition notes from closely timed or repeated refund webhooks are suppressed. * Fixed: native WooCommerce Refund button no longer briefly flashes before being hidden on GivePayments order screens where it is not available. #### 1.0.8 * Tested up to WordPress 6.9. * Changed: `payment.created` and `payment.authorized` webhook events now move orders into WooCommerce `processing` immediately instead of `pending`, while still allowing later `payment.failed` / `payment.declined` events to transition the order to` failed`. * Fixed: shipping addresses for countries without state/subdivision fields (e.g., Czech Republic, Netherlands) no longer cause GivePayments API validation errors at checkout. * Fixed: WooCommerce Blocks checkout now surfaces the actual GivePayments error message (e.g., fraud blocks, declines) instead of the generic “Something went wrong” message. * Fixed: race condition that could display a stale void amount of 0. * Improved: payment description is now sourced from gateway settings with a safe empty-string fallback. * Improved: production API URL handling and admin UI cleanup. #### 1.0.7 * Maintenance release with internal fixes and version alignment. #### 1.0.6 * Added: subscription adapter registry with MVP adapters for WooCommerce Subscriptions, WP Swings SFW, YITH, and Flexible Subscriptions by WP Desk — enabling card tokenization and renewal payment routing for supported subscription plugins. * Fixed: duplicate void/refund handling and several race conditions when refunds or voids were initiated from WooCommerce. * Fixed: refunds created through the GivePayments API are now correctly marked as `refunded` immediately, and voided transactions display a 0 amount. * Fixed: declined transactions now correctly transition the order to `failed`. * Fixed: native WooCommerce refund button is hidden when only a void action is allowed, preventing conflicting actions. * Fixed: re-register webhook button label and checkout failure edge cases. #### 1.0.5 * Added: recurring payments phase 1 groundwork. * Added: re-register webhook button in the gateway settings. * Added: void action for authorized transactions. * Improved: webhook signature verification, registration handling, and logging for stale entries. * Improved: status lifecycle now relies on the raw provider processing state, with refund/chargeback events no longer overwriting the underlying payment state. * Improved: security hardening, additional sanitization, and redaction of CVV / card number values from logs. * Fixed: webhook transaction ID resolution for voids and refunds, including fallback matching. * Fixed: declined transaction status mapping and refund UI visibility for failed transactions. * Fixed: production and sandbox API base URLs. #### 1.0.4 * Internal release rolled up into 1.0.5. #### 1.0.3 * Fixed API key save/toggle behavior when switching between Sandbox and Production environments. * Improved admin key handling to prevent invalid re-encryption and intermittent 400 payment errors. #### 1.0.2 * Added direct card payment flow improvements for checkout and checkout blocks. * Added native WooCommerce refund integration with GivePayments API. * Improved payment/refund error handling and logging for easier troubleshooting. * Hardened legacy return handling checks for safer order updates. #### 1.0.1 * Patch release #### 1.0.0 * Initial release of GivePayments for WooCommerce. * Seamless integration of the GivePayments payment gateway. * Implementation of user-friendly configuration and enhanced security features. ## Meta * Version **1.0.22** * Last updated **1 week ago** * Active installations **Fewer than 10** * WordPress version ** 6.2 or higher ** * Tested up to **6.9.4** * PHP version ** 7.4 or higher ** * Tags * [integration](https://wordpress.org/plugins/tags/integration/)[payments](https://wordpress.org/plugins/tags/payments/) [woocommerce](https://wordpress.org/plugins/tags/woocommerce/) * [Advanced View](https://wordpress.org/plugins/givepayments-for-woocommerce/advanced/) ## Ratings No reviews have been submitted yet. [Your review](https://wordpress.org/support/plugin/givepayments-for-woocommerce/reviews/#new-post) [See all reviews](https://wordpress.org/support/plugin/givepayments-for-woocommerce/reviews/) ## Contributors * [ GiveCorporation ](https://profiles.wordpress.org/givecorporation/) ## Support Issues resolved in last two months: 0 out of 1 [View support forum](https://wordpress.org/support/plugin/givepayments-for-woocommerce/)