Payment Gateway for Authorize.net for WooCommerce

1.0.25

• Improved – Tested with WordPress 7.1.2.

1.0.24

• Fixed – WooCommerce Subscriptions: every automatic renewal was charged twice in the same scheduled run. The gateway’s renewal handler was registered once by WooCommerce and a second time by the Checkout Blocks integration, so each renewal charge was submitted twice: Authorize.net rejected the duplicate (“Error 11: A duplicate transaction has been submitted.”), and that rejection then marked the already-paid renewal order as Failed and put the subscription On hold – so the customer was charged, yet received a renewal invoice asking them to pay again. Renewal handlers now run exactly once per renewal. If this affected your store: those Failed renewal orders were in fact paid – verify the charge in the Authorize.net Merchant Interface, then set the order back to Processing and reactivate the subscription. Thanks to @gordonium for the precise report.
• Fixed – As a permanent safeguard, a renewal order that already has a completed payment can never be charged again or flipped to Failed by a duplicate attempt, whatever triggers it: the duplicate is skipped and recorded as an order note instead, and Authorize.net’s own 120-second duplicate-transaction window remains active on all renewal and saved-card charges.
• Fixed – The Checkout Blocks integration created its own private copies of the card, eCheck and Google Pay gateways on every page load; it now reuses the gateways WooCommerce has already loaded. This also stops the same duplication elsewhere: saving the gateway settings no longer validates credentials and re-registers the Authorize.net webhook twice, “Capture Authorized Payment” no longer submits the capture twice (which left a stray “Capture failed” note on a successfully captured order), and removing a saved card no longer sends the profile deletion to Authorize.net twice.

1.0.23

• Fixed – Payments that Authorize.net accepted but held for review (Advanced Fraud Detection Suite) were marked as Failed orders with the misleading reason “Error I00001: Successful”, so customers who had already been charged were told the payment failed and paid again. These orders now go On hold with the transaction ID and a note telling you to approve or decline the transaction in the Authorize.net Merchant Interface. Approvals and ordinary declines are unchanged.
• Added – Order status now follows the outcome of a fraud review automatically: approving a held transaction in Authorize.net completes the order, declining it cancels the order and restores stock. Existing stores are updated on their own after this release – no settings need to be re-saved, no webhook is replaced, and any extra event types you added to the webhook yourself are kept.
• Improved – Card, eCheck and Google Pay orders held for review are never flipped to Failed by a later error during checkout, and “Capture Authorized Payment” is hidden while a transaction is still under review.
• Improved – Refunding an order whose payment is still under review now tells you to approve or decline the review in Authorize.net first, instead of returning a gateway error. Authorize.net does not allow these transactions to be refunded or voided until the review is settled.
• Fixed – With the transaction type set to “Authorize only”, a post-purchase order bump or upsell charge (CheckoutWC, FunnelKit) moved the original order back to On hold and replaced its transaction ID with the bump’s. The order now keeps its own status and transaction reference, and the extra authorization is recorded in an order note so you can capture it in the Authorize.net Merchant Interface.
• Added – Developers: the duplicate-transaction window sent to Authorize.net can now be set with the easyauthnet_authorizenet_duplicate_window filter, which turns on Authorize.net’s own protection against a customer submitting the same payment twice. The default is unchanged.

1.0.22

• Fixed – In rare cases checkout could fail at the final step with “There was an error processing your order.” and no explanation, because an unexpected PHP error during payment stopped WooCommerce from returning a valid response. The gateway now reports a proper error message and records the cause in WooCommerce > Status > Logs. Successful payments and ordinary card declines are unaffected.
• Improved – Tested with WooCommerce 11.0.

1.0.21

• Added – Accounting integration support: every order now carries its Authorize.Net transaction reference, including pre-authorized card payments and eCheck (ACH). QuickBooks connectors and similar bookkeeping tools can reconcile these orders against the gateway automatically.
• Improved – eCheck orders keep their transaction reference through settlement, so your books stay in step with the payment as it clears. Your configured eCheck order status is unchanged.
• Improved – Streamlined payment gateway registration for smoother compatibility with third-party plugins that list your store’s payment methods.

1.0.20

• Added – Google reCAPTCHA v3 fraud protection for card and eCheck checkout, blocking card-testing attacks. Optional and off by default; enable it under the Credit Card settings tab with your own v3 keys.
• Added – CheckoutWC compatibility: post-purchase one-click order bumps are charged to the card saved during checkout, with refund support.
• Added – WooCommerce Subscriptions: admins can now change or repair a subscription’s payment method from the subscription edit screen, and a recovered failing payment method is applied to future renewals automatically.
• Fixed – Changing a subscription’s payment method from My Account charged the customer immediately; the new card is now saved without any charge.
• Fixed – WooCommerce Pre-Orders “charge upon release” now works end-to-end: the card is saved at checkout and charged automatically when the pre-order is released.
• Fixed – FunnelKit upsells: guest checkout upsells are now supported and a declined upsell charge shows the real decline reason instead of failing silently.
• Improved – Safer detection of third-party plugins to prevent rare fatal errors caused by other plugins’ autoloaders, and stricter saved-card validation so a payment can only use cards saved by this gateway.