Affected package: @medusajs/core-flows. Reproduced against Medusa develop at 0b97a96ea0d32ff3f4b18dbeeeeba9e763600a15, the base used for PR #17286.
Node.js version
Node 22
Database and its version
PostgreSQL 17
Operating system name and version
Linux
Browser name
Not applicable; reproduced through HTTP integration tests.
What happened?
Confirming an order edit cancels an existing authorized-but-not-captured payment collection and creates a new unpaid collection even when the amount due is unchanged and still exactly equals the authorized amount.
For example, an order has a $100 payment authorization. Replacing an item with another variant at the same price leaves the order total and amount due at $100, but confirming the edit discards the authorization. The merchant loses the ability to capture that existing payment, and the customer must authorize payment again for the same amount.
In packages/core/core-flows/src/order/workflows/create-or-update-order-payment-collection.ts, createOrUpdateOrderPaymentCollectionWorkflow recreates an AUTHORIZED collection without checking whether the pending amount still equals its authorized amount.
Steps to reproduce
Create a completable cart containing one product variant, with another variant available at the same price.
Create its payment collection and a payment session using pp_system_default, then complete the cart. Leave the resulting order's payment authorized and uncaptured.
Start an order edit.
Remove the original item and add one unit of the other variant. Keep shipping, discounts, taxes, and the resulting total unchanged.
Confirm the edit.
Retrieve the order and inspect its payment collections.
Expected behavior
When the pending amount still exactly equals the authorized amount, the original payment collection and authorization remain available. Capturing the existing payment succeeds and marks the order as captured.
Actual behavior
The original authorization is cancelled and replaced by a new unpaid collection despite no change to the amount due.
Link to reproduction repo
PR #17286 includes a regression test in integration-tests/http/__tests__/order-edits/order-edits.spec.ts that performs the same-price variant swap, checks that the original collection remains authorized, and captures its payment. The test fails on the unmodified base and passes with the PR's change.
Scope and related reports
This issue covers only an unchanged pending amount that exactly equals the existing authorization. It does not request preserving an authorization when the amount due increases or decreases, or changing partially authorized payments.
The broader order-edit report #14984 is closed and focuses on lowered totals. Issue #17287 separately tracks partial-capture amounts not reaching the payment provider. PR #17286 does not fix that provider-level bug; this unchanged-amount case needs no partial capture.
I have already submitted the narrowly scoped fix in #17286 and am opening this issue to give that change a matching open issue under the contribution guidelines.