Moving Fast by Moving Slow: How We Built Payments at Ramp

Summary

Ramp describes why it delayed the launch of BillPay by about two months to replace its existing, ad hoc bank-transfer infrastructure with a new payments service. The earlier system encoded product-specific concepts such as employee bank accounts and reimbursement transfers, forcing each new use case to add bespoke data models, jobs, and scheduling logic. This friction became especially costly as the team anticipated additional payment products and vendor payments scheduled for future dates. The redesign used generic primitives—ACHDetails and TransferCanonical—to separate business logic from money-movement logic; it also treats failed transfers and retries as concerns requiring an auditable identity, history, and consistent provider mapping. The post argues that stress-testing assumptions, modeling relevant degrees of freedom, limiting conditional logic, and building platforms after recurring patterns can make future products faster to launch.

Context

Ramp’s existing payments infrastructure had been built piecemeal for debit checks, statement collections, and personal reimbursements. Its product-specific data models and jobs created repeated engineering work for new use cases, while BillPay introduced additional requirements such as vendor payments on scheduled future dates.

Approach / What changed

Ramp built a separate payments service around generic primitives, including ACHDetails for external bank accounts and TransferCanonical for transfers between Ramp-owned accounts and external counterparties. The design aimed to decouple business logic from money movement, preserve auditability across retries, support consistent provider identities, and account for future degrees of freedom such as currency.

Takeaways

• Product-specific payment models forced new use cases to add repeated tables, jobs, and scheduling logic for fundamentally similar money movements.
• ACHDetails and TransferCanonical provide a unified representation for external bank accounts and transfers across statement collections, debit checks, and reimbursements.
• The post recommends building a platform when a pattern has appeared twice, because maintaining duplicated logic can become more costly than supporting a third use case on shared infrastructure.

Related reading