From 12 Hours to 10 Minutes: Engineering Smallpdf’s Reactive Payment Frontend

A payment incident at Smallpdf lasted 12 hours, costing multiple 5 figures in revenue loss. With the reactive frontend architecture we built afterward, we estimate that the same scenario could be resolved in 10 minutes. This talk follows the engineering decisions behind that difference.

Payment flows become complicated quickly: gateways, regional requirements, compliance, experiments, retries, and partial failures all interact. Treating checkout as a linear sequence of steps makes those interactions difficult to change and recover when something goes wrong.

Through a production case study, we’ll explore how we used React’s reactivity to orchestrate payments through state changes and events. We’ll walk through the architecture, the trade-offs behind it, and how lazy loading, fallback strategies, and reactive orchestration work together to improve flexibility and platform stability.

Smallpdf was already global. This system helped us expand payment capabilities further, generate an additional 7 figures in revenue, respond to compliance requirements, and unlock opportunities faster with fewer incidents. We’ll revisit the original incident to explain what would make recovery faster today, then finish with a live demo of the system running in production.

You’ll leave with practical ways to apply reactive frontend architecture to complex workflows, reason about partial failures, and design for recovery. The examples use React, but the principles apply across modern frontend frameworks.