HustlePay Payment Connector for WooCommerce
| 开发者 |
hustlepaydev
davidbanner owlvano |
|---|---|
| 更新时间 | 2026年9月11日 02:02 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPL-2.0+ |
| 版权网址: | 版权信息 |
详情介绍:
HustlePay Payment Connector for WooCommerce connects WooCommerce stores to the HustlePay checkout orchestration service.
The plugin lets customers split a WooCommerce order across available payment methods, while actual payment authorization, processing, settlement, refunds, disputes, and chargebacks remain with the merchant's configured third-party payment service providers (PSPs), such as Stripe, Mollie, PayPal, NMI, or Finix.
HustlePay is not a bank, payment service provider, payment processor, money transmitter, merchant of record, or settlement provider. HustlePay provides a non-custodial checkout orchestration layer that routes payment instructions to the PSP accounts selected and configured by the merchant.
An active HustlePay account is required. Merchants are also responsible for maintaining their own accounts and agreements with the PSPs they choose to use.
安装:
- Install and activate WooCommerce.
- Upload and activate this plugin.
- Go to WooCommerce > Settings > Payments.
- Enable HustlePay.
- Enter the HustlePay publishable and secret API keys for test and/or live mode.
- Configure the payment providers you want to use in your HustlePay dashboard.
常见问题:
Is HustlePay a payment provider or payment processor?
No. HustlePay provides checkout orchestration software. Payment processing, settlement, refunds, disputes, chargebacks, and financial compliance remain with the merchant's selected PSPs.
Which payment methods are supported?
The available methods depend on the PSPs and payment methods configured for the merchant in HustlePay. Common examples include cards, wallets, PayPal, Stripe-backed methods, Mollie-backed methods, NMI-backed methods, and Finix-backed methods where supported by the merchant account.
Does the plugin store card data?
No. The plugin does not store full card numbers or CVVs in WordPress.
Can I test before going live?
Yes. The plugin includes test and live modes. Use the HustlePay test credentials and matching PSP test configuration before enabling live checkout.
What happens if part of a split payment fails?
The checkout session status is returned by HustlePay and the configured PSPs. WooCommerce order status is updated through the HustlePay callback/webhook flow.
Which WooCommerce versions are supported?
The plugin supports WooCommerce 8.0.0 and higher and declares HPOS compatibility.
What happens to my data if I uninstall the plugin?
Gateway settings (API keys, test/live mode, etc.) are removed. Order-level HustlePay references (payment IDs, refund IDs, and similar reconciliation data stored as order meta) are kept by default, so reinstalling the plugin does not strand historical orders without the references needed for refunds or reconciliation. To fully remove that data as well (e.g. when decommissioning a site), add define( 'HUSTLEPAY_REMOVE_ALL_DATA', true ); to wp-config.php before uninstalling — the same convention WooCommerce core itself uses for its own WC_REMOVE_ALL_DATA.
更新日志:
0.9.6
- Fixed: concurrent webhook deliveries or retried checkout requests for the same order could race and double-complete a payment or mint duplicate HustlePay payment sessions. Requests for the same order are now serialized.
- Fixed: a HustlePay-initiated refund and an admin-triggered "Refund via HustlePay" retry could race and double-book the refund ledger. Refunds now go through the same per-order serialization as webhooks.
- Fixed: a refund reported by webhook could fail to create its WooCommerce refund record and then never retry on redelivery, leaving the order's refund ledger permanently short. Redelivered refund webhooks now retry until the recorded refund matches what was actually refunded.
- Fixed: a refund request that timed out with no response was reported the same as an outright failure. The order is now flagged that the outcome is unverified before it's retried, instead of looking like nothing was attempted.
- Fixed: when a refund webhook's WooCommerce refund record failed to create, the order admin screen still offered "Refund via HustlePay" as a safe retry even though the order was already marked refunded and could never be retried that way. "Refund via HustlePay" is now disabled and "Refund manually" is offered instead for this case.
- Order line totals sent in the HustlePay checkout session payload now round to the store's currency precision and reflect the line's actual (post-discount) total rather than the product's current catalog price.
- Fixed: the checkout session token was localized on an order's pay-page without verifying the visitor holds that order's key, exposing a valid HustlePay session token to anyone with the order ID.
- Fixed: a split-payment refund where some transactions succeeded and others failed left WooCommerce's refund record deleted, with no way to see what had actually been refunded or retry safely. The order is now flagged for reconciliation, the per-transaction outcome is recorded on the order, and "Refund via HustlePay" can be retried safely until it's fully resolved. Manual refunds remain unavailable from this screen.
- Refund responses are now validated strictly — a malformed or type-loose
okfield (e.g. the string"false") can no longer be misread as a successful refund. - Fixed: refund requests and webhook signature verification used the gateway's current test/live mode setting instead of the environment a payment actually used, so switching modes after a payment could send its refund to the wrong endpoint or fail webhook verification. Each order now records the environment it paid in, and refunds/webhooks resolve against that instead.
- Uninstalling the plugin no longer deletes HustlePay's order/refund reference meta by default — reinstalling now preserves the history needed for refunds and reconciliation. A full data wipe can still be opted into via the
HUSTLEPAY_REMOVE_ALL_DATAconstant/filter.
- Add timestamp and event_id replay protection to the payment-status webhook — rejects callbacks outside a 300s freshness window and dedupes on event_id.
- Fixed a PHP 8 fatal error on the WooCommerce-missing/inactive admin notice (undefined text-domain constant).
- Admin scripts/styles no longer load on every wp-admin page — scoped to this gateway's settings screen and order-edit screens only.
- Fixed: a late or out-of-order webhook could no longer flip an already-paid or refunded order back to failed.
- The payment return-flow redirect now verifies a signed, order-bound token before trusting the order.
- Fixed the uninstall routine: it now actually removes HustlePay's order meta and transients (the cleanup queries never matched the real keys, so nothing was removed before).
- Removed the processing-fee toggle and its checkout fee logic — merchants could disable the fee via the setting, defeating its purpose; fee enforcement belongs on the widget side.
- Fixed refunds: the WooCommerce admin refund action now calls the HustlePay refund API instead of only marking the order as refunded locally. Partial-amount refunds are rejected (not supported by HustlePay), and split-payment orders are only reported as fully refunded when every transaction succeeds.
- Locked the refund amount field to the correct refundable total for HustlePay orders and removed the "Refund manually" option, which never actually notified HustlePay that a refund happened. The refund controls are disabled once an order has nothing left to refund.
- Fixed: retrying a refund on a split-payment order now succeeds once every transaction is refunded, including legs a previous attempt already refunded (HustlePay reports those as an "already refunded" error on retry, which no longer counts against the overall result).
- Fixed: orders with a partial refund recorded before HustlePay refund integration existed are now blocked with a clear message instead of silently failing every refund attempt.
- Added a guard so refunds can't be requested on orders that were never actually paid via HustlePay.
- Fixed refund error messages sometimes showing the literal text "Array" instead of the actual upstream error detail.
- Refund failures are now always written to the WooCommerce log (source: hustlepay_payment), even when debug logging is disabled.
- The HustlePay refund ID and per-transaction result are now stored on the order for support/reconciliation.
- Added PayPal as a separate payment service provider.
- Added NMI as a payment service provider.
- Added a processing fee toggle in plugin settings.
- Updated and synchronized the codebase.
- Minor logic improvements.
- Made checkout session validation independent of the logged-in WordPress user to support order-pay links across customer, admin, and cached page contexts.
- Fixed checkout session creation by avoiding WordPress REST cookie nonce handling for the HustlePay order nonce.
- WordPress.org distribution cleanup.
- Clarified that HustlePay is a checkout orchestration connector, not a payment processor or PSP.
- Documented external service usage, transmitted data, Terms of Service, and Privacy Policy.
- Removed the self-hosted plugin updater from the WordPress.org build.
- Bundled the HustlePay icon locally instead of loading it from the HustlePay CDN.
- Fixed the missing admin notice fallback when WooCommerce requirements are not met.
- Major UI/UX changes and improvements: updated the visual style, added animations, and improved input behavior.
- Payment methods are now set up as a single list; order and priority depend on dashboard configuration.
- Added optional appearance configuration for the widget, including fonts, colors, and borders.