Improve accuracy of transactions origin Part 3: Merge cached data when posting receipts + Cache amazon data #2989

tonidero · 2025-12-31T15:10:26Z

Description

These are the main changes in this PR:

Now, when posting a receipt, if we find that there is any cached information we will include this information in that POST /receipt. This doesn't handle edge cases that may happen when the purchase is not found from the store anymore (will handle in follow-up PRs)
Include amazon store user id + marketplace in ReceiptInfo, so it can be cached and posted later in POST /receipt when needed.
Include original observer_mode in post receipt request body. The cached value will have priority over the current one.

…ity-of-2' into sdk-4188-puchases-android-improve-accuracy-and-reliability-of-3

codecov · 2026-01-05T09:34:51Z

Codecov Report

❌ Patch coverage is 81.13208% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 78.97%. Comparing base (204d052) to head (90ac987).

Files with missing lines	Patch %	Lines
...lin/com/revenuecat/purchases/common/ReceiptInfo.kt	68.18%	0 Missing and 7 partials ⚠️
...tlin/com/revenuecat/purchases/PostReceiptHelper.kt	84.21%	0 Missing and 3 partials ⚠️

Additional details and impacted files

@@                                         Coverage Diff                                         @@
##           sdk-4188-puchases-android-improve-accuracy-and-reliability-of-2    #2989      +/-   ##
===================================================================================================
- Coverage                                                            78.98%   78.97%   -0.02%     
===================================================================================================
  Files                                                                  341      341              
  Lines                                                                13449    13476      +27     
  Branches                                                              1804     1820      +16     
===================================================================================================
+ Hits                                                                 10623    10642      +19     
+ Misses                                                                2079     2078       -1     
- Partials                                                               747      756       +9

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

…ity-of-2' of github.com:RevenueCat/purchases-android into sdk-4188-puchases-android-improve-accuracy-and-reliability-of-3

…erver_mode

JayShortway

Awesomeee! Some minor comments and some philosophical ones 😄

JayShortway · 2026-01-05T13:50:09Z

purchases/src/main/kotlin/com/revenuecat/purchases/common/Backend.kt

                return@let mapOf("revision" to it.revision, "rule_id" to it.ruleId)
            },
-            "observer_mode" to !finishTransactions,
+            "observer_mode" to (originalObserverMode ?: !finishTransactions),


Should we even fall back to the current value? That makes the field ambiguous, as it can now mean either "observer mode at time of transaction" or "observer mode at time of posting". Do we even care about the latter? If yes, maybe we should make separate fields?

Right, I went back and forth on this (see commit 😅 ).

My thoughts in the end were, we should always use the cached value if we have any cached data. If we don't, we should use the current value, since we can assume the purchase was just performed and/or comes from the queue.

My main reason for not separating it is that we're already sending this information on a header for all requests, so maybe we don't really need to send it at all unless we have a cached value. However, not sending it would mean possible changes in the backend, so I decided to leave the current behavior if the purchase is not cached.

But yeah, this is indeed confusing, so might be worth sending this in a new field to avoid confusion.

Yea I think we should avoid confusion, for us and for the backend. It could even lead to some subtly incorrect attributions. Maybe we leave the header as-is and introduce a new field in the body. (I'd also be okay removing the header if the backend isn't reading it).

I split this into a separate field: 3878eef

@antoniobg we will need to accept this new field in the backend. It's meaning will be the value of this field at the time when the purchase was made (which could have potentially changed if the value changed before the data was successfully posted)

If it's a new parameter, can we change the name that matches better the configuration, like purchase_completion_method or completion_method ?

Indeed... what do you think of purchase_completed_by, with possible values being my_app and revenuecat? Note that the public API for this is going to be PurchasesAreCompletedBy.MY_APP or PurchasesAreCompletedBy.REVENUECAT. cc @RevenueCat/coresdk @antoniobg

Sounds good to me

Ok renamed in 95af91f

purchases/src/main/kotlin/com/revenuecat/purchases/common/ReceiptInfo.kt

JayShortway · 2026-01-05T13:56:55Z

purchases/src/main/kotlin/com/revenuecat/purchases/PostReceiptHelper.kt

        val presentedPaywall = paywallPresentedCache.getAndRemovePresentedEvent()
+        val effectivePaywallData = presentedPaywall?.toPaywallPostReceiptData()
+            ?: cachedTransactionMetadata?.paywallPostReceiptData


Could this be a potential source of bugs if we're posting cached receipts while a paywall is showing? It might accidentally attribute the cached receipt to the currently showing paywall, if I understand correctly, right?

