Skip to main content
← Back

WasmPay Demo: The Wasm Component Model for Cross-Language Payments

The April 2, 2025 wasmCloud community call streams live from the wasmCloud booth in the CNCF Project Pavilion at KubeCon + CloudNativeCon Europe 2025 in London. Brooks walks through the team's conference schedule — including talks on wasmCloud's road to the standards, SPIFFE workload identity, and WebAssembly on Kubernetes — and then demos WasmPay, a cross-language, cross-country payment processing platform. WasmPay shows the Wasm component model at work: banks supply transaction validators written in any language that compiles to WebAssembly, and wasmCloud composes each untrusted validator with a "platform harness" component that handles HTTP, NATS messaging, and the validation contract.

Key Takeaways​

  • WasmPay is a cross-border payments demo built to show what it feels like to build a platform with wasmCloud — the pattern most teams actually follow when they deploy real applications: stand up a platform, then run components on top of it
  • The application combines a Go API gateway (the HTTP front door for the UI), a Rust transaction manager compiled to WebAssembly for baseline validation, and per-bank validators that can be written in any language that compiles to Wasm
  • Each bank ships its own untrusted validator implementing a shared validate interface; because it satisfies that typed contract, wasmCloud can run completely untrusted code safely — a direct illustration of the Wasm component model
  • The platform harness pattern wraps each validator with a separate component that exports the HTTP server, wasmCloud messaging, and a pass-through validate function — letting the platform own serialization, schema migration, and message replies while the bank only writes business logic
  • The demo showed live validation: a US bank (North Haven) approved a US-dollar transfer but rejected a request in British pounds because its component only approves USD; a European bank validator written in TinyGo enforced its own non-zero, US-to-UK rules
  • On scale, the team ran 10,000 unique validators on a single wasmCloud host on a laptop and captured resource-utilization metrics to dig into later
  • A deeper WasmPay walkthrough — with live Q&A — is planned for an upcoming community call after the team returns from KubeCon

Chapters​

Meeting Notes​

Live From KubeCon + CloudNativeCon Europe 2025​

The call came straight from the wasmCloud booth in the CNCF Project Pavilion in London, with Florian and a growing roster of wasmCloud maintainers and contributors on hand in person. Taylor was at the CNCF TAG Runtime booth down the row, with other folks rotating through the Cosmonic booth. Rather than a full agenda, Brooks pointed everyone at the KubeCon EU 2025 blog post listing where the team was speaking, and noted that CNCF publishes session recordings to YouTube a couple of weeks after the event.

The remaining talks at the show:

  • wasmCloud and the road to the standards — a look back at the project's history leading up to the wasmCloud 1.0 release the prior year.
  • SPIFFE and workload identity for Wasm workloads — Joonas (Cosmonic) and Colin Murphy (Adobe org maintainer) on bringing SPIFFE-based workload identity to wasmCloud.
  • WebAssembly and Kubernetes — Liam Randall on the maintenance implications of running Wasm on Kubernetes and why a project like wasmCloud exists.

Demo: WasmPay — A Cross-Language Payments Platform​

The centerpiece was WasmPay, the demo running at the wasmCloud and Cosmonic booths all week. The goal was to show the process of building a platform with wasmCloud, because that's what most teams do in practice: build a platform, then deploy applications that draw on a variety of capabilities. WasmPay is a cross-language, cross-country payment processing platform that facilitates sending money between banks — a domain chosen because it's high-security and obviously polyglot, not because the team set out to reinvent payments. The interesting part is how it uses WebAssembly.

