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.
FIXES SUP-560
**What**
Currently, no matter the error when looking for a provider to exists in the container we are throwing a normalized error stating that the provider does not exists in the container. The issue is that the first initialization of the provider occurs the first time we resolve it, and the error can be that the provider failed to be instanciated for any reason.
In this pr, we are explicitly checking for the error to be an awilix resolution error to throw the classic error and otherwise we provide the issue why the provider failed to be resolved.
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
What
- Store result of cart-completion workflow for three days by default
- This enables the built-in idempotency mechanism to kick-in, provided the same transaction ID is used on workflow executions
- Return order from cart-completion workflow if the cart has already been completed
- In case transaction ID is not used on workflow executions, we still only want to complete a cart once
* feat(core-flows,payment,medusa,types): add ability to set and manage refund reasons
* fix(payment): validate total amount when refunding payment (#8437)
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
* feature: introduce additional_data to the product endpoints (#8405)
* chore(docs): Generated References (#8440)
Generated the following references:
- `product`
* chore: align payment database schema
* Update packages/core/core-flows/src/payment-collection/steps/create-refund-reasons.ts
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
* chore: address review
---------
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
Co-authored-by: Harminder Virk <virk.officials@gmail.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
**What**
Update the `MedusaService` class, factory and types to remove the concept of main modules. The idea being that all method will be explicitly named and suffixes to represent the object you are trying to manipulate.
This pr also includes various fixes in different modules
Co-authored-by: Stevche Radevski <4820812+sradevski@users.noreply.github.com>
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
**What**
- remove medusa-core-utils
- dispatch the utils where they belongs
- update usage
**NOTE**
I have been wondering if the graceful class should go into the utils package or medusa package, I ve put it in the medusa package as it seems to be the best place I can see for now and is tight to the server as well. Also, I wanted to avoid the utils package to depends on http and net dependencies, happy to change that if you feel like it
