Skip to main content
Question

Problem after upgrading to version 9.0.0

  • August 10, 2026
  • 1 reply
  • 30 views
T
Forum|alt.badge.img

Recently, we upgraded both our libraries (purchases and purchases-ui) to version 9.0.0 because Google Play required apps to use Play Billing Library (PBL) version 8 or later.
Before that we had no issues with our app, purchases worked fine in locall and production enviroment.
A few days ago a user issued an email to us that he tried to make a purchase of our one time package(‘consumable’). In revenue cat we saw that he was charged but the item in our app was still locked (indicating the payment wasnt successfull). I tried to trace where was the issue, but i couldnt find out. Today for the first time i replicated the issue and i made the same one time purchase in my local enivorment (sanbox), it registered the payment in revenue cat but i saw these error logs: 
There was a problem with the App Store. Problem communicating with the Store when trying to validate the receipt.
The strange part is this issue happens at random times. After this unsuccessful payemnt i made, i tried a second time and every attempt after that was successfull. For now only one user had this issue in production, but it may escalate to more users.
The issue occurs on ios devices.

This is the data we recieve on the purchase (ive cleared all ids):
{
  event: {
    event_timestamp_ms: 1786367717255,
    product_id: 'skinScan',
    period_type: 'NORMAL',
    purchased_at_ms: 1786367684000,
    expiration_at_ms: null,
    environment: 'SANDBOX',
    entitlement_id: null,
    entitlement_ids: null,
    presented_offering_id: 'skinScan',
    transaction_id: “exampleid',
    original_transaction_id: 'exampleid',
    is_family_share: false,
    country_code: 'BG',
    app_user_id: 'exampleid',
    aliases: [
      'exampleid',
      'exampleid',
      'exampleid'
    ],
    original_app_user_id: 'exampleid',
    currency: 'EUR',
    price: 2.877,
    price_in_purchased_currency: 2.49,
    subscriber_attributes: { '$attConsentStatus': [Object], userId: [Object] },
    store: 'APP_STORE',
    takehome_percentage: 0.85,
    offer_code: null,
    tax_percentage: 0.145,
    commission_percentage: 0.15,
    metadata: null,
    renewal_number: null,
    discount_percentage: null,
    discount_amount: null,
    discount_identifier: null,
    type: 'NON_RENEWING_PURCHASE',
    id: 'exampleid',
    app_id: 'exampleid'
  },
  api_version: '1.0'
}

 

    1 reply

    H
    RevenueCat Staff
    Forum|alt.badge.img+8
    • Haley Pace
    • RevenueCat Staff
    • August 13, 2026

    Hi ​@tanya-zhecheva, that log is RevenueCat’s STORE_PROBLEM error. “Problem communicating with the Store when trying to validate the receipt” is our backend error 7101, returned when receipt validation with Apple fails or times out. On iOS this is usually a Apple/sandbox communication issue — which matches the intermittent pattern you described (fail once, then succeed). Docs: https://www.revenuecat.com/docs/test-and-launch/errors
    Background: https://community.revenuecat.com/featured-articles-55/what-does-the-error-there-was-a-problem-with-the-app-store-play-store-mean-480

    With StoreProblemError, the user may or may not have been charged, and the purchase can still land in RevenueCat even when the SDK reports an error. Your sandbox webhook (NON_RENEWING_PURCHASE for skinScan) fits that — RC recorded it while the client logged an error.

    The upgrade to purchases / purchases-ui 9.0.0 for Play Billing Library 8 is an Android-side change and isn’t related to this iOS App Store validation path.

    If a production user is charged but content stays locked, restore/sync and confirm your unlock path reads the latest customer state (for a permanent unlock of a feature, prefer a non-consumable + entitlement rather than a consumable).

    If you can share the project this is for, the full debug logs from the snippet you shared, the production App User ID and whether you unlock via entitlements vs. your own backend on the webhook and the code for this that would be helpful! I recommend sharing this in a Community Direct Message to me or in a RevenueCat Support ticket to avoid sharing sensitive information publicly: https://app.revenuecat.com/settings/support?tab=contact

    Terms & ConditionsAccessibility statement