Building payment infrastructure that lets customers buy wherever they want—starting with BNPL, extending to any channel.
Q1 2020. Executive mandate: fast-track a Buy Now, Pay Later provider to acquire younger customers and increase average order value. The business case projected $22M-$80M in incremental sales. Competitive pressure was real—BNPL was becoming table stakes in beauty retail.
This wasn't an isolated request—it was the first of several incoming commerce integrations. The architecture we chose for this first integration would set the velocity for the entire roadmap.
I spent five weeks in discovery before we wrote a line of code. That investment surfaced a critical architecture decision with major trade-offs.
| Approach | Direct Integration | Virtual Card Network (VCN) |
|---|---|---|
| Implementation | Direct API to Klarna backend | VCN tokenizes BNPL as credit card |
| Processing Fee | Lower (custom negotiated) | Higher (standard interchange) |
| Integration Time | 8—12 weeks per provider | 3—5 weeks after first |
| Reusability | None—each provider is custom | High—any VCN provider uses same rails |
| Risk Containment | Mixed with core payment stack | Isolated—failure doesn't affect credit cards |
The VCN trade-off was explicit: We accepted higher per-transaction costs in exchange for modularity and speed. The bet was that velocity would outweigh margin on a per-integration basis.
Four teams had concerns. Each concern was valid. The product work was designing around them—not dismissing them.
Concern: BIN-level controls wouldn't be ready by launch.
Resolution: Launched without BIN-level controls, added them in Phase 2. Accepted the limitation rather than delaying.
Concern: Resisted adding integration points to the payment stack.
Resolution: Structured the integration to contain risk—a VCN failure would only impact the new payment method, not core credit card flows.
Concern: Hesitant about SDK incorporation risk.
Resolution: Decoupled launches—web first, apps only after web proved stable.
The discovery investment paid off. By the time we assembled the team, we had clarity on architecture (VCN), scope (no loyalty integration), and rollout strategy (web first, decoupled apps). The 5-week execution sprint was possible because we'd done the work upfront.
Discovery: Architecture decision, stakeholder alignment, scope definition
Execution: Just 2.5 sprints from team formation to deployment
| Phase | Timeline |
|---|---|
| Klarna US (Web) | 10 weeks (5 discovery + 5 execution) |
| Klarna US (Mobile) | 3—5 weeks |
| Instacart | 3—5 weeks |
| Paybright, Klarna CA | Varied (external dependencies) |
| Google Shopping, IG Shopping | Subsequent launches |
| AfterPay, Shipt | Subsequent quarters |
US Web went first—highest traffic for fastest learning, simplest integration surface. We ran a 50/50 A/B test for 7 days, saw no major issues, and ramped to full rollout.
Unit economics: The AOV lift offset the higher VCN processing fees, preserving contribution margin despite the higher cost-of-payment. The margin-for-velocity trade-off paid off.
The first integration took 10 weeks end-to-end (5 weeks discovery, 5 weeks execution). Subsequent integrations took 3—5 weeks depending on complexity—cutting delivery time by 50—70% by reusing the infrastructure we'd built. Other integrations varied based on external dependencies (Canadian treasury approvals, partner readiness), but all ran on the same foundation.
By the time we launched Google Shopping and IG Shopping, integrations that would have required dedicated backend work ran on existing infrastructure, requiring configuration rather than new backend development.
The brief was "add a payment option." The outcome was omnichannel commerce infrastructure.
The VCN approach and reusable patterns weren't the fastest path to "Klarna live." They were the path that cut subsequent integration time by 50—70% (from 10 weeks to 3—5). Every decision that prioritized modularity over speed paid dividends on the next integration.
Higher processing fees, postponed BIN upgrades, decoupled app launches—each was a trade I had to defend. The job isn't avoiding trade-offs. It's making them explicitly and owning the outcome.
The teams that pushed back weren't obstructing—they were pattern-matching against past failures. The commerce backend team's concern about integration risk led directly to the risk containment approach that made the architecture defensible. Their resistance improved the solution.
The ask was a BNPL integration. The diagnosis revealed a pattern: this was the first of many commerce integrations, and the architecture we chose would either accelerate or constrain every one that followed.
The bet was building reusable payment infrastructure instead of a one-off Klarna integration. The VCN approach traded higher processing fees for speed and modularity—a trade-off the 18% AOV lift validated.
The results: $18M+ in revenue from Klarna, 50—70% faster subsequent integrations, and a platform that enabled 3 BNPL providers, 4 marketplace channels, and international expansion on the same rails.
The brief was "add a payment option." The outcome was omnichannel commerce infrastructure that let us meet customers wherever they wanted to buy.