Stripe Express: Successful order email when the client doesn't authenticate and confirm native Apple Pay payment.

[dan504301]

Bug Description

This was tested only in guest mode checkout, but I believe it will manifest similarly for logged-in checkouts.

I suspect this issue also occurs with Google Pay, although it has not been tested.

1.The client fills in all the order details and chooses Apple Pay inside the Payment element.

2.The client clicks "Yes" to use Apple Pay.

3.When the native Apple payment authentication with Touch ID appears, the client cancels the payment (tested on MacBook Pro).

4.The order confirmation email is sent to all participants.

5.The actual order remains in the On Hold state inside WooCommerce.

If the client retries the payment and successfully completes it, another order number is created.

This was a significant effort on my part @mralaminahamed .

[dan504301]

@mralaminahamed, Dokan has been updated twice since I opened this ticket, yet the issue persists.

Both Apple Pay and Google Pay remain unusable at this stage.

[dan504301]

@mralaminahamed, it seems I was able to fix the issue.

Some feedback will be great...

stripe-express/includes/Processors/Payment.php

Lines 815 to 823...

$order->update_status(
                'on-hold',
                sprintf(
                    /* translators: 1) gateway title, 2) charge id */
                    __( '[%1$s] Charge authorized (Charge ID: %2$s). Process order to take payment, or cancel to remove the pre-authorization. Attempting to refund the order in part or in full will release the authorization and cancel the payment.', 'dokan' ),
                    Helper::get_gateway_title(),
                    $response->id
                )
            );

Becomes

$order->update_status(
                'pending',
                sprintf(
                    /* translators: 1) gateway title, 2) charge id */
                    __( '[%1$s] Charge authorized (Charge ID: %2$s). Process order to take payment, or cancel to remove the pre-authorization. Attempting to refund the order in part or in full will release the authorization and cancel the payment.', 'dokan' ),
                    Helper::get_gateway_title(),
                    $response->id
                )
            );

I simply changed on line 816 from on-hold to pending

Now the order remains in the pending state when the client cancels the payment, the initial order number is kept.

The order switches to processing once the client autentificate Google Pay or Apple Pay.

I don't know if this change affects other functions of the Stripe Express module.

[dan504301]

It has been almost two months since I started using this modification on my live instalation: there are no issues so far.

I've also repeately tested it with both Apple Pay and Google Pay.

The error remains if the client cancels Apple Pay/Google Pay (resource_missing - id), but it does not seem to affect functionality.

This change should be included in the next Dokan Pro update.

[mralaminahamed]

@dan504301, I hope you are well.

WooCommerce handles orders according to their guidelines (ref: Order Statuses), and specifically, the WooCommerce Stripe Gateway sets orders to 'on-hold' when payment capture fails (ref: WooCommerce Stripe Gateway).

However, payment failures can occur for various reasons:

• Customer cancels payment
• System failed to read the webhook response.
• Customer was charged but our system was not updated.
• And other scenarios

Your 'pending' status is valid for this case, but from a global point of view, there can be other cases. In order to mitigate all the other unknown cases which has to be resolve manually, we want to keep the system according to the woocommerce guideline which will keep us aligned according to the policy. If any further enhancement suggestion is there from you, you are always welcome to place it on our community issue list.

[dan504301]

@mralaminahamed, thank you for your response.

It’s good to know this.

I will keep this change on my installation because, for our workflow, it makes zero sense to have a successful order confirmation email for on hold card payments.

The "On Hold" order status makes sense for bank transfers because the vendor has to manually confirm the payment, but it makes zero sense for card payments.

Most vendors deliver their orders based on the successful confirmation emails for card payments and dont bother to look first in the vendor dashboard.