Uncaught Error

Thanks for checking.

I’ve gone back through the stack trace and there are two points that may help narrow this down.

The fatal is not occurring on the classic checkout flow. It is occurring during a Store API cart request on:

/wp-json/wc/store/v1/cart/add-item

In our case, the call stack shows WooCommerce recalculating cart totals during that request, which then triggers your fee callback:

WC_Cart->calculate_fees()
→ Apply_Payment_Processing_Fee->apply_gateway_fee()

At that point, WC()->session is an instance of Automattic\WooCommerce\StoreApi\SessionHandler, not the classic WC_Session_Handler. The fatal is specifically:

Call to undefined method Automattic\WooCommerce\StoreApi\SessionHandler::has_session()

So the immediate issue is not whether the endpoint exists, but whether the plugin assumes that WC()->session always exposes the classic handler methods during Store API / Blocks requests.

For reference, WooCommerce currently has an open core bug describing the same problem in isolation, including the same has_session() fatal when a Store API cart request is made and code calls WC()->session->has_session(). That report notes that the Store API session handler is not interface-compatible with the default session handler in this scenario. (GitHub)

A few details that may explain why you are not seeing it consistently:

1. It only appears when the plugin’s fee logic actually runs during cart recalculation on a Store API request.
2. A traditional add-to-cart flow may not reproduce it, even if the product page uses modern WooCommerce components elsewhere.
3. Reproduction is more reliable when testing against the real Blocks / Store API cart flow rather than just calling the endpoint in a way that does not reach the same fee path.

A minimal reproduction path on our side is:

1. Activate WooCommerce and Conditional Extra Fees for WooCommerce.
2. Ensure the fee logic is enabled in a way that causes apply_gateway_fee() to run during cart totals calculation.
3. Add a product to cart through the Store API / Blocks flow so WooCommerce recalculates fees on /wc/store/v1/cart/add-item.
4. The request reaches apply_gateway_fee(), where WC()->session->has_session() is called on Automattic\WooCommerce\StoreApi\SessionHandler, producing the fatal above.

Based on the trace, the safe fix seems to be to avoid assuming WC()->session always supports has_session() in Store API contexts, for example by adding a guard such as method_exists( WC()->session, 'has_session' ) before calling it, or by using a Store API-safe approach that does not depend on that classic session handler method being present.

If helpful, I can provide the exact stack trace and environment details from the site where this occurs via email/offline.

We’ve now identified a second fatal in the same plugin during WooCommerce Store API cart requests.

This one occurs on:

GET /wp-json/wc/store/v1/cart?_locale=user

Fatal:
Call to a member function get_shipping_country() on null

File:
admin/selection_rules/rules/country.php:115

From the plugin code, the country rule does:

$user_country = WC()->customer->get_shipping_country();

with no null check on WC()->customer.

Combined with the earlier fatal on:

WC()->session->has_session()

during:

POST /wp-json/wc/store/v1/cart/add-item

this suggests the plugin is assuming classic WooCommerce customer/session objects are always present during Store API requests.

WooCommerce’s Cart and Checkout blocks use the Store API for normal frontend cart activity, so these requests are part of expected customer browsing, not necessarily bot traffic. The issue appears to be that the plugin is not handling Store API contexts defensively.

At this point we have two separate Store API fatals in the plugin:

1. StoreApi\SessionHandler::has_session()
2. WC()->customer being null in the country rule

That looks like a broader Store API compatibility issue rather than an isolated edge case.

Thanks. To be clear, this was observed on a live production site rather than an isolated test install, so I cannot yet give you a guaranteed single-click sandbox repro.

What I can give you is the exact plugin version, the failing code paths, the request endpoints, and the configuration conditions that make the issue reachable.

Plugin version:
conditional-extra-fees-for-woocommerce 1.1.49.42

We have now seen two separate fatals in your plugin during WooCommerce Store API cart requests.

1. Payment processing fee path

File:
public/class-apply-payment-processing-fee.php:28

Code:

if (isset(WC()->session) && WC()->session->has_session()) {

Failing request:
POST /wp-json/wc/store/v1/cart/add-item

Fatal:
Call to undefined method Automattic\WooCommerce\StoreApi\SessionHandler::has_session()

This path becomes reachable when:

• WooCommerce is recalculating cart fees during a Store API cart request, and
• the payment processing fee feature is enabled so apply_gateway_fee() runs.

2. Country rule path

File:
admin/selection_rules/rules/country.php:115

Code:

$user_country = WC()->customer->get_shipping_country();

Failing request:
GET /wp-json/wc/store/v1/cart?_locale=user

Fatal:
Call to a member function get_shipping_country() on null

This path becomes reachable when:

• cart fees are calculated during a Store API cart/cart refresh request, and
• at least one fee rule uses the Country/Continent condition so Pi_cefw_selection_rule_country->conditionCheck() runs.

So while I cannot yet provide a clean sandbox repro from our side, the expected reproduction setup on your side should be:

For the first issue:

1. Fresh WooCommerce install.
2. Activate only WooCommerce + Conditional Extra Fees for WooCommerce.
3. Enable a payment processing fee rule so Apply_Payment_Processing_Fee->apply_gateway_fee() is active.
4. Trigger Store API cart add-to-cart flow via /wp-json/wc/store/v1/cart/add-item.
5. Observe whether WC()->session is a Store API session handler on that request and whether has_session() is called.

For the second issue:

1. Fresh WooCommerce install.
2. Activate only WooCommerce + Conditional Extra Fees for WooCommerce.
3. Create any fee rule using the Country/Continent condition.
4. Open the cart or trigger /wp-json/wc/store/v1/cart?_locale=user.
5. Observe whether WC()->customer is null when conditionCheck() runs.

Even if you cannot reproduce immediately, both code paths currently assume classic WooCommerce objects are always available in Store API requests:

• WC()->session->has_session()
• WC()->customer->get_shipping_country()

Those assumptions are what our production traces are failing on.

If helpful, I can also send the full stack traces for both errors.