dev

Hello,

This is within the debug.log, cause isn’t known at this time its the only provided information.

Hello,

Version details are:
WordPress
PHP v 8.2.26
Mycred Version 2.9
Mycred Toolkit Version 1.1.0 
LMS Pro 3.1.0 

This is only with the “Passing a Quiz (Tutor LMS)” hook when a student fails a test.

Any update?

This is happening now, even with custom order pre-fix its marking orders back 5 months ago as paid for today due to the order numbers being the same on a different store.

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.

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 1 year, 6 months ago by dev.

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.