Hmm you're indeed right that this may potentially happen... and could also be happening right now I think, since the event storage mechanism is completely unattached to the posting of the receipt here, we don't know if it's related... We should think on how to fix this issue more permanently... Great catch!!

For this PR, I'm thinking we could potentially check, if there is a cached value for the given token we don't even need to call getAndRemovePresentedEvent above, to avoid missattributions later, but as mentioned, this wouldn't fix the existing issue I think.

if there is a cached value for the given token we don't even need to call getAndRemovePresentedEvent above

True, but we should make sure the paywallPresentedCache doesn't contain stale data in any case.

An additional thing we could do is check if the presented paywall's Offering corresponds to the PresentedOfferingContext we have? Not airtight by any means, but it does allow us to eliminate obvious missattributions.

we should make sure the paywallPresentedCache doesn't contain stale data in any case.

Right, I was checking and we basically should be clearing the cached paywallPresentedCache when:

Performing a successful POST /receipt.

When closing the paywall (or at least asked to be dismissed). This includes:

When navigating back with the back button

When clicking on close buttons with the navigate back action

When navigation to a web checkout url.

I believe this shouldn't leave cached paywall information around.

An additional thing we could do is check if the presented paywall's Offering corresponds to the PresentedOfferingContext we have? Not airtight by any means, but it does allow us to eliminate obvious missattributions.

I do think this is a valid check, but will likely do that in a separate PR, since it seems like a different thing than what we're trying to do in this PR

Changed the order of operations in a7f7d22.

Will take note and do try to figure a more robust solution for the cached paywall events in a follow-up PR

purchases/src/main/kotlin/com/revenuecat/purchases/PostReceiptHelper.kt

purchases/src/main/kotlin/com/revenuecat/purchases/common/ReceiptInfo.kt

…nd-reliability-of

…ity-of' into sdk-4188-puchases-android-improve-accuracy-and-reliability-of-2

…ity-of-2' of github.com:RevenueCat/purchases-android into sdk-4188-puchases-android-improve-accuracy-and-reliability-of-3

rickvdl

Awesome work!

rickvdl · 2026-01-08T09:44:08Z

purchases/src/main/kotlin/com/revenuecat/purchases/PostReceiptHelper.kt


-        val presentedPaywall = paywallPresentedCache.getAndRemovePresentedEvent()
+        val presentedPaywall = if (cachedTransactionMetadata == null) {
+            paywallPresentedCache.getAndRemovePresentedEvent()


Should we also remove the in-memory cached value if we don't use it (if we don't call getAndRemovePresentedEvent()) to prevent it from being used in the next (non-paywall?) purchase?

We shouldn't, since it's possible the paywall is still displayed while we're syncing purchases in the background. We should only clear it in the same situations we were clearing it before (upon a successful purchase and/or when closing the paywall)

rickvdl · 2026-01-08T09:58:51Z

purchases/src/main/kotlin/com/revenuecat/purchases/PostReceiptHelper.kt

+        } else {
+            null
+        }
+        val effectivePaywallData = cachedTransactionMetadata?.paywallPostReceiptData


Did we decide on keying the in-memory cached presentedPaywall by product id / transaction ID or similar? In order to avoid mixing this data with an unrelated transaction? Not sure if it's a realistic scenario or only theoretical one, but what if a purchase comes in from the queue while this in-memory value is set?

Note that the cachedTransactionMetadata's paywall is indeed keyed by the purchase token hash. As for the in memory event (that came from before these PRs), it's indeed a problem I'm thinking about how to solve... It normally shouldn't be an issue since we clear the in memory cache when closing the paywall, but there are edge cases that are not correctly handled, like when making a purchase when PurchasesAreCompletedBy.MY_APP or if for any reason presenting multiple paywalls at once.

purchases/src/main/kotlin/com/revenuecat/purchases/PostReceiptHelper.kt

purchases/src/main/kotlin/com/revenuecat/purchases/common/caching/LocalTransactionMetadata.kt

JayShortway

Good stuff!

JayShortway · 2026-01-08T14:15:45Z

purchases/src/main/kotlin/com/revenuecat/purchases/common/Backend.kt

                return@let mapOf("revision" to it.revision, "rule_id" to it.ruleId)
            },
            "observer_mode" to !finishTransactions,
+            "purchase_completed_by" to purchasesAreCompletedBy.name.lowercase(),


JayShortway · 2026-01-08T14:16:12Z

