dev

?It does show webp image is supported under the status, so that doesn’t appear to be the cause.

It’s not possible to test on our store non .web images via the media library are all webp with a CDN redirect however the .webp images when hard coded into the template so doesn’t seem to be a webp issue.

Hello,

In test mode and the preview, the store logo does not show at all and the error is within the logs. Only when the image is hardcoded does it show.

Using simple template does not work either.

Specifically, this code is having to be replaced with an img tag to resolve it. We’ve not changed our logo in sometime or made any changes.

    <td class="header">
        <?php
            if ( $this->has_header_logo() ) {
                do_action( 'wpo_wcpdf_before_shop_logo', $this->get_type(), $this->order );
                $this->header_logo();
                do_action( 'wpo_wcpdf_after_shop_logo', $this->get_type(), $this->order );
            } else {
                $this->title();
            }
        ?>
    </td>

Hello,

We’re using pro v2.15.11 however our logo has disappeared from our invoices (unsure to when). It does show webp image is supported under the status, so that doesn’t appear to be the cause.

The logs show a critical error and header image not found (Critical Header logo file not found.). However encoding a .png image URL into a template works.

On review, also adding manually a .webp image also works, so its the logo via the “Shop header/logo” under general settings which doesn’t seem to work with the simple premium template theme.

• This reply was modified 3 days, 12 hours ago by dev.

Looks like its been happening since July, so one of the following updates has most likely caused it:
v3.9.10 or v3.9.9

Pretty sure its down to only using orderIDs for validation, which if within the same stripe account and matching would cause a webhook to trigger another orders payment status.

I dont think this is limited to stripe checkout, as a few payment methods have the same potential issue.

class-stripe-checkout.php

/**
* creates order after checkout session is completed.
* @since 3.3.4
*/
public function eh_spg_stripe_checkout_order_callback() {

    if(!EH_Helper_Class::verify_nonce(EH_STRIPE_PLUGIN_NAME, 'eh_checkout_nonce'))
    {
        die(_e('Access Denied', 'payment-gateway-stripe-and-woocommerce-integration'));
    }
    $order_id = intval( $_GET['order_id'] );
    $order = wc_get_order($order_id);

    if(isset($_REQUEST['action']) && 'cancel_checkout' === sanitize_text_field($_REQUEST['action'])){
        wc_add_notice(__('You have cancelled Stripe Checkout Session. Please try to process your order again.', 'payment-gateway-stripe-and-woocommerce-integration'), 'notice');
        wp_redirect(wc_get_checkout_url());
        exit;
    }
    else{
        $session_id = sanitize_text_field( $_GET['sessionid'] );

        $obj  = new EH_Stripe_Payment();

        $order_time = date('Y-m-d H:i:s', time() + get_option('gmt_offset') * 3600);

        $session = \Stripe\Checkout\Session::retrieve($session_id);
        $payment_intent_id = $session->payment_intent;

         EH_Helper_Class::wt_stripe_order_db_operations($order_id,  $order, 'add', '_eh_stripe_payment_intent', $payment_intent_id, false);  

        $payment_intent = \Stripe\PaymentIntent::retrieve($payment_intent_id);
        $charge_details = $payment_intent->charges['data'];

        foreach($charge_details as $charge){

            $charge_response = $charge;  
        }

        $data = $obj->make_charge_params($charge_response, $order_id);

        if ($charge_response->paid == true) {

            if($charge_response->captured == true){
                $order->payment_complete($data['id']);
            }

            if (!$charge_response->captured) {
                $order->update_status('on-hold');
            }

            $order->set_transaction_id( $data['transaction_id'] );

            $order->add_order_note(__('Payment Status : ', 'payment-gateway-stripe-and-woocommerce-integration') . ucfirst($data['status']) . ' [ ' . $order_time . ' ] . ' . __('Source : ', 'payment-gateway-stripe-and-woocommerce-integration') . $data['source_type'] . '. ' . __('Charge Status :', 'payment-gateway-stripe-and-woocommerce-integration') . $data['captured'] . (is_null($data['transaction_id']) ? '' : '.'.__('Transaction ID : ','payment-gateway-stripe-and-woocommerce-integration') . $data['transaction_id']));
            WC()->cart->empty_cart();

            EH_Helper_Class::wt_stripe_order_db_operations($order_id, $order, 'add', '_eh_stripe_payment_charge', $data, false); 
            EH_Stripe_Log::log_update('live', $data, get_bloginfo('blogname') . ' - Charge - Order #' . $order_id);

            // Return thank you page redirect.
            $result =  array(
                'result'    => 'success',
                'redirect'  => $obj->get_return_url($order),
            );

            wp_safe_redirect($result['redirect']);
            exit;

        } else {
            wc_add_notice($data['status'], $notice_type = 'error');
            EH_Stripe_Log::log_update('dead', $charge_response, get_bloginfo('blogname') . ' - Charge - Order #' . $order_id);
        }
   }
}

