Vipps MobilePay is woven into everyday life across the Nordics. The company powers P2P transfers, in-store checkout, and online payments, with 400,000 merchants relying on it as part of their payment infrastructure. In the last year alone, the platform processed about 1.2 billion payments.

What began as two separate companies, Vipps and MobilePay, became one Nordic payments leader when they merged in October 2022. The combined organization decided to standardize on the Vipps platform as the core infrastructure, onboarding Finnish and Danish MobilePay users onto the unified stack.

The result was a huge success. In December 2023, with Vipps live only in Norway, the platform supported roughly 4.5 million users, already impressive in a country of 5.5 million people. By March 2024, after launching the new app in Finland in January and in Denmark in March, that number had leapt to around 11.5 million users in just a few months.

Behind the scenes, the traffic profile is substantial: around 10 billion API requests per month, about 350 million per day. During the quietest periods around 4 a.m., traffic dips to 360–400 requests per second, then surges to peaks of about 8,000 requests per second during busy hours.

All of this runs on a cloud native, Kubernetes-driven architecture in Microsoft Azure. From day one, Vipps MobilePay has been “all in” on Azure, running most workloads on Kubernetes with a homegrown operator on top. The platform team provides infrastructure and paved roads; about 40 product teams across Norway, Denmark, and Finland own their own APIs and applications, deploying continuously without platform engineers sitting in the middle.

Its startup-style culture and values — trust, one-team collaboration, and “keep it simple” for customer value — would later shape how Vipps MobilePay approached one of its biggest infrastructure shifts: migrating from Azure API Management (APIM) to Kong.

For years, Azure APIM sat at the core of Vipps MobilePay’s API gateway layer. It worked and processed transactions without major issues. But the merger with MobilePay and the resulting traffic growth exposed architectural and operational limits that the team could no longer ignore.

The daily traffic pattern was a challenge in itself. In just one hour, Vipps MobilePay sees around 40% of its daily traffic. With Azure APIM, scaling up to handle that surge could take up to 45 minutes.

“We originally used auto-scaling and leveraged it,” said Adam Shaw, Senior Platform Engineer and migration lead at Vipps. “But after the merger with MobilePay, we started to see that we weren’t able to complete the scale-up within the timeframe. We might start to auto-scale around 11, the peak is at 11:30, and we’re still scaling.”

The situation was complicated further by the company’s decentralized API model. Teams owned their APIs and their OpenAPI specs, which were stored in their own repositories. The platform team provided an operator and a deployment pattern that rolled everything out, but they did not centrally manage every API definition or gateway configuration.

When the decision to move to Kong came down from management, it came fast and with a tight deadline. 

“We have a startup mentality, so we have a very short path to action," said Kaja Hannestad, Senior Platform Engineer at Vipps. "We got the decision that we would move to Kong quite suddenly. We didn’t have a lot of time to prepare, and management told us we had to do it in six weeks.”

Underneath that urgency sat several technical and organizational challenges:

• Tight coupling to Azure APIM. The existing traffic flow routed via Azure App Gateway → Azure APIM → NGINX ingress → Kubernetes pods. Any change in that layer risked impacting mission-critical APIs.
• Implicit, permissive behavior in APIM. Over time, APIM had allowed all sorts of edge-case paths and behaviors—trailing slashes, double leading slashes, double trailing slashes, case-insensitive paths. Many of these quirks were invisible to the platform team but fully exploited by “creative” integrators.
• Decentralized ownership with hidden complexity. API manifests lived in product team repositories. The platform team didn’t have a clean, central inventory of every API, path, and policy.
• Limited time and resources. The platform team didn’t have the capacity to fully re-architect its operator and deployment patterns before the migration.

Initially, the plan was to migrate “as-is” from Azure APIM to Kong.

Vipps MobilePay chose Kong as the foundation for its next-generation API layer. The decision was driven by performance, developer experience, and architectural alignment with the company’s Kubernetes-first approach.

“This is our bread and butter,” Shaw said. “All of our workloads run in Kubernetes. So this is where we feel most comfortable.”

Canary migration with safety brakes

The first problem to solve was migration safety. The team needed a way to shift APIs gradually from APIM to Kong without jeopardizing stability. The original traffic flow was: App Gateway → Azure APIM → Ingress NGINX → Kubernetes pod.

To enable a controlled migration, they introduced a canary proxy box that could split traffic between Kong and APIM by percentage.

“We had to figure out how we could come up with a setup where we could migrate APIs one by one while keeping the operational stability," Hannestad said. "So we introduced a canary proxy where we could percentage-wise split the traffic between Kong and APIM during the migration phase.”

In the early stages, they capped traffic to Kong at 90%. That meant they could always roll back completely to APIM in case of incidents, major events, or predicted spikes in load. The target end state was much simpler: App Gateway → Kong (running in AKS) → Kubernetes pod.

A phased migration timeline

The migration played out over several months:

• May 2025: First production traffic began flowing through Kong. The team prioritized high-volume APIs to see significant traffic quickly and scale down APIM usage to save costs.
• June–July 2025: A flat period due to summer change restrictions. Migration slowed as the company enforced a freeze to protect stability.
• September 2025: For APIs already running with 90% traffic through Kong, the team flipped those to 100%, which was, as Hannestad put it, “a huge bump in traffic and kind of the point of no return in our migration."
• October 2025: Vipps MobilePay was 100% migrated to Kong across all environments. Azure APIM has been fully decommissioned, with resources deleted.