purchases/src/main/kotlin/com/revenuecat/purchases/common/ReceiptInfo.kt

+     * Merges this [ReceiptInfo] with another [ReceiptInfo], giving precedence to the values in this
+     * instance when there are conflicts.
+     */
+    fun mergeWith(receiptInfo: ReceiptInfo): ReceiptInfo {


…ity-of-2' of github.com:RevenueCat/purchases-android into sdk-4188-puchases-android-improve-accuracy-and-reliability-of-3

Copilot

Pull request overview

This PR improves transaction origin accuracy by implementing cached data merging when posting receipts and adding Amazon-specific fields to ReceiptInfo. The changes enable better handling of transaction metadata that may have been cached during the purchase flow.

Key Changes

Added storeUserID and marketplace fields to ReceiptInfo to support Amazon store data
Implemented mergeWith() method in ReceiptInfo to intelligently combine current and cached receipt information
Replaced observerMode with purchasesAreCompletedBy enum in LocalTransactionMetadata for more explicit transaction completion tracking
Modified PostReceiptHelper to merge cached transaction metadata (including receipt info, paywall data, and purchasesAreCompletedBy) when posting receipts

Reviewed changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
`ReceiptInfo.kt`	Added Amazon fields (storeUserID, marketplace) and implemented mergeWith logic for combining current and cached data
`Backend.kt`	Refactored postReceiptData to use ReceiptInfo fields directly and added purchasesAreCompletedBy parameter
`PostReceiptHelper.kt`	Enhanced to retrieve and merge cached transaction metadata when posting receipts
`LocalTransactionMetadata.kt`	Replaced observerMode boolean with purchasesAreCompletedBy enum for clearer semantics
`AppConfig.kt`	Made purchasesAreCompletedBy publicly accessible
`SyncPurchasesHelper.kt`	Updated to include storeUserID and marketplace in ReceiptInfo
`PurchasesOrchestrator.kt`	Updated to include storeUserID and marketplace in ReceiptInfo for Amazon purchases
Test files	Comprehensive test updates and additions covering new merge functionality and cached data scenarios

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-01-08T15:56:26Z

purchases/src/main/kotlin/com/revenuecat/purchases/common/Backend.kt

            "applied_targeting_rule" to receiptInfo.presentedOfferingContext?.targetingContext?.let {
                return@let mapOf("revision" to it.revision, "rule_id" to it.ruleId)
            },
            "observer_mode" to !finishTransactions,


Both observer_mode and purchase_completed_by are being sent in the request body. This appears to be redundant since they represent similar information. Consider whether both fields are needed or if observer_mode should be removed in favor of purchase_completed_by.

Suggested change

"observer_mode" to !finishTransactions,

Copilot · 2026-01-08T15:56:27Z

purchases/src/main/kotlin/com/revenuecat/purchases/common/Backend.kt

            isRestore.toString(),
            finishTransactions.toString(),
            subscriberAttributes.toString(),
            receiptInfo.toString(),


The cache key for deduplicating postReceiptData calls doesn't include purchasesAreCompletedBy. This could lead to incorrect request deduplication when the same receipt is posted with different purchasesAreCompletedBy values. Consider adding purchasesAreCompletedBy.toString() to the cacheKey list.

Suggested change

receiptInfo.toString(),

receiptInfo.toString(),

purchasesAreCompletedBy.toString(),

Copilot · 2026-01-08T15:56:27Z

purchases/src/main/kotlin/com/revenuecat/purchases/common/caching/LocalTransactionMetadata.kt

+        @SerialName("purchases_are_completed_by")
+        val purchasesAreCompletedBy: PurchasesAreCompletedBy,


The serialization field name is changed from observer_mode to purchases_are_completed_by, but the field type has also changed from nullable Boolean to non-nullable PurchasesAreCompletedBy enum. This is a breaking change for persisted data. Any previously cached transactions with observer_mode will fail to deserialize. Consider adding a migration strategy or using a custom deserializer to handle backward compatibility.

ajpallares · 2026-01-09T15:23:31Z

purchases/src/main/kotlin/com/revenuecat/purchases/PostReceiptHelper.kt

+        }
+        val effectivePaywallData = cachedTransactionMetadata?.paywallPostReceiptData
+            ?: presentedPaywall?.toPaywallPostReceiptData()
+        val effectiveReceiptInfo = cachedTransactionMetadata?.receiptInfo?.let { receiptInfo.mergeWith(it) }


I wonder, if the result of the mergeWith actually results in changes, shouldn't we update the cached metadata with the merged information? Otherwise, a failure in the POST /receipt could result in data loss?

