**Problem** When upgrading a subscription with proration-charge-immediately, there's no way to show the customer what they're about to be charged. The upgrade endpoint applies the change and takes payment in the same call, so the prorated amount is only knowable afterwards, from the resulting transaction. Any upgrade flow that needs a confirmation step — "You'll be charged $X today, continue?" — can't be built accurately today. It's also awkward wherever disclosing the amount before charging is expected practice. **Why this can't be worked around merchant-side** The prorated base can be calculated in-app with some effort. The tax can't. As merchant of record, Creem calculates VAT, GST and sales tax across 190+ jurisdictions from the customer's location and status, so any figure a merchant computes is an estimate rather than the amount that will actually be charged. Discounts, existing credit balances and final rounding compound the same gap. That makes this a platform capability rather than something merchants can build around. **Request** An endpoint that returns the exact amount an upgrade would charge, without applying it — effectively a preview of the upcoming invoice. Given a subscription, a target product and an update_behavior, it should reflect proration, tax, active discounts, available credit balance and rounding, and return the same total the customer would actually be charged. **Current options and why they fall short** - Estimate it app-side and caveat it as approximate. Works, but isn't authoritative and the receipt may differ from what was shown. - Switch with proration-none and charge the difference through a separate checkout session. The checkout does display the exact taxed total before payment, but it splits one plan change into two transactions and the proration base is still merchant-computed.
