I’m working on a PHP application that needs to use both the Chrome Web Store payments system and Google Drive API together. I’ve run into a major problem with the manifest configuration.
My app already has the Chrome Web Store licensing API working perfectly. When I tried to add Google Drive functionality using the PHP examples, I kept getting save errors and JavaScript console errors. After some debugging, I figured out that the manifest.json file needed updates - specifically setting the container to GOOGLE_DRIVE and adding the proper API console ID.
But here’s where things get tricky. After making these changes, the Chrome Web Store developer dashboard shows this warning message that basically says apps using containers other than CHROME cannot use the Web Store payments feature.
This creates a real problem for me. Do I set the container to CHROME or GOOGLE_DRIVE? It seems like I can’t have both working at the same time.
My main questions are:
- Is it actually possible to combine Drive API access with Chrome Web Store payments in the same PHP app?
- Are Google Drive apps required to be completely free?
- What’s the correct way to handle the container setting when you need both APIs?
I want to make sure I’m building something that won’t break when older authentication methods get deprecated. Any guidance would be really helpful.
honestly this containers thing is such a pain, ran into the same wall couple months back. you basically gotta pick one or the other - cant have chrome store payments with GOOGLE_DRIVE container. i ended up going with stripe for payments instead, way cleaner setup and you keep the drive integration working properly.
I encountered something similar about two years ago when building a document management tool. The container restriction is unfortunately real and creates this exact dilemma you’re facing. From what I learned through trial and error, Google Drive apps don’t necessarily have to be free, but they can’t use the Chrome Web Store payment system directly. The workaround I ended up implementing was handling payments through a separate web application that communicates with the Drive app through postMessage APIs. Basically, I kept the Drive integration as a free app with container set to GOOGLE_DRIVE, then created a companion web service that handles the subscription logic and licensing checks. The Drive app queries this service to verify user permissions before enabling premium features. It’s definitely more complex than having everything in one place, but it works reliably and doesn’t violate Google’s container restrictions. The authentication flow becomes a bit more involved since you’re essentially managing two separate authorization contexts, but it’s been stable for me even as Google has updated their APIs. The key is making sure your licensing checks happen server-side so users can’t bypass them easily.
You’ve hit one of Google’s more frustrating platform limitations. I dealt with this exact scenario last year when trying to monetize a productivity app that synced with Drive. The container setting is basically forcing you to choose between payment integration and Drive functionality, which seems counterintuitive from a developer perspective. What I discovered through Google’s developer support is that Drive apps with GOOGLE_DRIVE container are meant to follow their different monetization approach. Instead of Chrome Web Store payments, you’re expected to implement your own subscription system or use Google Pay API directly within your web application. The Drive container essentially puts you outside the Chrome Web Store ecosystem for payments. The approach that worked for me was restructuring the app architecture. I created a web-based subscription portal that handles all payment processing independently, then the Drive app checks licensing status through secure API calls to my backend. Users subscribe through the web portal first, then install the Drive app which validates their subscription server-side. It’s definitely more work than the integrated Chrome Web Store approach, but it’s actually more flexible long-term since you’re not locked into Google’s payment processing fees and restrictions.