Merge cached data when posting receipts + Include amazon data

9769b93

tonidero added the pr:other label Dec 31, 2025

Merge branch 'sdk-4188-puchases-android-improve-accuracy-and-reliabil…

8d7a45c

…ity-of-2' into sdk-4188-puchases-android-improve-accuracy-and-reliability-of-3

tonidero added 3 commits January 5, 2026 11:07

Merge branch 'sdk-4188-puchases-android-improve-accuracy-and-reliabil…

812b7cb

…ity-of-2' of github.com:RevenueCat/purchases-android into sdk-4188-puchases-android-improve-accuracy-and-reliability-of-3

Change to use existing observer_mode property instead of original_obs…

c3bf6df

…erver_mode

Fix missing merge data

856a210

tonidero mentioned this pull request Jan 5, 2026

Improve accuracy of transactions origin Part 4: Post remaining transaction metadata when syncing purchases #2993

Open

tonidero marked this pull request as ready for review January 5, 2026 11:55

tonidero requested a review from a team as a code owner January 5, 2026 11:55

JayShortway reviewed Jan 5, 2026

View reviewed changes

tonidero and others added 5 commits January 7, 2026 17:15

Merge branch 'main' into sdk-4188-puchases-android-improve-accuracy-a…

002f85e

…nd-reliability-of

Merge branch 'sdk-4188-puchases-android-improve-accuracy-and-reliabil…

544e8d2

…ity-of' into sdk-4188-puchases-android-improve-accuracy-and-reliability-of-2

Some PR review changes

a7f7d22

Merge branch 'sdk-4188-puchases-android-improve-accuracy-and-reliabil…

dbb6fc8

…ity-of-2' of github.com:RevenueCat/purchases-android into sdk-4188-puchases-android-improve-accuracy-and-reliability-of-3

Split cached data into original_observer_mode and related tests

3878eef

tonidero requested a review from JayShortway January 8, 2026 09:04

rickvdl reviewed Jan 8, 2026

View reviewed changes

Change to use PurchasesAreCompleted instead of originalObserverMode

95af91f

ajpallares reviewed Jan 8, 2026

View reviewed changes

purchases/src/main/kotlin/com/revenuecat/purchases/PostReceiptHelper.kt Outdated Show resolved Hide resolved

ajpallares reviewed Jan 8, 2026

View reviewed changes

purchases/src/main/kotlin/com/revenuecat/purchases/common/caching/LocalTransactionMetadata.kt Outdated Show resolved Hide resolved

Change purchase_completed_by to always have a value

5af7be1

tonidero requested a review from a team January 8, 2026 13:23

JayShortway approved these changes Jan 8, 2026

View reviewed changes

tonidero force-pushed the sdk-4188-puchases-android-improve-accuracy-and-reliability-of-2 branch from 544e8d2 to d7fff68 Compare January 8, 2026 14:53

Merge branch 'sdk-4188-puchases-android-improve-accuracy-and-reliabil…

90ac987

…ity-of-2' of github.com:RevenueCat/purchases-android into sdk-4188-puchases-android-improve-accuracy-and-reliability-of-3

tonidero requested a review from Copilot January 8, 2026 15:52

Copilot started reviewing on behalf of tonidero January 8, 2026 15:53 View session

Copilot AI reviewed Jan 8, 2026

View reviewed changes

ajpallares reviewed Jan 9, 2026

View reviewed changes

	receiptInfo.toString(),
	receiptInfo.toString(),
	purchasesAreCompletedBy.toString(),

		@SerialName("purchases_are_completed_by")
		val purchasesAreCompletedBy: PurchasesAreCompletedBy,

Improve accuracy of transactions origin Part 3: Merge cached data when posting receipts + Cache amazon data #2989

Are you sure you want to change the base?

Improve accuracy of transactions origin Part 3: Merge cached data when posting receipts + Cache amazon data #2989

Conversation

tonidero commented Dec 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

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

Uh oh!

Codecov Report

Uh oh!

JayShortway left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tonidero Jan 8, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JayShortway Jan 6, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rickvdl left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

JayShortway left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Key Changes

Reviewed changes

Uh oh!

Copilot AI Jan 8, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 8, 2026

tonidero commented Dec 31, 2025 •

edited

Loading

codecov bot commented Jan 5, 2026 •

edited

Loading

tonidero Jan 8, 2026 •

edited

Loading

JayShortway Jan 6, 2026 •

edited

Loading