A few concerns raised from initial checks:

1. Order ID Handling – The code relies on $_GET[‘order_id’] to retrieve the order ID and assumes it uniquely identifies an order. If two stores accidentally share the same order_id (e.g., both stores start order numbers at 1 or have overlapping ranges), a webhook sent to one store could inadvertently match an order in another store when sharing the same stripe account.
2. The session ID ($_GET[‘sessionid’]) is retrieved and used to fetch the Stripe Checkout session: php. Stripe webhooks should include additional validation, such as verifying the metadata or client_reference_id to ensure the webhook corresponds to the correct store and order
3. No Cross-Store Verification – The code does not validate whether the order_id or session ID belongs to the current store. It directly assumes the provided order_id is valid and related to the webhook payload. This could allow a Stripe webhook from another store (with a matching order_id) to mark an unrelated order as paid.
4. The code marks the order as paid when $charge_response->paid and $charge_response->captured are true. Without additional checks to validate that the order_id and payment intent belong to the current store, this could inadvertently mark an unrelated order as paid.
5. Stripe webhooks require the validation of their signature (Stripe-Signature header) to ensure the request came from Stripe and corresponds to the correct environment. The code snippet does not show any validation of this header, which might leave the endpoint vulnerable to spoofed requests.
   

Go to with GBTs review/recommendations:

Recommendations for Mitigation

1. Verify Order Ownership: Add additional checks to ensure the order ID and session ID belong to the current store. For example:
   • Compare the store’s URL or a unique identifier in the order metadata or webhook payload.
   • Use metadata fields in Stripe sessions to include the store ID or environment details.
2. Validate Stripe Webhook Signature: Use the \Stripe\Webhook::constructEvent() method to validate the Stripe-Signature header and ensure the payload belongs to the current store.
3. Check Payment Intent Metadata: Use metadata in the Stripe session or payment intent to uniquely link the payment to the specific store and order. This allows you to validate the incoming webhook against the store’s data.

One thing we’ve done as a temp measure is to have custom prefixes in for each stores order IDs, so they won’t clash anymore.

Bits to review in the meantime:

Order 1 (Failed) was in July 2024
Order 2 (Success) 15th Nov 2024

Order 1 had this added and the order went from failed to processing due to the matching order ID. The txn_ is for order 2.

Payment Status : Succeeded [ 2024-11-15 20:33:04 ] . Source : card. Charge Status :Captured. Transaction ID : txn_3QLWCLI<<redacted>>. via webhook

Payment Status : Succeeded [ 2024-11-15 20:33:04 ] . Source : mastercard( credit ). Charge Status :Captured.
Transaction ID : txn_3QLWCLI<<redacted>>

There’s only logs to the order 2 and not to the orginal failed payment in July.

Can you provide the best email to send these as they contain sensitive information?

The log error that we had was out in a previous post

[body] => {“error”:”invalid_grant”,”error_description”:”Refresh token does not exist: REDACTED”}?[response] => Array?(?[code] => 400?[message] => Bad Request?)?[cookies] => Array?(?)?[filename] =>?[http_response] => WP_HTTP_Requests_Response Object?(?[data] =>?[headers] =>?[status] =>?[response:protected] => WpOrg\Requests\Response Object?(?[body] => {"error":"invalid_grant","error_description":"Refresh token does not exist: REDACTED"}?[raw] => HTTP/1.1 400 Bad Request

Sure thing

Has this been fixed ?

The console errors were from astra theme files, latest updates fixed it. Theres a related convo about it on the spectra thread: https://www.ads-software.com/support/topic/customizer-problem-since-update-wp-6-7/

Updates over the weekend Astra 4.8.6 & spectra 2.16.5 have resolved the issue.

This could be an issue with the astra theme, @normaldenker do you use it ?

https://www.ads-software.com/support/theme/astra/

clearing al caches and tweaking PHP does not resolve issue. Was working before plugin updates and wordpress update.

Have rolled back plugin updates and still has issues, so looks like its a compatibility issue with latest wordpress or another issue.