fix(napm): report failed web redirect to backend when confirmation is required

[dbashtani]

Fixes #535

Problem

When a web-type redirect fails during a native alternative payment (customer closes ASWebAuthenticationSession, or the session fails to start), uncheckedRedirect(to:) throws before continuePayment is called. The merchant app receives processout-mobile.cancelled, but the backend is never informed — the invoice stays pending in the dashboard, disagreeing with the SDK-reported outcome.

This is inconsistent with the deep_link branch, which reports .init(success: didOpenUrl) when redirect.confirmationRequired is set.

Change

On web redirect failure, when redirect.confirmationRequired is true, report redirect: .init(success: false) via continuePayment — mirroring the deep link semantics — then rethrow the original error.

• Gated on confirmationRequired, the backend's existing opt-in flag, so no confirmations are sent that the backend didn't ask for.
• Best-effort (try?): a network failure during the report cannot mask the original failure.
• Merchant-facing behavior is unchanged — the same POFailure propagates, same events are emitted.

Open questions for review

1. Backend semantics of success: false for web redirects (fail attempt vs. allow retry) — please confirm the desired invoice transition.
2. In the user-cancel path the surrounding task is cancelled, so the report request may be cancelled with it. If the report should be guaranteed there too, it would need an unstructured task shielded from cancellation — happy to adjust if that's preferred.
3. The Android SDK has the same gap (handleWebRedirect(failure:) completes locally without sending a redirect confirmation); if this change is accepted, a matching fix there would keep platforms consistent.

[andrii-vysotskyi-cko]

Hi @dbashtani, thank you for the suggestion!

Currently the only use case for confirmation is to allow fallback from deep link to web redirect. So while the use case you described is possible in theory, it's not in possible in practise (also because confirmation is not required for web redirects).

[dbashtani]

Hi @dbashtani, thank you for the suggestion!

Currently the only use case for confirmation is to allow fallback from deep link to web redirect. So while the use case you described is possible in theory, it's not in possible in practise.

@andrii-vysotskyi-cko Thanks for the explanation, that makes sense — I didn't realize the confirmation is only there for the deep link → web fallback. So yeah, this change would never actually fire.
The original problem still bugs me though: user abandons the web redirect, SDK says cancelled, but the invoice just sits pending in the dashboard. Is the expectation that it simply expires and we shouldn't read anything into dashboard state? Or is there interest in letting the client report an abandoned redirect somehow? We see this at some scale at Glovo, so happy to rework the PR if there's a direction you'd accept — otherwise I'll close it and we track it on our side.

[andrii-vysotskyi-cko]

Is the expectation that it simply expires

Correct

Or is there interest in letting the client report an abandoned redirect somehow?

For now probably not. SDK change alone won't suffice since backend won't change payment's state even if it receives false for a web redirect confirmation.

BTW the topic itself is broader than redirects, for example customer dismissing payment screen (or clicking cancel button) won't cause payment to transition to failed state either.