Adding Google OAuth to a production application presents an interesting challenge: although you need to publish the environment to a location accessible to Google's reviewers, the user experience will deteriorated if the environment is released to the production without any design. We, the Giselle development team, recently faced this exact situation and discovered an elegant solution using Vercel's Custom Environments feature.
We'll share our journey through this process, including the approaches we considered, the solution we finally chose, and the practical lessons we learned along the way. Whether you're working with Vercel, Supabase, Stripe, or a similar stack, this experience will help you prepare for verification by Google.
The OAuth Verification Puzzle
We wanted to add Google OAuth signup/login functionality to our released application. However, we needed to keep the functionality unreleased until our OAuth client being approved; releasing before Google's verification would spoil user experiences by showing an "unverified app" warning in the consent screen.
We had to figure out how to manage this with the infrastructure stack listed below:
The approach shown in this post is particularly useful for development teams who have already implemented Stripe payments in production and want to add Google OAuth login functionality afterward.
Options Considered
Using Production Environment (Rejected)
Although our first instinct was to use our Production environment with limited release controls, we found that this approach brings a cumbersome requirements: we need to implement payment bypass logic for verification process because registering transactions without actual payments violates Stripe's services agreement.
We initially considered how we can meet our requirements with this approach, but decided to look for alternatives after exploring these possible methods:
- Add authentication (URL query parameters, etc.) and share credentials with Google reviewers
- Cons: Requires additional implementation
- Use Vercel Feature Flags
- Cons: Feature users (Google reviewers) would need Vercel accounts
Using Vercel Preview Environment (Rejected)
Vercel's Preview environments seemed promising until we discovered they didn't meet Google's verification requirements:
- Preview environments are hosted on
vercel.appby default- We need additional $100/month to attach custom domain to Preview environments using Preview Deployment Suffix
We rejected this solution because the required cost was too expensive for what we want to achive.
Using Vercel Custom Environment (Our Solution)
Vercel's Custom Environments feature emerged as our ideal solution, offering:
- Custom domain support without additional charge
- No Vercel accounts needed
- Flexible environment variable management
- Clean separation from Production
Details of this approach are described in the following sections.
Implementing the Solution
Although we can create the environment by following steps described in the official document, there are some tips specific to this context.
Initially, our environment was configured as shown in the figure below:
Copy environment variables from pre-productions
We need to use Stripe with Test mode or Sandboxes to avoid violating their services agreement: the environment variables for Stripe should be copied from Preview environments. To avoid confusion, other environment variables should also be copied from pre-productions (Preview- and Development- environments).
The important exceptions are the environment variables fore Google OAuth client, that will be explained in the next section.
Use Production-Google OAuth client
During the development of Google OAuth login/signup functionality, we used two OAuth client: one for Preview environments, and the another for Production. On the Custom environment to submit for verification process, we must use environment variables for Google OAuth to use on Production. Needless to say, once an OAuth client has passed the verification process, we must use exactly the same client on Production.
This also means that environment of the authentication service (Supabase Auth in our case) must also reference the OAuth client that will be used in Production:
Release the functionality on Custom environment via environment variable
The smaller the difference in environment, the better. To submit Google OAuth login/signup functionality for verification, we released the functionality by toggling a Vercel Feature flag by changing environment variable. This enabled feature releasing without any changes to the application code.
Verification Process Made Elegant
Our Google OAuth verification process proved seamless thanks to Vercel Custom Environments, providing a dedicated verification environment without compromising our released app and even development workflow.
Post-verification, we successfully completed two critical transition steps:
- Configured the development environment of Supabase Auth to refer development-OAuth client (shown in the figure below)
- Removed the code related to Vercel feature flag
This smooth transition allowed us to launch Google OAuth signup/login functionality while maintaining third-party compliance and preserving user experience. The approach demonstrated that with the right environment strategy, you can prepare production-ready authentication methods that satisfy both verification requirements and development needs—all without disrupting your existing services. At Giselle, we're committed to creating seamless authentication experiences while maintaining the highest standards for security and user experience. This solution represents our approach to technical problem-solving: evaluating multiple options, choosing the most elegant path forward, and documenting our journey to help others facing similar challenges. As we continue enhancing our AI Agent Builder platform, we'll keep sharing these practical insights from our development process. We'd love to hear about your experiences implementing OAuth verification or using Vercel Custom Environments in your projects!