HustlePay Payment Connector for WooCommerce
| 开发者 |
hustlepaydev
davidbanner owlvano |
|---|---|
| 更新时间 | 2026年10月7日 17:09 |
| 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.
- For test and/or live mode, enter the Publishable Key (
pk_…), Secret API Key (sk_…), and Webhook Signing Secret (hmac_…, orsk_…for older accounts) from your HustlePay merchant portal. - 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.
Which API keys does the plugin need?
Three per mode, all from your HustlePay merchant portal. The Publishable Key (pk_…) is used only by the checkout widget in the shopper's browser. The Secret API Key (sk_…) authenticates your store's requests to HustlePay. It is sent only from your server to HustlePay, never to shoppers' browsers. The Webhook Signing Secret verifies the payment updates HustlePay sends back. Stores that were set up before the Secret API Key setting existed keep working with only a Publishable Key, and WP Admin shows a notice until the Secret API Key is entered. Enter it as soon as you have it, because without it the key authenticating your store is the one exposed to browsers.
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.10
- Settings: new Secret API Key field for each environment (test and live). Session creation and refunds now authenticate with it. The Publishable Key is sent only to the checkout widget.
- Settings: while a Secret API Key isn't saved, the plugin falls back to the Publishable Key so existing stores keep working, and an admin notice lists each environment that still needs one.
- Settings: the old API secret fields are renamed Webhook Signing Secret. Saved values are kept.
- Webhooks: signing secrets with the
hmac_prefix are now accepted. Before this, webhook verification failed for stores created after the key split. - Settings: keys are checked on save. The Secret API Key must start with
sk_. The Webhook Signing Secret must be a valid 32-byte secret. The two must be different. - Settings: the Publishable Key field refuses any secret, including
sk_/hmac_values in any case and values matching a saved Secret API Key or Webhook Signing Secret, so no secret can reach the checkout page. - Docs: the External services section of
readme.txtdescribes the three credentials and where each one is sent.
- Checkout widget: one payment method now covers the full order by default. The first method starts at the full amount, and its slider animates once to show the amount can be changed (the animation is skipped when reduced motion is on).
- Checkout widget: a newly added method takes the unpaid remainder. If the total is already covered, the amount is split equally across the editable methods, leaving out payments already made. When a removal leaves one editable method, that method covers the rest.
- Checkout widget: the amount slider stops at the smallest currency unit (for example €0.01) and can no longer go to zero.
- Checkout widget: "Pay now" stays hidden until a method is added and always shows the amount (for example "Pay $64.69"). When the payment is ready it turns into a green gradient button, which can be recoloured through
colorSuccess. It stays disabled while a newly selected method is being created, so the split is final before anything is charged. - Checkout widget: "Add another payment method" is now a secondary button with a plus icon. It is dashed when the total is covered, and reads "Pay remaining $X with another method" while part of the total is unpaid.
- Checkout widget: the hint "Pay with one method, or split the amount between methods." shows while only one method is selected.
- Checkout widget: the amount field updates as you type, not only when you leave the field, and the slider keeps up with live updates while you drag it.
- Added optional single-item layout for the checkout description (
mode: 'single_item') - Added SouthPay as a redirect-based crypto payment method
- Added discount display and optional tip in the order summary before payment
- Fixed: failed card transactions stay editable/retryable instead of locking like cancelled/refunded ones
- NMI card payments now collect and submit billing address for AVS, fixing AVS-decline issues
- Fixed: an admin "Refund via HustlePay" attempt and a concurrent HustlePay refund webhook could race and leave the order marked "refunded" with no matching WooCommerce refund record, with no way to recover it on webhook retry.
- Fixed: a refund request that lost the per-order lock to contention used to proceed unlocked, risking two real refund requests being sent to HustlePay for the same payment. It now returns a retryable error instead of proceeding.
- Fixed: the password-visibility toggle button on the gateway's settings screen had an undersized clickable area, below WCAG accessibility guidelines.
- 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.