Vercel can manage the Stripe key – which risks does this remove?

What Vercel has changed

Vercel Connect can now create and store restricted Stripe keys for your application. The feature was announced in Vercel’s changelog on 23 October 2026 and is called Managed API Key.

Previously, a common approach was to create a Stripe key, copy it and add it to Vercel as an environment variable. The same secret could then remain in place for a long time, be carried across environments and sometimes end up in local files, documentation or other services.

With the managed approach, Vercel instead creates a restricted API key directly in your Stripe account. You choose which Stripe resources the key can read or change. Vercel stores the key and links the connection to the projects and environments that should be able to use it.

When the application needs to communicate with Stripe, it calls getToken through Vercel Connect. Your running application authenticates itself to Vercel using OIDC – a short-lived identity linked to details including the project and environment. Vercel then checks whether the project is allowed to use the relevant Stripe connection.

It is important to distinguish between the identities in the chain:

• The application uses a short-lived Vercel identity to access Vercel Connect.
• Vercel Connect uses the restricted Stripe key to access Stripe.
• Stripe determines what the key can do based on the selected permissions.

This does not mean that the Stripe key itself has automatically become short-lived. It has moved from your application’s configuration to Vercel’s management. The security benefit comes mainly from not having to copy the key between systems and from being able to give it narrower permissions.

The risks that are actually reduced

The clearest improvement is that fewer people and systems need to see the Stripe key itself. You do not need to paste it into Vercel’s environment variables, send it to a developer or put it in a local .env file to make the integration work.

This reduces several common risks.

The secret is less likely to spread. Every place where a key is copied becomes somewhere that must be protected, inventoried and cleaned up after an incident. Management becomes simpler when Vercel creates and stores the key.

The application does not need to use Stripe’s full secret key. A restricted Stripe key could, for example, be allowed to read payment information without being able to issue refunds or change customers. If the key is exposed, the damage is limited to what the key actually permits.

Different tasks can have different permissions. A reporting job may only need to read data. A process that creates Stripe customers needs write access to customers, but not access to payouts. When these functions use separate connections, you do not need to give both of them the same broad key.

Rotation does not require the same changes to the deployment. Vercel lets you rotate the key from the connection settings without first changing an environment variable and redeploying the application. This reduces the risk of old values remaining in the wrong environment or an urgent rotation being postponed.

The project identity can replace a long-lived Vercel token. When the code runs on Vercel, Connect can use the project’s OIDC identity. You therefore do not need to create another static access token for the link between the application and Vercel Connect.

The improvements are therefore about fewer manual handovers, less spread of secrets and less potential damage if something goes wrong. They do not make access to Stripe risk-free.

The risks that remain

The main remaining risk is incorrect permissions. A managed key with broad write access can still change important data. Vercel storing the key does not make its permissions any less powerful.

You should therefore apply the principle of least privilege. Start with what the function needs to do in business terms, then translate that into Stripe resources. A job that compiles payment data normally needs read access. A customer flow that creates or updates customers needs write access to that resource. In Stripe, write access also means that the key can read the same resource.

You must also protect whatever is allowed to request the key. If a Vercel project is linked to the connection, code in an authorised environment can call Connect. A vulnerable server function, incorrect authentication or a compromised agent can therefore use Stripe within the key’s permissions. Connect does not replace controls in your own application.

For example, check that:

• the user behind a request is actually allowed to perform the action
• an AI agent cannot select arbitrary Stripe calls based on uncontrolled text
• amount limits and business rules are validated on the server
• administrative functions are not exposed through public API routes
• the Stripe key is never written to logs, error messages or tracing tools

Access to the Vercel account also becomes more important. Team members who can create, change or link connections can affect which projects can access Stripe. You should therefore review roles, sign-in protection and procedures for when someone leaves the team. Carry out the corresponding checks in Stripe, where the key and its permissions ultimately reside.

Also remember that the API key is not Stripe’s only secret. A webhook normally has a separate signing secret used to verify that an event really comes from Stripe. Vercel Connect does not replace it. Publishable Stripe keys, webhook secrets and any secrets in other integrations still need to be managed according to their own roles.

Separate testing from production

The environment boundary is particularly important because a Vercel connection can be linked to production, preview and development. A deployment being a preview does not automatically mean that it receives a harmless Stripe key.

If the same connection is available in several environments, code from a test branch could, in the worst case, access the same Stripe account and data as production. This applies even if the page itself is hosted at a temporary Vercel address.

You should therefore use separate Stripe connections for testing and production. The test connection should use a Stripe sandbox or test mode, while the production connection should use a live key with carefully selected permissions. Then link each connection only to the appropriate Vercel environment.

There is an important distinction between restricting which deployment can request a key and restricting which Stripe account or mode the key can access. The project and environment link in Vercel controls the first part. Separate connections and separate Stripe keys provide isolation in Stripe.

When testing the migration, do not only check that a payment succeeds. Review all server functions that use Stripe, such as customer creation, subscription changes, refunds, reports and background jobs. Restricted keys produce clear errors when a request lacks the correct permission, but the error may remain hidden until an uncommon function is used.

Review both the application logs and Stripe’s API request log. These show which resources are actually being used and whether the key is trying to do something it is not allowed to do. Remove unused permissions rather than keeping them just in case.

Plan for rotation and recovery as well. Vercel can keep the previous key valid during a transition when you rotate it. This makes a planned change easier, but if you suspect a leak, you need to know whether the old key still works and revoke it directly in Stripe if necessary.

Checklist before switching

A move to managed Stripe keys should be treated as a permissions migration, not simply as a change to where an environment variable is stored.

• Inventory every place where the application uses Stripe.
• Check whether the same Stripe key is used by several services, jobs or projects.
• Create separate connections for functions with different requirements.
• Grant read access where the code only reads data.
• Grant write access only to resources that are actually changed.
• Use a separate test connection to a Stripe sandbox or test mode.
• Check exactly which Vercel environments each connection is linked to.
• Ensure that preview deployments cannot access the production connection.
• Review which team roles can change, link and rotate connections.
• Check that token values are not logged or sent to analytics tools.
• Test uncommon flows and background jobs before removing the old key.
• Review API logs for denied requests and unexpected use.
• Document how to rotate and revoke the key during an incident.
• Manage the webhook signing secret separately.
• Remove old Stripe keys once the migration has been verified.

Vercel Connect therefore reduces the need to carry Stripe secrets between systems, but security still depends on what the key can do, which environments can access it and who can change the connection. If you want to carry out the same review when a prototype is being given real payments, permissions and production environments, you can read about moving from prototype to product.

---

Source: Vercel changelog