SEPA payment failed

Hi,

Thanks for your reply.

We have checked the webhook setup, but we also reviewed the plugin source code because we wanted to understand the exact behaviour when a SEPA payment fails several days after the order has already been processed.

From what we can see in the code, when the order has already reached the completed status, the plugin appears to consider it as finalized and does not move it back to failed when a later charge.failed webhook is received.

So the webhook itself may be received correctly, but the order status would still remain completed.

Could you please confirm whether this is the expected behaviour?

Hi,

Thanks for the clarification.

I understand the logic regarding failed SEPA payments. However, our concern is specifically about SEPA disputes occurring after the payment has already been successfully completed.

With SEPA Direct Debit, a payment can legitimately be marked as successful, the WooCommerce order can therefore be processed and completed, and the goods can already have been shipped.

But the customer still has an 8-week period after the debit to dispute the payment through their bank, on a no-questions-asked basis. Stripe also confirms that disputes within this period are automatically honoured.

This is not only a theoretical case for us: we have already had orders where the SEPA payment was successfully processed, the order was shipped, and the customer later disputed the debit and was reimbursed by their bank.

So in that situation, keeping the WooCommerce order as completed after receiving the later dispute makes it difficult operationally for us to identify that the payment has effectively been reversed.

Thanks

Hi,

Thanks, that distinction is helpful.

I checked one of our actual SEPA cases in Stripe Workbench, and it appears to be slightly different from the charge.dispute.created flow you described.

In this case:

• the SEPA payment was initiated and remained processing for several days;
• Stripe later displayed the message that the customer had requested a refund from their bank;
• the actual events generated by Stripe were charge.failed and payment_intent.payment_failed;
• there was no charge.dispute.created event;
• the WooCommerce order had already been marked as completed, and it remained completed after the charge.failed event.

So this seems to be the exact case we were initially referring to: a late SEPA bank return/refund request that Stripe reports through charge.failed, while the WooCommerce order has already reached completed.

As you confirmed previously, your plugin intentionally does not move an already completed order back to failed.

Regards

Hi,

Thanks, that explains the misunderstanding.

In our case, the order being completed is expected and comes from our own internal workflow.

For operational reasons, we do not wait for the final SEPA confirmation before processing the order. The order is initially placed on-hold, then after our internal validation we manually move it to processing, and later to completed once it has been fulfilled.

So I agree that your Stripe plugin is not responsible for moving this particular order to completed.

The issue we are trying to address is what happens afterwards:

• the SEPA order has already been processed and completed by our internal workflow;
• several days later Stripe sends a charge.failed event;
• because the WooCommerce order is already completed, the Stripe plugin intentionally leaves its status unchanged;
• operationally, we then have a completed order for which the SEPA payment has actually failed.

We have therefore developed a small custom MU-plugin for our specific workflow. It listens for late SEPA charge.failed events and, when the related order is already processing or completed, moves it to failed and alerts our customer service team.

We understand this is specific to our business process rather than an issue with the default behaviour of your plugin.

Is wc_stripe_webhook_charge_failed the appropriate hook for implementing this custom handling, or would you recommend another hook/API exposed by Payment Plugins for this use case?