Chapter 35 — If You're a Founder

Part IX: How to Use This Knowledge

Running scenario: Loop — a subscription software company that just crossed $2M in annual revenue. Priya is the founder.

Priya finds out about her payments problem the way most founders do: from her accountant, eighteen months too late.

The year-end review shows two numbers side by side. Payment processing fees: a little over 3% of revenue, once you add the currency conversion charges and the per-transaction fees nobody remembers agreeing to. Engineering time spent on payments that year: roughly two engineer-months — a webhook rewrite, a tax-invoice workaround, and a long, unpleasant week reconciling a payout that didn't match the dashboard.

Here's what stings. Loop's product margins are the envy of her peers, and yet one of her largest single vendors is a payment processor she picked in an afternoon, three years ago, because the docs looked nice. Nobody made a bad decision. Nobody made a decision at all.

That's the founder's payments problem in one sentence: payments is a strategic cost center that almost every founder treats as a checkbox. This chapter is the playbook for treating it like what it is — and just as importantly, for knowing what not to spend your attention on at each stage. If the operator's job (Chapter 36) is keeping the system healthy and the architect's job (Chapter 37) is designing it, the founder's job is simpler and harder: making the three or four payments decisions that are actually yours to make, at the moment they matter, and delegating everything else.

Stage One: First Sale — Choose Boring, Stay Out of Scope

At the first-sale stage, the correct payments strategy fits on an index card: one PSP, hosted checkout, and stay out of PCI scope.

Pick one well-documented, full-stack PSP for your market and integrate its hosted checkout or embedded fields — the integration models where card data goes straight from your customer's browser to the PSP and never touches your servers. As we saw in Chapter 24, that single choice is the difference between the shortest self-assessment questionnaire and a compliance program you are not staffed to run. Your integration choice is a compliance decision, and at this stage the right compliance posture is "as close to none as legally possible."

Don't negotiate pricing yet. Blended pricing — the flat 2.9%-and-something quote that made you wince in Chapter 10's interchange economics — is genuinely fine at low volume. What you're buying at this stage isn't a rate; it's speed, documentation, and the freedom to not think about payments while you find product-market fit. The negotiating leverage comes later, and it comes from data you aren't generating yet.

Two things are worth doing properly even now, because they're nearly free at the start and expensive to retrofit.

First, keep your own record of every transaction. Not a data warehouse — a table. Your internal order ID, the PSP's transaction ID, amount, state. The moment your product marks an order "paid," you should be able to say which PSP object made that true. Chapter 4 taught you that a payment is a four-stage lifecycle, not an event; your database should at minimum know which stage each payment is in. Founders who skip this meet it again during their first reconciliation break, their first dispute, and — most expensively — their first PSP migration.

Second, make the statement descriptor say your brand's name. It is a two-minute setting, and an unrecognizable descriptor quietly manufactures disputes from customers who don't remember you (Chapter 13 showed you where friendly fraud comes from).

What to ignore at this stage

Everything else, honestly — but four temptations deserve a specific warning, because they wear the costume of diligence.

Multi-PSP redundancy on day one. You will read a post about how serious companies never depend on a single processor. True — at a scale you have not reached. A second PSP doubles your integration surface, splits your transaction history, and buys you resilience against a failure mode that is rarer than the bugs you'll write implementing it. Chapter 31 explains when orchestration actually earns its keep; day one is not it.

Building a card vault. Storing card credentials yourself drags you into the deepest end of PCI scope (Chapter 25) to replicate something your PSP gives you for free. Use the PSP's vault and network tokens (Chapter 12).

Crypto and stablecoin rails. Part VII made the honest case for where these rails genuinely win — cross-border settlement, specific corridors, specific counterparties. If that's not your customer today, it's a distraction. Revisit when you have a concrete corridor problem, not before.

Building billing logic from scratch. Subscriptions feel like a weekend project — until proration, plan changes, failed-payment retries, and tax land on you at once (Chapter 17). Buy or use the PSP's billing product until its constraints genuinely block your pricing model.

Stage Two: Growth — The Money Is in the Failures

Somewhere past your first few thousand transactions a month, the payments opportunity changes shape. It's no longer about setting things up correctly; it's about recovering the revenue you're already losing quietly. Three leaks, in priority order.

Involuntary churn. For any subscription business this is the big one: customers who didn't cancel — their payment simply failed and nobody noticed. Expired cards, reissued cards, insufficient funds on renewal day. Chapter 15 gave you the full dunning playbook; the founder-level version is three questions for your team. Are we enrolled in the card networks' account-updater programs, so replaced cards refresh themselves? Do our retries follow decline semantics — soft declines retried intelligently, hard declines never — inside the network retry limits? And do we measure recovered revenue as a number a human reviews monthly? If the answers are "not sure," that's your highest-ROI payments project this quarter.

