Charged but the AI plan is not active: a recovery-flow case study
A structured recovery flow for the moment a charge appears but benefits do not, distinguishing authorization from settlement and tracing the most common root cause: account identity mismatch across channels.
The situation: the bank shows a charge, but the product account still shows the free plan. The first critical distinction is whether the charge is a settled transaction or a temporary authorization. An authorization can reserve funds for days without creating a successful order, and only the payment provider controls its release timing. This distinction determines whether you are recovering an order or waiting for a hold to drop.
The most common root cause in our case reviews is account identity mismatch: the user signed in with a different email, used a different single-sign-on method, or the purchase happened in a store account that has not been restored into the product account. The charge is real, but it is attached to an identity the user is not currently viewing. Before contacting support, check which product account was signed in and whether the purchase was web, Apple, or Google Play.
The recovery steps: check both the product account's subscription page and the store order page; sign out and back in once; update the official app; use the provider's 'restore purchase' action if available. Do not buy a second plan while the first is unresolved—this is how duplicate subscriptions start. If access is still missing, prepare the order ID, charge time, amount, currency, account email, and channel for support.
The outcome of this flow: most 'charged but not active' cases resolve without a refund once the correct account identity is found or the store purchase is restored. The lesson is that a missing benefit is usually an identity routing problem, not a payment failure. The limitation: if the charge was an authorization that never settled, the resolution is waiting for release, not a dispute.