Add purchaseInterruptedError for UPI/external payment app flows by facumenzella · Pull Request #6207 · RevenueCat/purchases-ios

facumenzella · 2026-02-05T11:48:56Z

Summary

When users complete purchases via third-party payment apps (e.g., UPI in India), switching to the external app causes AMSError.paymentSheetFailed to be returned. This error was previously mapped to PURCHASE_CANCELLED, even though the user may be completing (not cancelling) the payment.

Changes

Adds new error code purchaseInterruptedError (code 43, codeName PURCHASE_INTERRUPTED)
Tracks app background state during in-flight purchases via purchaseBackgroundedState
When AMSError.paymentSheetFailed is received AND app was backgrounded during purchase, returns purchaseInterruptedError instead of purchaseCancelledError
purchaseInterruptedError.isCancelledError returns false, so userCancelled will be false for interrupted purchases

Behavior

Scenario	Error Returned	`userCancelled`
User taps "Cancel" button	`purchaseCancelledError`	`true`
User switches to UPI app (app backgrounds)	`purchaseInterruptedError`	`false`

Developer Guidance

When receiving purchaseInterruptedError, developers should call getCustomerInfo() to verify actual entitlement status, as the payment may have succeeded in the external app.

Test plan

Builds successfully
ErrorCodeTests pass (including new testPurchaseInterruptedError)
Manual testing with UPI payment flow on device in India

Addresses #6194

claude · 2026-02-06T11:21:43Z

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

When users complete purchases via third-party payment apps (e.g., UPI in India), switching to the external app causes AMSError.paymentSheetFailed to be returned. This error was previously mapped to PURCHASE_CANCELLED, even though the user may be completing (not cancelling) the payment. This change: - Adds new error code `purchaseInterruptedError` (code 43) - Tracks app background state during in-flight purchases - When AMSError.paymentSheetFailed is received AND app was backgrounded, returns `purchaseInterruptedError` instead of `purchaseCancelledError` - `purchaseInterruptedError.isCancelledError` returns false, so `userCancelled` will be false for interrupted purchases Developers should handle this error by calling `getCustomerInfo()` to verify actual entitlement status. Fixes #6194 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

- Store notification observer and remove in deinit to prevent leaks - Clean up purchaseBackgroundedState in handlePurchasedTransaction (SK1) - Clean up purchaseBackgroundedState in handleDeferredTransaction - Add test for UPI/external payment app interrupted flow Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Add purchaseInterruptedError (code 43) to the public API baseline. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

The error message for storeProblemError differs between macOS and iOS. Update test to handle both platforms. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

…ction Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

tonidero · 2026-02-10T14:50:45Z

Sources/Purchasing/Purchases/PurchasesOrchestrator.swift

+            Logger.debug(Strings.purchase.purchase_interrupted_external_app(
+                productIdentifier: skError.userInfo["productId"] as? String ?? "unknown"
+            ))
+            return ErrorUtils.purchaseInterruptedError(error: error)


Hmm I think changing the return error code in this case is a kind of behavioral breaking change... For example, we will likely need to update our hybrids to handle this appropriately as well... Maybe we could do it if we do a major, but maybe it's worth exposing this information some other way for now...

Could we maybe add this information as part of the error's userInfo or something like that? for devs that want to handle this differently than a normal cancellation? Not sure how common this use case would be. If developer should handle this case differently than a cancellation, then maybe this is ok. If it's uncommon, let's avoid the behavior change if we can 🙏

Also, cc @ajpallares , not sure if this can have any effects on the RCT project we're working on?

I didn't think about this 🤔
I think I like it? Given that introducing a breaking change will most likely open other doors for issues.

Another thing is whether we might want to reuse the paymentPendingError error code for this scenario, instead of introducing a new one... but it would still be a bit of a behavioral breaking change...

In any case, it would be good to get some @RevenueCat/catforms feedback on this PR.

UPIs are very common in India, Most of the users make the payment by UPI only. There should be a way for us to distinguish user cancellation vs payment pending/in progress so that we can show the right state to the users.
Currently for this to work we have to keep the user waiting for 5 mins. We keep this payment timeout and keep on checking the payment status in background. Although this works, but the problem here is that even if the user is cancelling the payment or the purchase flow then also they will have to wait for 5 mins as we have no way to tell if user has actually cancelled it or the payment is in progress state.
Not just the UPI, even if you try to initiate the payment on IOS and you don't have the apple id logged in or payment method added then also it throws this error that user cancelled even though you are trying to login or adding the payment method.
I hope this gets resolved for good user experience and better tracking.

Given the fact that this is a breaking behavioral change, I think I agree with @tonidero and would be in favor of adding this to userInfo for now and potentially throwing a typed error for this in a future major SDK update.

rickvdl

Interesting edge case, thanks for digging into this!

