fix(core): restore refund sync for terminal statuses when force_sync is set

[lorenzozanee]

Type of Change

• Bugfix
• New feature
• Enhancement
• Refactoring
• Dependency updates
• Documentation
• CI/CD

Description

GET /refunds/{id}?force_sync=true silently no-ops when the refund is already in a terminal status (Success/Failure): should_call_refund gates force_sync behind a non-terminal-status check, so the request returns the stale database row without consulting the connector.

This restores the pre-#11725 behavior and v2 parity: force_sync is again an unconditional override that consults the connector even for terminal refunds, and TransactionFailure is now treated as a terminal failure state like Failure. When the connector is called, sync_refund_with_gateway already materializes the returned status (including a connector-side reversal) and fires the outgoing webhook — only the predicate was blocking it.

Note: with this change, non-terminal refunds (Pending, ManualReview) are again synced with the connector when retrieved without force_sync, matching v2 and the behavior before #11725.

Additional Changes

• This PR modifies the API contract
• This PR modifies the database schema
• This PR modifies application configuration/environment variables

Motivation and Context

Fixes #13680

Since #11725 (released 2026.04.10.0), an explicit force_sync=true on a refund in Success/Failure returns the stale row — no connector call, no error, no indication the sync was skipped. If the connector later reverses a succeeded refund and the reversal webhook is lost, the refund stays stuck at success with no supported way to pull the connector's truth back in. v2 still has the unconditional force_sync disjunct, so the same API behaves oppositely between v1 and v2.

#11725's own description says terminal refunds should skip sync when "all_keys_required or force_sync" is set, but the merged code only gates force_sync — leaving the all_keys_required bypass and contradicting its stated intent. The terminal set also omits TransactionFailure, which the rest of the refund flow already treats as terminal.

Note: v1 no longer has the connector_refund_id guard that v2 still has (removed in #12755), so v1 may consult the connector for a refund without a connector refund id; that v1/v2 divergence is tracked separately and deliberately left out of this change.

How did you test it?

• Added a table-driven unit test for should_call_refund covering all five RefundStatus variants × force_sync × all_keys_required (20 cases), including the regression direction terminal + force_sync=true.
• The test fails on the base commit (terminal + force_sync=true returns false) and passes with the fix: cargo test -p router --lib --features v1 core::refunds::tests::should_call_refund_predicate_directions → ok, 1 passed.

Checklist

• I formatted the code cargo +nightly fmt --all
• I addressed lints thrown by cargo clippy
• I reviewed the submitted code
• I added unit tests for my changes where possible

[semanticdiff-com]

Review changes with  

Changed Files

File	Status
crates/router/src/core/refunds.rs	13% smaller