Authorization rate. You now have enough volume for the auth rate to be a KPI, sliced the way Chapter 36's scorecard slices it — by issuer, region, and payment method, never as one blended number. Two cheap, high-leverage fixes at this stage: descriptor and data hygiene (issuers approve merchants they recognize), and network tokens where your PSP supports them (Chapter 12 — richer credential data gives issuers confidence to approve). Tune 3DS deliberately rather than accepting defaults: challenge the risky slice, keep the rest frictionless, and watch conversion and fraud together, per Chapter 11.

The wrong rails for your geography. Growth usually means new markets, and Chapter 8's lesson bites here: payments do not globalize cleanly. If Dutch customers can't pay by iDEAL-style bank transfer, if Southeast Asian customers can't pay by QR or wallet (Chapters 18, 19 and 22), your "conversion problem" is actually a payment method problem, and no amount of checkout-button polish fixes it. Add local rails deliberately — one market at a time, measured — through your existing PSP where possible.

This is also the stage where pricing becomes negotiable. Once you're doing steady volume, ask your PSP to move you from blended pricing to interchange-plus, where you see the actual network costs and the PSP's margin as separate line items (Chapter 10). Even if you don't switch, the conversation itself is diagnostic: a provider who refuses to unbundle is telling you where their margin lives.

Stage Three: Scale — Own the Decisions, Then the Infrastructure

At scale — multiple markets, meaningful volume, a payments line item big enough that a 10-basis-point change is real money — the founder's job shifts again. The questions become architectural, and your role is not to answer them yourself but to make sure someone owns them.

Redundancy and routing finally earn their complexity budget. A second acquirer or PSP, an orchestration layer to route between them, retry and fallback logic that respects decline semantics — Chapters 31 and 32 are the blueprint, and Chapter 37 is what your engineering lead should be handed along with the mandate.

Your ledger, not the PSP's dashboard, becomes the system of record. The moment two processors both hold a slice of your transaction history, "look it up in the dashboard" stops being an answer. Chapter 37 calls this the architectural turning point, and it is: financial truth is something you own, with vendors as inputs.

Pricing becomes a portfolio negotiation. You now know your transaction mix — debit-heavy or credit-heavy, domestic or cross-border, card-present or not — and Chapter 10 told you what that mix costs the networks to serve. Walk into the renegotiation knowing what your traffic is worth. This, more than any tool, is where the book pays for itself.

Here is the whole arc as one decision tree — where you are on it tells you which chapters to hand to whom:

Diagram 1: The founder's payments arc. Each stage has a small number of decisions that are genuinely the founder's; everything between them is delegation. Skipping stages — orchestration before product-market fit, vault-building before volume — is the expensive failure mode.

What Breaks First

Every payments stack fails eventually, and at founder scale the failures are predictable enough to pre-empt. Three arrive earliest.

Webhooks and reconciliation. The first serious incident is almost never a card being wrongly charged — it's your system and the PSP's system disagreeing about what happened. A webhook was missed during a deploy; an order shipped unpaid, or a paid order never shipped. The vaccine is cheap: treat webhook handling as at-least-once (idempotent handlers, per Chapter 37), and reconcile your internal records against PSP payouts daily, even if "reconciliation" is a script and a Slack alert.

Involuntary churn — covered above, listed again deliberately. It breaks silently, which is why it breaks first.

Fraud and disputes, arriving suddenly. Card testers find every checkout eventually (Chapter 13, Chapter 26). One morning you'll see a thousand $1 authorizations from one BIN range. Velocity limits and bot controls on the checkout are a day of work before it happens and a very bad week after. And know the dispute thresholds — the card networks' monitoring programs (Chapter 36) don't care that you're small.

The Questions to Ask Any PSP Before You Sign

Vendor selection deserves its own table — not features, which every sales deck covers, but the questions the deck avoids. These come straight from the failure modes in Parts III through VI.

Table 1: The pre-signature questions. A provider who answers all seven crisply is telling you something; so is one who won't.

The Founder's Rule

If you remember one thing from this chapter: payments decisions are stage-gated, and the failure mode is doing the right thing at the wrong stage. Hosted checkout is wisdom at first sale and a constraint at scale. Orchestration is a distraction at first sale and table stakes at scale. The book you're holding is the map; your revenue curve is the clock.

And when the stack is chosen and the volume is flowing, someone has to keep the system honest every single day — reading the decline codes, chasing the missing $12,000, answering the card network's letters. That someone is the operator, and the next chapter is their field manual.

Sources

• PCI Security Standards Council — Self-Assessment Questionnaire (SAQ) types and eligibility criteria (integration model determines scope)
• Visa — Visa Account Updater program; retry and reattempt rules (credential reattempt limits)
• Mastercard — Automatic Billing Updater; transaction processing rules on reattempts
• Stripe and Adyen — public documentation on hosted checkout integration models, network token support, and settlement reporting granularity