[gnicholas]

This is super annoying. I have two extensions, one which we've offered on Chrome and Firefox for years, and which uses Stripe for payments. The other we only offered on Chrome and was paid through the Chrome Store. Thinking of all the work we'll have to do to manage accounts/payments/etc on the PDF extension almost makes me want to scrap the whole thing.

Most frustrating is the migration. We have been live in the Chrome Store for 7 years, with varying prices. When someone subscribes, they are grandfathered at that price forever. But when we create our own payment system, how do we know what price someone was previously paying? We can either make our new customers really happy by charging all grandfathered users the lowest price we ever charged, or we can upset a bunch of our older customers by charging everyone the current price (which is 5x the former).

One fair way to accommodate everyone is charge the high price but if someone forwards us their receipt from the Chrome Store showing a different price, we apply a perpetual coupon to their account. But that will be super labor-intensive (and is susceptible to manipulation/abuse).

[katzgrau]

Depending on what 5x is, you might not annoy as many users as you think.

I did a major pricing overhaul with my SaaS company a few years ago and made lots of sincere appeals to users. They generally supported me and the app. I had some churn, but I knee it was coming. It worked out for the best.

Of course, my experience is going to be unique but with the right transparency and explanation you may be overcome a lot of reflexive pushback.

[Axsuul]

Are you able to query what they were paying? e.g. google.payments.inapp.getPurchases

[gnicholas]

Yeah, it looks like there is a way to do this. But this requires them to authenticate to allow it, and is a hassle on both ends. Seriously, what a huge pain for all involved. It is shocking they are giving such a short timeline for this transition, especially during COVID (they use COVID as an excuse for slow processing times, but clearly they don't care that devs would be similarly affected).

[exikyut]

Maybe provide some options:

- Default to an automatic resubscription for (say) 50-75% of the current list price

- Consent to OAuth2<->Google ("one-time blahblahblah"), and retrieve perpetual payment info that way

- Accept Store receipts (capturing all email headers and keeping all PDFs for cross-comparison... meh)

I wonder if you should send 2 warning emails or 3. ("action required" "your account will automatically be subscribed unless...")

This is maybe a gray-ish pattern, but would convert some percentage of users to a higher ongoing subscription level. This sounds like a line-of-business type extension, so that percentage may be marginally appreciable.

Perhaps combat the boringness aspect of the store-receipt process by sending solicitation emails ASAP to get that rolling.

And, hrm, anticipate refunds. :(

[gnicholas]

Yeah, if we could email our customers that would be great. Unfortunately, I can't find a way to access the email addresses for our customers. Maybe I'm really dumb, but all I can find are anonymized transaction IDs.

It would be a lot better if they would allow us to contact our users via email. Instead, we're going to have to use pop-up messages that annoy users and are likely to be reflexively closed by many of them.

I'd love to know what they are communicating to users, and when. At least then we could wait to communicate with them until just after they send an email, so that users would be less likely to ignore our messages. As is, it feels like we're flying blind.

[exikyut]

Oh noooo. I see now. The documentation helpfully completely sidesteps this probably quite widespread scenario!

Thinking about it, it's not really on point for Google™©® to connect you with your customers; your outreach could be considered unsolicited and G could be argued to be enabling spam. What a wonderful situation G has dug for itself here.

The only thought I can come up with is to partially break or otherwise "wait what"-ify your extension's behavior to concretely capture users' attention. You mentioned it does PDF processing of some kind; a relevant example in this case could be injecting new page(s) into generated output (or watermarking, but that may be mechanically trickier, and my knee-jerk connection to watermarking could wind up being "meep, this software has just gone rogue on me" - and depending on my stress level I may not actually read any notices).

Said injected (or overlaid) content would likely immediately first clarify that visiting the options page and clicking a giant green button will 100% revert functionality. It would probably also do well to include a website name (also showing a giant banner), a contact email address (RIP in advance), and possibly a suggestion/invitation to forward the PDF to internal IT for review in case of doubt (which would neatly offload some % of "???" to external labor that is incidentally highly trusted, but may look odd).

FWIW, I noticed the latest versions of Chrome have redesigned the extension UI; overflow icons have moved from the system menu into a dedicated popup. Some users (Windows) likely have this update, while others (eg, myself using Chromium 83.0/Debian, and version-locked enterprise users) don't. So hypothetical screenshots would need to illustrate both flows.

Besides all that, auto-renewing to some (non-low-end, because why not) percentage of the current list price, and straightforwardly handling refunds, seems to be the only obvious fallthrough I can see.

[gnicholas]

> Besides all that, auto-renewing to some (non-low-end, because why not) percentage of the current list price

Yeah, but we can't even auto-renew. We have to set up every customer new in Stripe and get their permission to charge them. There's literally no way for me to make this automatic. If Google is going to get rid of this functionality they should at least make it super easy for us to transition customers. Otherwise they're going to have a bunch of angry customers and devs on their hands.

[dalbasal]

Old school HN comment. useful

[summitsummit]

and annoying. you're charging your most loyal users the cost of providing proof after all these years.

[mikro2nd]

Or don't. Just ask users to tell you (without any burden of proof) if they've been paying less. Will a handful of users abuse this? Probably. My bet is that the vast majority are honest people -- particularly if the circumstances are clearly and simply communicated -- and will not take undue advantage. The upside is that you won't be pissing off the honest majority, and the cost is probably (admittedly unprovably) small.

[summitsummit]

> My bet is that the vast majority are honest people

what makes you believe this? feel like this is Hobbes vs Rousseau

[divbzero]

That really sucks. I’m guessing Google aggregates payments so there’s no way of getting individual subscription data?

If you explain the predicament clearly, succinctly, and with as easy a resolution as possible, I think a lot of your customers will understand the situation and appreciate that you’re doing your best for them.