WasmPay Architecture​

  • A front end talks to an API gateway written in Go, the HTTP front door for everything coming from the UI.
  • When a transaction occurs between two banks, a transaction manager written in Rust and compiled to WebAssembly does baseline validation.
  • Every bank has its own customer rules, regulations, and country-specific requirements, so WasmPay lets each bank supply its own validator written in any language that compiles to WebAssembly. As long as it satisfies the validate interface, wasmCloud can deploy that completely untrusted code.
  • Each validator is composed with a separate component that implements the HTTP server, NATS messaging, and a pass-through layer — the platform harness. When a transaction passes validation, the result can be stored in a legacy banking database (the point where you'd normally reach out to an external payments API).

Demo Walkthrough​

Running locally, Brooks logged in as a member of North Haven Financial (a US bank) and sent $50 to a European bank — that cleared and the account balance updated. Requesting money in British pounds, however, failed validation: North Haven's validator only approves US dollars and rejects unsupported currencies with a returned reason. The European bank — implemented in TinyGo — uses the same interface to ensure transactions are non-zero and that the transfer occurs between the USA and Great Britain. The interface a bank sees is deliberately simple: it gets the transaction's origin, destination, currency, and country, and returns a validation response. (An LLM sits behind the scenes for niceties like translation and currency conversion.)

The Platform Harness Pattern​

Under the hood, the validator component exports the WASI HTTP server, wasmCloud messaging, and the validate function — but it's composed with every bank's validator so the platform can call the underlying validate and handle the surrounding concerns: serialization and deserialization, schema migration, replying to a message bus, and more. The validator code stays focused on business logic; the harness owns everything else. The code is published on the Cosmonic Labs side for anyone who wants to explore it.

Scale and What's Next​

On scale, the team ran 10,000 unique validators on a single wasmCloud host on a local machine and captured resource-utilization screenshots to study after the conference. Asked in chat about exotic languages, Brooks noted a Fortran validator should be possible (and promised to check whether COBOL can compile to Wasm) — underscoring the "any language that targets WebAssembly" point. A more in-depth WasmPay demo, with live Q&A, is planned for an upcoming community call after KubeCon.

WebAssembly News and Updates​

This week's "news" was the conference itself: wasmCloud was live at KubeCon + CloudNativeCon Europe 2025 in London with maintainers in the CNCF Project Pavilion and sessions across the WebAssembly track. The lineup spanned the project's road to the standards and wasmCloud 1.0, SPIFFE-based workload identity for Wasm, and WebAssembly on Kubernetes. Liam Randall also appeared live on the Cloud Native FM podcast during the show to discuss the platform-engineering shift WebAssembly is driving. Session recordings are published by CNCF to YouTube in the weeks following the event — full details and links are in the KubeCon EU 2025 blog post.

What is wasmCloud?​

wasmCloud is a CNCF project that lets you build applications using WebAssembly components and deploy them anywhere — cloud, edge, or Kubernetes clusters. It uses the WebAssembly component model to let you write business logic in any supported language (Rust, Go, Python, TypeScript, C#, and more) while the platform handles capabilities like HTTP, messaging, and key-value storage through a pluggable provider architecture. wasmCloud's reference host is built on Wasmtime, and it uses NATS for transport and OCI registries for distribution. With built-in OpenTelemetry observability and Kubernetes integration, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: The Wasm Component Model​

WasmPay is a concrete, end-to-end illustration of the Wasm component model. The whole platform hinges on a single idea: a bank's validator is just a WebAssembly component that satisfies a typed validate interface. Because the contract is the interface — not the language, not the binary's internals — North Haven's USD-only logic can be authored in one language while the European bank's rules are written in TinyGo, and wasmCloud can run both as completely untrusted code without trusting their internals.

The platform harness pattern then leans on composition, the component model's superpower. Instead of every validator re-implementing HTTP serving, NATS messaging, serialization, and schema handling, those concerns live in a separate component that is composed around each validator. The composed unit exports the WASI HTTP server and wasmCloud messaging while internally calling the bank's validate function. This is "composition without trust escalation": you assemble a working service from independently authored, independently sandboxed parts that interoperate through interfaces. Running 10,000 such validators on a single host — the kind of density that's impractical with one container per validator — is what that model unlocks. For a primer on the broader runtime, see the runtime overview and the guide to building custom hosts.

Who Should Watch This​

This call is especially valuable for platform engineers designing internal platforms where teams ship business logic without owning the surrounding plumbing (the platform harness pattern starting around 9:30), polyglot teams that need Rust, Go/TinyGo, and other languages to interoperate safely through one contract (the validator design at 5:40), and anyone evaluating WebAssembly versus containers for high-density, multi-tenant workloads (the 10,000-validator scale note at 10:40).

Up Next​

The team planned a more in-depth WasmPay walkthrough — with live Q&A — in an upcoming community call after returning from KubeCon, including a closer look at the early scale metrics from running 10,000 validators on a single host. Watch this space for the CNCF session recordings (wasmCloud and the standards, SPIFFE workload identity, and WebAssembly on Kubernetes) as they're published to YouTube, plus WASM I/O and KubeCon recording links.

Get Involved​

wasmCloud is a CNCF project and contributions are welcome. Join the community:

Full Transcript​

Read the complete transcript with speaker labels and timestamps:

Read the full transcript →