Maybe this also affects RCT and / or is a potential case we should cover there, so it might make sense if @ajpallares could also have a look at it.

fire-at-will

I agree with @tonidero's idea of exposing this through the userInfo instead of a new error type for now to avoid making a breaking behavior change. That said, the detection logic seems reasonable to me :)

A few other questions that aren't specific to a single line of code:

Is there any documentation from Apple's side on how to use UPI apps with StoreKit? I'm not finding any, but I could just be missing it
It looks like this implementation only covers StoreKit 1 purchases. I can't tell from the referenced issue's sample code, but should we also be handling StoreKit 2 purchases as well?
Is it possible for us to easily test purchases made in the UPI flow to verify that this works as expected?

fire-at-will · 2026-02-13T18:29:59Z

Sources/Purchasing/Purchases/PurchasesOrchestrator.swift

        self.purchaseInitiatedPaywall.value = nil
    }

+// MARK: - Purchase Background State Tracking (for UPI/external payment app detection)


Suggested change

// MARK: - Purchase Background State Tracking (for UPI/external payment app detection)

// MARK: - Purchase Background State Tracking (for UPI/external payment app detection)

Nit: Mark should be indented

fire-at-will · 2026-02-13T18:33:38Z

Sources/Purchasing/Purchases/PurchasesOrchestrator.swift

+            Logger.debug(Strings.purchase.purchase_interrupted_external_app(
+                productIdentifier: skError.userInfo["productId"] as? String ?? "unknown"
+            ))
+            return ErrorUtils.purchaseInterruptedError(error: error)


Given the fact that this is a breaking behavioral change, I think I agree with @tonidero and would be in favor of adding this to userInfo for now and potentially throwing a typed error for this in a future major SDK update.

facumenzella added the pr:other label Feb 5, 2026

facumenzella marked this pull request as ready for review February 6, 2026 11:15

facumenzella requested a review from a team as a code owner February 6, 2026 11:15

facumenzella mentioned this pull request Feb 10, 2026

IOS: Payment cancelled while doing payment from UPI RevenueCat/react-native-purchases#1570

Open

5 tasks

facumenzella and others added 4 commits February 10, 2026 12:02

Update public API interface files

bcc2919

Add purchaseInterruptedError (code 43) to the public API baseline. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Fix LocalizedAlertErrorCodeTests for macOS platform

03569a2

The error message for storeProblemError differs between macOS and iOS. Update test to handle both platforms. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

facumenzella force-pushed the fix/purchase-interrupted-upi-payments branch from 7d51c3d to 03569a2 Compare February 10, 2026 11:04

facumenzella requested a review from a team as a code owner February 10, 2026 11:04

fix: correct vertical parameter alignment in handleSK1PurchasedTransa…

4b08058

…ction Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

tonidero reviewed Feb 10, 2026

View reviewed changes

rickvdl reviewed Feb 10, 2026

View reviewed changes

fire-at-will reviewed Feb 13, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add purchaseInterruptedError for UPI/external payment app flows#6207

Add purchaseInterruptedError for UPI/external payment app flows#6207
facumenzella wants to merge 5 commits intomainfrom
fix/purchase-interrupted-upi-payments

facumenzella commented Feb 5, 2026 •

edited

Loading

Uh oh!

claude bot commented Feb 6, 2026

Uh oh!

tonidero Feb 10, 2026

Uh oh!

tonidero Feb 10, 2026

Uh oh!

facumenzella Feb 11, 2026

Uh oh!

tonidero Feb 12, 2026

Uh oh!

helians11 Feb 13, 2026 •

edited

Loading

Uh oh!

fire-at-will Feb 13, 2026

Uh oh!

rickvdl left a comment

Uh oh!

fire-at-will left a comment

Uh oh!

fire-at-will Feb 13, 2026

Uh oh!

fire-at-will Feb 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

	// MARK: - Purchase Background State Tracking (for UPI/external payment app detection)
	// MARK: - Purchase Background State Tracking (for UPI/external payment app detection)

Conversation

facumenzella commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Behavior

Developer Guidance

Test plan

Uh oh!

claude bot commented Feb 6, 2026

Code review

Uh oh!

tonidero Feb 10, 2026

Choose a reason for hiding this comment

Uh oh!

tonidero Feb 10, 2026

Choose a reason for hiding this comment

Uh oh!

facumenzella Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

tonidero Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

helians11 Feb 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fire-at-will Feb 13, 2026

Choose a reason for hiding this comment

Uh oh!

rickvdl left a comment

Choose a reason for hiding this comment

Uh oh!

fire-at-will left a comment

Choose a reason for hiding this comment

Uh oh!

fire-at-will Feb 13, 2026

Choose a reason for hiding this comment

Uh oh!

fire-at-will Feb 13, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

facumenzella commented Feb 5, 2026 •

edited

Loading

helians11 Feb 13, 2026 •

edited

Loading