Summary
When trial mode is enabled in Cafe Bazaar (Poolaki), and a new user initiates a purchase using a standard subscription SKU, Bazaar silently substitutes the requested product with a trial product. Because the app has no way to anticipate or detect this substitution before the purchase flow begins, it cannot reconcile the returned productId with the requested one — resulting in a failed purchase acknowledgement and an unrecoverable state.
Environment
Platform: Android
Store: Cafe Bazaar (Poolaki billing library)
Feature: Trial Mode (enabled)
Steps to Reproduce
Enable trial mode in the Bazaar developer console.
A new user (with no prior subscription history) opens the app.
App initiates a purchase request for a standard subscription SKU (e.g., premium_monthly).
Bazaar substitutes the product with a trial SKU internally.
onPurchasesUpdated is called with the trial product — not the requested one.
App logic fails to match the returned productId to the expected SKU → purchase is not acknowledged → transaction fails.
Expected Behavior
Before initiating a purchase, the app should be able to determine whether a user is eligible for a trial (i.e., has no prior subscription history). This allows the app to request the correct product upfront and avoid any mismatch.
Actual Behavior
No API exists to check a user’s subscription history prior to initiating a purchase. As a result, when trial mode is enabled, the app has no way to know that Bazaar will substitute the requested product with a trial — and cannot prevent or handle this substitution proactively.
Impact
The app enters an unrecoverable state because the purchase flow is taken over by Bazaar before the app can validate eligibility.
No programmatic way to gate trial offers or route users to the correct product SKU.
onPurchasesUpdated returns null or an unrecognized product, causing the purchase acknowledgement to fail silently.
Developers are forced to either disable trial mode entirely or accept undefined behavior for new users.
Suggested Solutions
Option 1 — Respect the Requested SKU (Workaround)
Bazaar should not automatically substitute the requested product with a trial unless the app explicitly requests a trial SKU. The substitution should be opt-in at the request level, not a global side effect of enabling trial mode.
Option 2 — Provide a Subscription History API (Preferred)
Expose an API that allows developers to check whether a user has ever held a subscription on this account. For example:
kotlin
BazaarBilling.hasEverSubscribed(productId: String): Boolean
// or
BazaarBilling.getSubscriptionHistory(): List
This would allow developers to:
Check eligibility before initiating the purchase flow
Request the correct SKU (trial vs. standard) based on the result
Provide accurate UI to the user prior to any transaction
Summary
When trial mode is enabled in Cafe Bazaar (Poolaki), and a new user initiates a purchase using a standard subscription SKU, Bazaar silently substitutes the requested product with a trial product. Because the app has no way to anticipate or detect this substitution before the purchase flow begins, it cannot reconcile the returned productId with the requested one — resulting in a failed purchase acknowledgement and an unrecoverable state.
Environment
Platform: Android
Store: Cafe Bazaar (Poolaki billing library)
Feature: Trial Mode (enabled)
Steps to Reproduce
Enable trial mode in the Bazaar developer console.
A new user (with no prior subscription history) opens the app.
App initiates a purchase request for a standard subscription SKU (e.g., premium_monthly).
Bazaar substitutes the product with a trial SKU internally.
onPurchasesUpdated is called with the trial product — not the requested one.
App logic fails to match the returned productId to the expected SKU → purchase is not acknowledged → transaction fails.
Expected Behavior
Before initiating a purchase, the app should be able to determine whether a user is eligible for a trial (i.e., has no prior subscription history). This allows the app to request the correct product upfront and avoid any mismatch.
Actual Behavior
No API exists to check a user’s subscription history prior to initiating a purchase. As a result, when trial mode is enabled, the app has no way to know that Bazaar will substitute the requested product with a trial — and cannot prevent or handle this substitution proactively.
Impact
The app enters an unrecoverable state because the purchase flow is taken over by Bazaar before the app can validate eligibility.
No programmatic way to gate trial offers or route users to the correct product SKU.
onPurchasesUpdated returns null or an unrecognized product, causing the purchase acknowledgement to fail silently.
Developers are forced to either disable trial mode entirely or accept undefined behavior for new users.
Suggested Solutions
Option 1 — Respect the Requested SKU (Workaround)
Bazaar should not automatically substitute the requested product with a trial unless the app explicitly requests a trial SKU. The substitution should be opt-in at the request level, not a global side effect of enabling trial mode.
Option 2 — Provide a Subscription History API (Preferred)
Expose an API that allows developers to check whether a user has ever held a subscription on this account. For example:
kotlin
BazaarBilling.hasEverSubscribed(productId: String): Boolean
// or
BazaarBilling.getSubscriptionHistory(): List
This would allow developers to:
Check eligibility before initiating the purchase flow
Request the correct SKU (trial vs. standard) based on the result
Provide accurate UI to the user prior to any transaction