I haven't been able to reproduce this issue on the latest Stripe changes, however merchants are still reporting that some of their orders are being incorrectly marked as on-hold with the following order notes:
In trying to understand how this could be possible, I found 2 areas of our code where we could unintentionally pass a Payment Intent object to our process_response() function. Because Payment Intent objects do not have a captured param, that will cause this condition to not pass, resulting in the order being marked as on-hold with an irrelevant order note, then though the payment has been successful (see code here)
Testing instructions
[!NOTE]
I've tried many things to reproduce this issue naturally but I could not, so please excuse the hackery in these testing instructions š
Make sure you have legacy checkout experience disabled and the "Issue an authorization on checkout, and capture later" setting also disabled.
Inside process_subscription_payment() tweak this code slightly and manually set $latest_charge to null, to force the intent response to be used instead:
// Use the last charge within the intent or the full response body in case of SEPA.
$latest_charge = null;
$this->process_response( ( ! empty( $latest_charge ) ) ? $latest_charge : $response, $renewal_order );
While on trunk, process a subscription renewal order
Note the subscription is on-hold and the latest renewal order is on-hold
View the renewal order and confirm the "Stripe charge authorized" order note is present.
Switch to this branch and purchase a new subscription or reactivate your existing subscription.
With $latest_charge set to null, the subscription will remain on-hold until the payment_intent.succeeded webhook comes in and processes the renewal payment via the webhook handler and sets the subscription back to active.
[ ] Covered with tests (or have a good reason not to test in description āļø)
[x] Added changelog entry in bothchangelog.txt and readme.txt (or does not apply)
Fixes #2404
Changes proposed in this Pull Request:
I haven't been able to reproduce this issue on the latest Stripe changes, however merchants are still reporting that some of their orders are being incorrectly marked as on-hold with the following order notes:
In trying to understand how this could be possible, I found 2 areas of our code where we could unintentionally pass a Payment Intent object to our
process_response()function. Because Payment Intent objects do not have acapturedparam, that will cause this condition to not pass, resulting in the order being marked as on-hold with an irrelevant order note, then though the payment has been successful (see code here)Testing instructions
process_subscription_payment()tweak this code slightly and manually set$latest_chargetonull, to force the intent response to be used instead:trunk, process a subscription renewal order$latest_chargeset tonull, the subscription will remain on-hold until thepayment_intent.succeededwebhook comes in and processes the renewal payment via the webhook handler and sets the subscription back to active.changelog.txtandreadme.txt(or does not apply)Post merge