* fix: preserve payment sessions during certain Stripe errors for webhook reconciliation
fix: add retry mechanism for errors that might be fixed after retry
fix: authorizePaymentSession method will update payment_session.status regardless regardless of wether or not the authorization is successful
* Refactor: improve handling structure and syntax
-Move HandledErrorType definition to the top of stripe-base
- Use timers/promises for setTimeout
- Removed data in HandledErrorType when retry is true
* refactor: improve error handling flow and logic
- Simplify return statement in initiatePayment to handle null cases
- Remove redundant if-check in handleStripeError and rely on switch
- Reorder conditional checks in executeWithRetry for clearer flow
- Update executeWithRetry to check for retry=false condition first
* clean up
* fix: improve payment error handling and traceability
- Return structured error state for StripeAPIError instead of null
- Throw error when retries are exhausted and no payment intent exists
- Update type definitions to support error state tracking
* fix formatting and naming
This PR adds a couple new statuses to the payment collection and payment webhook results. The payment collection will now be marked as "completed" once the captured amount is the full amount of the payment collection.
There are several things left to improve the payment setup, so non-happy-path cases are handled correctly.
1. Currently the payment session and payment models serve a very similar purpose. Part of the information is found on one, and the other part on the other model, without any clear reason for doing so. We can simplify the payment module and the data models simply by merging the two.
2. We need to handle failures more gracefully, such as setting the payment session status to failed when such a webhook comes in.
3. We should convert the payment collection status and the different amounts to calculated fields from the payment session, captures, and refunds, as they can easily be a source of inconsistencies.
RESOLVES SUP-188
**What**
Two changes are happening here
- In the stripe payment provider, idempotent cancellation action, if not id is provided then return the existing data unchanged
- Payment module should not try to cancel a session that have failed to be created in the first place
