Payments in the product: a design guide to embedding checkout, onboarding and reporting

Most ISVs decide to embed payments and then bolt them on where the interface happens to have room. This guide shows where payments belongs in your product, from signup to the monthly reconciliation view.

Most ISVs decide to embed payments and then bolt them on where the interface happens to have room. This guide shows where payments belongs in your product, from signup to the monthly reconciliation view.

A settings page gets a "Payments" tab, onboarding becomes a link to someone else's form, and reporting lands on a page nobody opens. Attach rate comes in low, and the conversation turns to sales incentives.

Attach rate is a product decision. This guide walks through the interface choices in the order a merchant meets them: onboarding inside your signup flow, checkout and card on file, stored credentials and recurring billing, payouts and reconciliation, and the reporting surface that turns transaction data into decisions. Each section ends with three questions to settle before anyone designs a screen, and the paper closes with a build checklist mapped to Accept, Secure, Manage and Grow.

The patterns are illustrative. We have attached no conversion rates or activation times, because those depend on your vertical and your merchants. What we do say plainly is where each piece of payments belongs, and what a managed PayFac model takes off your engineering roadmap so your team can build it.

It pairs with our buyer's checklist for choosing an embedded payments partner: that one helps you choose, this one shows what to build once you have.

Get the full report