Uncaptured Payment Cancelled Bug for Dashboard Review Approval

[QuranIslam]

Hello

I think there is a very annoying bug with this plugin that will cause preauthorized payments get lost.

If you have manual capture set and payment goes to radar review. This payment will normally be set to On-Hold. Till now everything is fine but things starts to get funny when you approve the open review of the uncaptured payment from the stripe dashboard. Woocommerce will change order to pending payment. The opened review for this order is now closed. Reason: (approved) Order status changed from On hold to Pending payment.

After a few hours this payment will be marked as cancelled automatically by woocommerce and it will send API request to Stripe to cancel the uncaptured payment. Unpaid order cancelled – time limit reached. Order status changed from Pending payment to Cancelled.

I believe this should be changed. Payment under review that get approved from Stripe dashboard should not change the status of the order.

I stopped approving the review from the stripe dashboard because of this.

Thank you

[dougaitken]

WordPress.org Forum post about the same - https://wordpress.org/support/topic/payment-lost-bug-uncaptured-payment-review/#post-14483709

[QuranIslam]

Long story short the plugin has a strange behavior with uncaptured payments under review. I've lost money because of this bug and thought it is a good idea to point it out here so people can avoid losing money. I hope you can reproduce and fix this.

If someone approved an open review for uncaptured payment the plugin will mark the associated order to 'pending payment' This is wrong and the order should remain on-hold instead of pending.

Pending payment status will eventually be marked as cancelled and API sent to stripe will cause uncaptured money to get lost.

I hope your understand the scenario here. It took me hours to figure this out after discovering a cancelled payment that I didn't refund. After checking my logs this was the outcome.

[reykjalin]

I'm unable to reproduce the issue, but I think I know what's happening. Let me go through how I tested this before I get to what I think might be going wrong.

Testing

Webhook delivery must be correctly set up for this to work.

1. Configure Stripe to not immediately capture payments via WooCommerce > Settings > Payments > Stripe > Capture.
2. Use the testing card 4000 0000 0000 9235 to make a payment, retrieved from Stripe's Radar Testing instructions.
3. You'll see the order is set to on-hold.
4. Go into your Stripe dashboard, find the uncaptured payment and approve it.
5. You'll see the order has now been set to processing.

What's going wrong for merchants?

We have this code in place for handling the status changes:

Once a review is opened we store the current order status and set the status to on-hold:

https://github.com/woocommerce/woocommerce-gateway-stripe/blob/0978b203a16f69406652d7f1465cb9720e7fc3fb/includes/class-wc-stripe-webhook-handler.php#L635-L644

When the review is closed we retrieve the status we saved

https://github.com/woocommerce/woocommerce-gateway-stripe/blob/0978b203a16f69406652d7f1465cb9720e7fc3fb/includes/class-wc-stripe-webhook-handler.php#L673-L681

I think the issue here is that test charges are authorized (as in payment, not Radar rules) immediately, while real payments don't always work like that — sometimes it takes a bit before charges are authorized, but the Radar rules should pretty immediate. So here's what I think is happening:

1. Customer makes a payment.
2. Order status is set to pending-payment.
3. Radar rules put the payment under review.
4. Stripe extension saves the current order status as pending-payment.
5. Customer payment is authorized and is ready for capture.
6. The radar review is manually approved.
7. Stripe extension retrieves the previous order status (pending-payment) and applies that to the order.

Due to the nature of how this all works I don't think there's a way for us to reproduce this with testing cards, meaning we might have to fix this with some guesswork involved when it comes to how we handle the status updates.

Stopgap

Make it so that reviews don't affect the order status:

function disable_stripe_review_change_order_status( $should_change_order_status, $order, $notification ) {
    return false;
}
add_filter( 'wc_stripe_webhook_review_change_order_status`, 'disable_stripe_review_change_order_status', 10, 3 );

Proposed fix

I'm not sure to be honest. We may need some way to reliably update the _stripe_status_before_hold meta value on the order, but I'm not sure what the right place to do that is.

@politeshrimp were the orders that failed like this paid for with an asynchronous payment method like SEPA, or were they all card payments? The answer to that will help inform how we go about fixing the issue.

If it's related to asynchronous payment methods (e.g. SEPA) we can probably just update the _stripe_status_before_hold value in the process_webhook_charge_succeeded() and process_webhook_charge_failed() webhook handlers. If this is related to card payments we'll need something more elaborate. At that point it becomes increasingly likely that the webhooks are delivered out of order.

@dechov It's been a year since you last worked on this, but maybe you remember something that might help here?

[QuranIslam]

@reykjalin I don't use Stripe to accept SEPA. I only accept card payments so I can't tell you whether it occurs with SEPA or not. Sorry for the late reply.

[aheckler]

There is a similar issue occurring even without the manual capture setting enabled.

Specifically, if you use Stripe Radar to, say, hold for review all payments made with Mexican cards, and then do a test purchase with a Mexican card (4000004840008001), the payment is not captured when you go into the Stripe dash and approve the transaction there. I can see a note in the order indicating that the Stripe plugin "knows" that the transaction has been approved, but payment is not captured/taken.