Hi,

This is something you would have to keep track of yourself. What you could do is:

1. Add a flag for each IAP to your user’s data in the backend (hasPurchasedA, hasPurchasedB)
2. When a purchase occurs (can listen to webhooks for this), flip the boolean from false to true
3. When building the paywall, don’t show products (from the getOfferings call) that the user has purchased.

Thanks Ryan, I should have mentioned I am using the RC paywalls and was hoping to exclude products from them. What I have done instead is to create offerings that only have one package in them and using a list of available products in my UI that activates the selected paywall using the offering parameter.

“Flip the Boolean from false to true?” - and what if I subscribed on iPhone and try to open paywall on iPad?
 

when you initialize RC Purchases object, you can retrieve all purchases and offerings; you can also subscribe on “event stream” so that whenever you purchase product on iPhone, your “callback” will trigger paywall screen refresh on iPad, in less than a second.

@Bamba we provide multi-platform support, but you’ll need to configure your user identification correctly. If that’s all in place, you’d check that boolean in your user’s data on your backend.

I do not understand what you mean. Which question do you try to answer?

Original question asked (not by me!): 

“is there some way to exclude products (packages) that have already been purchased from the paywall when displaying the offering?”

My answer: Not. Revenue Cat Purchases API doesn’t implement this, we need to implement it ourselves, and implementation depends on use case: for example, if you selling coffee vs. selling monthly subscription.
 

For example: 

Purchases.addCustomerInfoUpdateListener((customerInfo) async {

bool active = customerInfo.entitlements.alln`MySuperPuperSubscription`]!.isActive


Or, another example using Firebase claims (set by RC extension webhook):

// use "true" to enforce "token" refresh and receive updated "claims"
IdTokenResult idTokenResult = await u!.getIdTokenResult(true); 


if (idTokenResult.claims != null &&

idTokenResult.claims!i'revenueCatEntitlements'] != null &&

!idTokenResult.claims!i'revenueCatEntitlements'].isEmpty &&

idTokenResult.claims!i'revenueCatEntitlements']e0] == 'premium') {

subscriptionStatus.value = SubscriptionStatus.premium;

In this specific case, App Store sends Purchase event to Revenue Cat, which calls Web Hook at Firebase Firestore (which is Revenue Cat extension) which sets “claims”. Developer can configure and register alternate webhook with Revenue Cat to keep track of purchases. Maybe there is some part of “RC Purchases API” which allows to query if customer purchased specified product or not, I don’t know,  and @Ryan Glanz suggests to “flip boolean” ;)

Revenue Cat has all this purchase history, but it is probably too much burden to implement richer API: indeed, it is very “vendor specific” and it is use case specific. Revenue Cat should show “offerings” “as is” as received from App Store (for example); and is it “use case specific” because we don’t know if it is the same subscription but on new device, or the same book, same cup of coffee, or “upgrade subscription” offering, etc. 

Revenue Cat is not “true source of knowledge”, neither third-party (such as custom webhook & events processor); so that in the most robust scenario developer should use App Store API to get answer directly from the “seller”.
 

So, in short, Revenue Cat SDK such as offerings = await Purchases.getOfferings();  won’t give any indication if customer already owns product or not

• Revenue Cat team suggests to “flip boolean”
• You can implement your own “web hook” to “flip boolean”
• You can call App Store API to get access to already implemented “boolean” and indeed it is “true source of knowledge”; it will be faster; Revenue Cat could be out of sync with App Store
• You can also rely on Firebase Firestore Custom Claims for example, but there are even higher risks of being “out of sync”, this is very specific solution for those providing Firestore-based subscription services
• it is technically *impossible* to implement such getPastPurchases(userId) API as part of RevenueCat client SDK: purchases are made at third-parties such as Google Play or Apple App Store, or tens of other vendors, and data is out of sync; you might be migrating new customers to RC, but how to support old customers? RC is just “web hook”; true “sellers” are true “source of knowledge” to get historical data.
  
  Thanks