In total, the migration took about seven months.

Faster auto-scaling aligned with traffic realities

Kong’s performance and tight integration with Kubernetes yielded immediate benefits for auto-scaling.

Since moving to Kong, Vipps MobilePay has achieved an 89% decrease in scale time: what previously took up to 45 minutes now takes about five minutes end-to-end. Four of those minutes are spent provisioning and joining new nodes to the cluster and spinning up daemon sets; about one minute is Kong itself loading.

“If we were to pre-warm nodes, this could actually be even faster,” Shaw noted.

YAML-first developer experience

Developer experience was another strong motivator. In Azure APIM, “policies” are the equivalent of Kong plugins. They’re configured using C# and XML.

“For some developers, that’s perfectly fine,” Shaw said. “But for us, we prefer YAML. When we want to go to market and bring in new people, we also feel that using YAML is more accessible.”

Kong’s declarative configuration model fits naturally with Vipps MobilePay’s GitOps-style workflows and its preference for YAML-based manifests.

Centralized pipelines, decentralized manifests: “centralized decentralization”

One of the most distinctive aspects of Vipps MobilePay’s approach is what the team calls centralized decentralization.

Historically, their operator deployed APIs for teams, while the teams kept their OpenAPI specs in their own repositories. That pattern allowed developers to move fast and own their APIs. During the Kong migration, the team didn’t have the time or resources to fully integrate Kong into the operator — but they didn’t want to abandon the autonomy teams enjoyed.

“The API manifests are decentralized. They can be anywhere,” Shaw explained. “The pipeline is centralized. We have full control over it. You have to deploy it through us. And we set all of the guardrails.”

The key mechanic behind those guardrails is tagging based on GitHub OIDC tokens.

Every GitHub runner that starts a deployment comes with an OIDC token. When decoded, it contains:

• the actor (who triggered the workflow)
• the branch (e.g., enforcing that production deployments only come from main)
• the repository (which “owns” a given API)
• the run ID

The deployment pipeline extracts and validates these claims, then automatically adds them as tags on the Kong entities being deployed — routes, services, and so on.

“We validate that it is an actual OIDC token from GitHub with the public signatures,” Shaw said. “And then we tag it. That’s enforced, and you can't bypass that.”

On every deployment, the pipelin does the following:

1. Performs a deck dump of all existing routes in Kong’s control plane
2. Compares them to the routes the developer wants to deploy
3. If it doesn’t find matching routes, it creates them
4. If it does find matching routes, it checks the ownership tags — only the repository that originally deployed a route is allowed to modify it

“If we see people trying to move their API to another repository, they can’t,” Shaw said. “They’ll get a tag mismatch and an error response.”

The result is a model where teams retain decentralized control of their OpenAPI specs and manifests in their own repos and the platform team centralizes the deployment pipeline and enforces governance, ownership, and security via tags and validation.

AI-assisted incident response with Vipty and MCP

Vipps MobilePay is also experimenting with AI to streamline incident response using MCP (Model Context Protocol) and a friendly AI mascot named Vipty.

By feeding the MCP server extra context — from Kong tags and the mapping between upstreams and Kubernetes namespaces — they’ve created a way for incident responders to ask natural-language questions like: “Give me all the APIs deployed to this namespace, who deployed them, when, and a link.”

The MCP server can respond with a table that includes hyperlinks directly to the relevant runs and APIs, helping responders quickly see what changed before an incident and who to contact.

“During incident response, we want to get our incident responders information quickly,” Shaw said. “So we’ve been testing giving a little bit of extra context to the MCP server.”

Today, this MCP server is admin-only; the team is still exploring how to handle authentication and how Kong’s AI plugins might play a role. But it’s a clear glimpse of how Kong’s metadata and tagging model can feed intelligent tooling.

Migrating from Azure APIM to Kong has reshaped Vipps MobilePay’s API landscape across performance, governance, and culture.

“Don’t underestimate the complexity of your systems," Hannestad said. "If you’re going to do what we did, which comes with a decentralized approach, then please allow extra time.”
89% faster scale-ups for peak payments

By running Kong in Kubernetes and aligning scaling with the platform’s existing patterns, Vipps MobilePay reduced scale-up times by 89%. With pre-warmed nodes, the team expects this to become even faster, better matching those one-hour windows where 40% of daily traffic hits the platform.

100% migration, with safety at every step

The canary proxy approach allowed Vipps MobilePay to:

• Move APIs gradually, one by one
• Keep a hard rollback path to APIM during high-risk periods
• Focus first on high-volume APIs to quickly reduce APIM costs

Today, all environments run entirely on Kong, and APIM has been completely decommissioned.

Stronger governance without losing speed

The centralized deployment pipeline with OIDC-based tagging has delivered a governance model that feels natural to both platform and product teams.

• Ownership is enforced by tags. Only the repository that originally deployed a given route can modify it. Attempts to move or hijack an API configuration result in tag mismatch errors.
• Production safety is baked in. Only commits from main can deploy to production, enforced at the OIDC token level.
• Auditability and traceability improve. Every API entity in Kong carries tags that link it back to who deployed it, when, and from which repository and run.

It’s governance as a guardrail — not a gate — mirroring the company’s “keep it simple” and trust-based values.

For now, Vipps MobilePay has achieved what many payment providers aspire to: a unified, cloud native API gateway layer that scales with demand, respects team autonomy, and embeds governance directly into the tools developers already use.