Stripe merge requestshttps://lab.civicrm.org/extensions/stripe/-/merge_requests2024-03-14T15:39:20Zhttps://lab.civicrm.org/extensions/stripe/-/merge_requests/249Process the invoice.paid and invoice.payment_succeeded webhook events with de...2024-03-14T15:39:20ZdmunioProcess the invoice.paid and invoice.payment_succeeded webhook events with delay. #442https://lab.civicrm.org/extensions/stripe/-/merge_requests/247#469 - Added condition to check if the event fire for charge.succeeded...2024-02-20T13:17:18Zdamo-civi#469 - Added condition to check if the event fire for charge.succeeded...Issue #469 - Added condition to check if the event fire for charge.succeeded or charge.captured in the doChargeSucceeded() function.Issue #469 - Added condition to check if the event fire for charge.succeeded or charge.captured in the doChargeSucceeded() function.https://lab.civicrm.org/extensions/stripe/-/merge_requests/239when civi.stripe.authorize fails, log the reason2024-03-05T21:40:07Znoahwhen civi.stripe.authorize fails, log the reasonInclude more useful information in an exception message.Include more useful information in an exception message.https://lab.civicrm.org/extensions/stripe/-/merge_requests/235Add in better handling for delayed webhook events where we cannot retrieve ch...2023-12-11T23:22:31ZseamusleeAdd in better handling for delayed webhook events where we cannot retrieve charge anymoreOn a clients site we had a situation where there were a number of webhooks that were quite delayed (on the test payment processor webhook thankfully) but were having 500 errors returned because when they were re-tried by Stripe the charg...On a clients site we had a situation where there were a number of webhooks that were quite delayed (on the test payment processor webhook thankfully) but were having 500 errors returned because when they were re-tried by Stripe the charges had been rotated out of stripe's system already and such the setInputParameters was triggering an exception.
This aims to better handle it like in the process delayed webhooks process. This at least stops the 500 http error from being returnedhttps://lab.civicrm.org/extensions/stripe/-/merge_requests/221Display a message indicating 0 amount display on the 3DS verification popup i...2023-08-15T11:25:05ZjitendraDisplay a message indicating 0 amount display on the 3DS verification popup is normalWorkaround for https://lab.civicrm.org/extensions/stripe/-/issues/411 by displaying an alert before the SCA popup displays $0 for the recurring payment.
![image](/uploads/6d28b8f26659dcd1004456ab78e86012/image.png)Workaround for https://lab.civicrm.org/extensions/stripe/-/issues/411 by displaying an alert before the SCA popup displays $0 for the recurring payment.
![image](/uploads/6d28b8f26659dcd1004456ab78e86012/image.png)https://lab.civicrm.org/extensions/stripe/-/merge_requests/216Proposed fix for #428: webform submit button is non-responsive for zero-dolla...2023-12-04T19:03:47ZAllenShawProposed fix for #428: webform submit button is non-responsive for zero-dollar contribution amount.This PR does solve the problem in #428, but frankly I would be surprised if this is a complete fix as it's admittedly naive.
I found that by commenting out the [`event.preventDefault()` call at the top of `script.submit()`](https://lab....This PR does solve the problem in #428, but frankly I would be surprised if this is a complete fix as it's admittedly naive.
I found that by commenting out the [`event.preventDefault()` call at the top of `script.submit()`](https://lab.civicrm.org/extensions/stripe/-/blob/6.8.2/js/civicrmStripe.js#L497), the problem in #428 goes away. Apparently that's what is interrupting the submit when `script.submit()` returns at [line 605](https://lab.civicrm.org/extensions/stripe/-/blob/6.8.2/js/civicrmStripe.js#L605).
Of course, that change would seem a little blunt. Surely there are some cases where it is still appropriate to preventDefault().
Instead, this PR adds `preventDefault()` in `script.submit()` only where that function returns `false`. My assumption here is that there once was (or somewhere still is) a meaningful distinction between `return;`, `return false;` and `return true;`, and that _maybe_ that disctinction relates to whether or not to allow the event to continue processing.https://lab.civicrm.org/extensions/stripe/-/merge_requests/193recognize first payment of future recurring2023-06-30T18:30:36Zkonadaverecognize first payment of future recurringFix for #384Fix for #3846.9