Important issues to be reviewed

Hello,
We have been using the plugin for quite some time and have identified several important issues affecting compatibility, reliability, and WooCommerce standards compliance.

1. Incorrect Total Amount Used During Payment Initialization

The plugin currently uses the cart total instead of the actual WooCommerce order total.
Affected areas include:

• WC_Gateway_XPay_Cards_Build.php (line 99) passes WC()->cart->total into get_payment_build_payload()
• WC_Gateway_XPay_Cards_Build.php (line 121) also builds the hidden payload using WC()->cart->total
• WC_Gateway_NPG_Cards_Build.php (line 130) behaves similarly for NPG Build fields
• WC_Gateway_NPG_API.php (line 582) uses that total to create the NPG Build order/payment session

According to WooCommerce gateway standards, process_payment( $order_id ) should always rely on the final WC_Order object and use:

$order->get_total();

instead of cart totals.

2. Frontend Checkout Refresh / Fee Compatibility Issue

There is a frontend refresh/timing problem that makes the plugin incompatible with WooCommerce fees and dynamic checkout recalculations.

The problem is that the payment payload is generated at the wrong moment in the checkout update cycle. As a result, when a customer switches away from a payment method that adds fees and then switches back to Nexi credit card, the fee is not properly removed from the Nexi payment payload and the customer ends up paying more.

Reproduction scenario:

1. Customer selects a payment method that adds a fee
2. Customer then switches back to Nexi credit card
3. WooCommerce recalculates the checkout total and removes the fee
4. The Nexi payload is not regenerated at the correct point after this recalculation
5. Customer may be charged an outdated amount that still includes the removed fee

There is also a separate checkout refresh issue: when the customer removes an item from the cart using the delete/remove button on the checkout page, the credit card form fails to render and does not appear again.

The reliable final amount should still be taken from the finalized order inside:

process_payment( $order_id )

using:

$order->get_total();

3. Incorrect Order Number Function Used

The plugin continues to use get_id() instead of the WooCommerce-compatible order number API.

This breaks compatibility with:

• Sequential Order Numbers plugins
• Custom order number plugins
• ERP/accounting integrations relying on displayed order numbers

WooCommerce documentation clearly distinguishes the two:

get_id()

Returns the internal database ID.

get_order_number()

Returns the public/display order number.

The plugin should consistently use:

$order->get_order_number();

for all customer-facing and external transaction references.

4. Orders Automatically Canceled Despite Successful Payment

Many successfully paid orders remain in pending payment status and are later automatically canceled by WooCommerce.

The root cause appears to be the payment notification requests coming from Nexi servers using the following User-Agent:

Apache-HttpClient/4.5.13 (Java/1.8.0_161)

This User-Agent is extremely common in automated traffic and is frequently blocked by hosting firewalls, WAFs, Cloudflare rules, ModSecurity, and anti-bot systems.

As a result:

• Nexi callbacks fail
• WooCommerce never receives the successful payment confirmation
• Orders remain pending payment
• WooCommerce later auto-cancels them

While IP allowlisting is suggested, it is not salways supported.

A more reliable solution would be for Nexi to use a distinct/custom User-Agent for payment notifications.

Nexi notification documentation:
Nexi Notification Specs

5. Incompatibility with WooCommerce Order Pay Page

Because the plugin does not fully follow WooCommerce payment gateway guidelines, it is not compatible with the standard WooCommerce order payment page:

/checkout/order-pay/1234/?pay_for_order=true&key=...

This affects:

• Failed payment retries
• Manual payment links
• Admin-created orders
• Subscription renewals
• Deferred payment flows

The plugin should support WooCommerce’s native order-pay flow properly using the provided order object rather than relying on cart/session state.

6. “Name on Card” Validation Is Too Restrictive

The “Name on card” field currently rejects full stops (.).

This is problematic because many card issuers use names that include initials or abbreviations, for example:

A. Smith
J.P. Morgan

7. Hosted Apple Pay / Google Pay Cancel Button Does Not Work

On the hosted Apple Pay and Google Pay pages, the button:

CANCEL THE TRANSACTION

does not function correctly.

Most of these issues have already been reported multiple times over the past several years, but no complete resolution has been provided across recent plugin versions. Let us know if you are planning to fix them.

Thank you.