Mews: Hospitality, payments, and durability on a global scale

Mews is a hospitality cloud platform serving 15,000+ customers, managing 350,000+ hospitality spaces worldwide, processing billions in annualized payment volume, and managing 16 million check-ins per year. When your platform handles this kind of enormous volume of guest stays and financial transactions, reliability and scalability are everyday critical concerns.

For Petr Koutny, Staff Software Engineer focused on backend reliability and payments at Mews, a fundamental problem needed solving: how do you orchestrate complex, long-running Workflows across payments, refunds, chargebacks, and onboarding without losing state, duplicating money movement, or requiring constant manual intervention?

Hint: the answer was Temporal.

The challenge: Homegrown solutions at breaking point

Before Temporal, Mews relied on a typical mix of custom solutions. They included custom job frameworks, event-driven flows over Kafka and Azure Service Bus, and ad-hoc state machines in the database.

For simple tasks, this worked. But Mews also needed genuinely long-running, cross-service Workflows for operations like payments automation, KYC onboarding, complex refunds, and chargeback lifecycles. The team found themselves constantly scrambling to solve each new use case.

“We had to reinvent durability, retries, and state recovery each time,” Petr explains. “Error handling and observability were inconsistent, and answering ‘what is the current state of this business process?’ often meant grepping logs or querying multiple systems.”

As a result, the pain points became impossible to ignore.

Unpredictable bill closing times: Large bills with thousands of line items could take highly variable amounts of time to close, blocking the entire payments automation flow and making performance nearly impossible to observe or tune
Unclear exception handling and retries: Custom retry logic was scattered across services, and it wasn’t always clear which exceptions were retriable versus fatal, especially when dealing with external payment providers
Lost or stuck processes: Long-lived Workflows spanning multiple events and services risked losing state during deployments or outages, with no easy recovery path

For Mews, “mission-critical” means anything touching money, guest stays, or audit trails. Failures in these areas could easily result in lost revenue, duplicate charges, or regulatory issues. This approach wasn’t sustainable, so they decided to try Temporal.

Why Temporal: orchestration over messaging

Petr had first heard of Temporal through blog posts, conference talks, and its growing customer list. What made it stand out for the Mews team was the alignment between Temporal’s model and the problems they were facing.

Code-first Workflows: Temporal’s programming model matched how the team approached their work, creating Workflows and Activities as code rather than a proprietary DSL
Durable Execution by default: The promise of “write business logic, let Temporal handle retries, state, and restarts” was exactly what the team needed for payments automation
Temporal Cloud: A managed service with strong SLAs meant no need to stand up and babysit their own Temporal cluster

At the end of the day, Petr and his team went with Temporal because it’s better than other solutions for orchestrating business processes. Queues are great at delivering messages, but Mews needed their mission-critical Workflows to be failure-proof.

Building on Temporal: from bill closing to fintech foundations

Mews started with a single, high-impact use case: bill closing as part of payments automation. By moving bill closing into an independent Temporal Workflow, the main automation flow no longer had to block on variable-length processing. Today, Temporal reliably closes around 6,000 bills per day for Mews.

From there, adoption grew rapidly. Today, Mews runs thousands of payment-related Workflows daily across multiple Temporal Cloud Namespaces.

Webhook processing

To process billions of payments, Mews utilizes third-party webhook events, which are handled via Temporal Workflows, including parallel side effects to Kafka and core business logic. When a Kafka outage once stalled thousands of these Workflows, Temporal automatically resumed them when Kafka recovered, meaning no manual cleanup required. The team used Temporal’s patching API and replay tests to evolve the Workflow design without breaking in-flight executions.

Integration flows

Mews chose Temporal over a pure commands-and-events design for end-to-end payment capture, bridging a third-party monolith and a new payments service. Additional integrated Workflows include:

Partial refunds: A dedicated Workflow retries refunds on a schedule until the underlying transaction settles or a cutoff is reached, then notifies the monolith
Chargeback/dispute lifecycles: Long-running Workflows signaled by Braintree webhooks coordinate chargeback creation, outcomes (won/lost), and corresponding accounting actions

Long-running onboarding and KYC

Onboarding Workflows can span days or weeks, with many webhook events for the same logical entity. Temporal maintains state across that entire lifecycle without custom “keep alive” logic or polling, despite crashes, deployments, and infrastructure changes.

Job scheduler tasks

Some periodic jobs now run via Temporal in the job-scheduler service, benefiting from the same durability and visibility guarantees as payment Workflows.

The results

Since adopting Temporal, Mews has seen measurable improvements across reliability, performance, and engineering velocity.

Faster payments automation: By isolating bill closing into an independent Temporal Workflow, automatic payments no longer block on variable processing times, reducing overall end-to-end latency
6,000 bills closed per day via Temporal: Enabled by much stronger observability into durations and error patterns
Reduced operations work after incidents: During a Kafka outage incident, Temporal automatically resumed thousands of stalled Workflows when Kafka came back online. The team gets to focus on preventing future issues instead of on manual cleanup.
Safer iterative delivery: Patching and replay tests allow the team to evolve sensitive payment Workflows with reduced risk of incidents

Petr adds, “Some of the benefits, like fewer edge-case incidents or support escalations around stuck payments, are qualitative but very noticeable in day-to-day operations.”

The takeaway

With Temporal in place, Petr and his team are now comfortable building Workflows they previously would have avoided due to high orchestration risk.

Sophisticated refund and dispute handling: Partial refunds that depend on transaction settlement and long-running chargeback lifecycles with multiple state changes are now doable with Temporal Workflows and Signals
End-to-end onboarding flows: A single Workflow per connection to third-party providers that lasts weeks, aggregates many webhooks, and exposes live status without building custom state engines
Chained funds-movement flows: Multi-step payout or reconciliation scenarios can be modeled as a single Workflow with clear Activities and compensation strategies

“In the past, we might have tried to approximate these with a tangle of jobs and events and then under-scope the feature to reduce risk,” Petr says. “With Temporal in place, those designs feel much more realistic.”

When asked what would break first if Temporal disappeared, Petr’s answer is immediate: payments.

“We’d lose the Workflows that currently close thousands of bills per day reliably. Hotels would start seeing stuck or delayed automations, and we’d have to scramble to rebuild that orchestration.

“Webhook processing, integration flows, refunds, chargebacks, payouts: these would all degrade quickly, forcing manual intervention. We’d still have our queues and job frameworks, so nothing is literally impossible to rebuild.

“But we’d lose durability guarantees, Workflow visibility, and a lot of carefully encoded retry semantics overnight, which, in a payments-heavy environment, is not something I’d ever want to experience.”

The future

Mews recently raised a $300 million Series D funding round, cementing them as the world’s top hospitality operating system. The funding round expands Mews’ significant investments in AI, embedding agent-driven systems across the platform to automate complex Workflows, reduce cognitive load for staff, and improve guest experiences. We’re excited to see what the team does next and how Temporal can support them to achieve even more!

About Mews

Mews is a hospitality cloud platform providing a modern PMS, embedded payments, POS, and integration marketplace that powers 15,000+ customers and over 350,000 hospitality spaces worldwide.

Industry: Hospitality Technology

Deployment: Temporal Cloud

SDK: .NET