The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
Cancelling a purchase and failing a purchase reach your Flutter code the same way, as a PlatformException. That is how a paywall ends up showing a red error to someone who simply changed their mind on the store sheet.
PurchasesErrorHelper.getErrorCode is what distinguishes them, and two outcomes are not enough. A single call to Purchases.purchase can end five ways: cancelled, pending, completed, failed and unresolved. Pending is the one that catches people out. A parent still has to approve the purchase, or a slow payment method has to settle, and RevenueCat grants no entitlement until the store confirms it.
Which means the paywall screen should not be what decides access. A pending purchase can complete after the paywall closes or after the app has been killed, and RevenueCat does not push that change to the device. Keep a CustomerInfo listener in an object that lives as long as the app, and have every paid feature read the entitlement from it rather than from whatever the purchase call returned.
https://www.duskolicanin.com/blog/flutter-subscription-pending-cancelled-purchase
duskolicanin.com
Handle Pending and Cancelled Flutter Purchases
Handle RevenueCat cancelled and pending purchases in Flutter: map error codes to paywall states and unlock only from an active entitlement listener.
This is such a real pain point! So many paywalls break exactly here - treating a user cancellation as a crash. Thanks for pointing out PurchasesErrorHelper.getErrorCode to distinguish it. Handling cancelled vs pending correctly is crucial for UX, no one wants a red error for changing their mind. Saving this!
Thank you
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
Built two pricing sections for a concept invoicing app in code with Claude Code. Same Starter, same Pro, same prices. B only adds a $79 plan that isn't really there to be bought.
Which one gets you to pick Pro, A or B?
0 voted
0%
24 voted
100%
24 votes
Closed
B for me. Next to $79, Pro at $24 looks like the sensible middle, and the dark Pro card already does half the work.
A push notification model usually breaks in one of two ways: a second phone stops receiving anything, or notifications keep arriving for the account that just signed out. Both come from storing one push address per user. Store one row per app installation instead, with the user ID as a field, and someone with a phone and a tablet has two rows that a single query returns.
The sign-out half has an ordering trap. Delete the installation row while the user is still signed in, then call signOut. A security rule that compares the row owner to the signed-in user refuses the delete once there is no user left to compare against, and the device keeps pointing at the previous account.
The full write-up covers the Firestore rules, the Flutter registration listener, a server cleanup that handles both unregistered error codes, and an acceptance sequence to run on two test installations.
duskolicanin.com
Keep Flutter Push Tokens Correct Across Devices
Fix Flutter push notifications that miss a second device or follow the previous user: store one FCM installation ID per device and prune unregistered IDs.
Great technical breakdown! Handling multi-device FCM tokens and secure sign-out correctly is essential for reliable push notifications. I appreciate the focus on both architecture and real-world edge cases. 👏
Backfill: every cancellation becomes a booking.
Why: a late cancellation leaves an empty chair. Filling it means calling down a waitlist, which nobody at a busy front desk has time for, so the hour and the revenue are simply lost.
What it does: when a patient cancels, Backfill offers the slot to everyone on the waitlist whose service, day and time match, all at once. The first to tap Claim gets it. The slot is re-checked first, so nobody is ever double-booked. Everyone else is told it's taken and keeps their place. The front desk sees every step on a live dashboard, along with the revenue recovered. If nobody claims within 30 minutes, staff get a "Needs you" alert.
Try it: open the link and choose "Use a demo account". Nora is the front desk; Sarah, Mike and Amara are patients. Cancel as Sarah in one window and claim as Mike in another. Or register with your own email and tap "Send me an offer" to get the real offer email.
Built with Base44: the data model, the offer chain, a demo clinic that refreshes every day, a demo sign-in with an in-app inbox, real offer emails, and a split-screen demo view.
Behind the build: a design system and a clickable prototype first, then every screen rebuilt in Base44's AI chat, one prompt at a time.
Data, offer automation, real emails and the front desk dashboard all run on Base44, responsive down to a phone.