How Early-Stage Startups Collect First Revenue Without a Custom Billing Stack

European seed teams hit the same week-three moment. A Berlin SaaS pilot wants to pay by card. A London B2B buyer asks for a numbered invoice with UK VAT. A contractor in Lisbon needs a SEPA transfer for last month’s work. Suddenly someone is building forms, tax fields, failed-payment emails, and a spreadsheet that tracks who settled. Cash that should fund the next hire sits uncleared while the team rebuilds rails specialists already run.

At seed stage the job is reliable collection, clear records, and money that reaches founders and freelancers on schedule. A custom billing engine can wait.

Buy Before You Build

Build when payments are the product. Marketplaces with complex split logic, usage products with unusual metering, or regulated institutions with bespoke ledger rules may need custom code early. Most B2B and B2C startups do not.

If pricing still changes weekly, paying accounts still number in the dozens, and one person still sends the invoice by hand, use a hosted checkout and invoice flow. Keep the customer relationship and pricing logic in the CRM or a shared board. Leave card storage, Strong Customer Authentication under PSD2, and settlement batching to a specialist. Revisit a build when volume, margin, or a unique pricing model makes platform fees larger than the engineering cost of owning the stack.

Teams that reverse this order often spend a quarter on Stripe Connect edge cases, then pause feature work to debug webhooks after midnight. That trade rarely beats shipping the product buyers already agreed to pay for.

What a Lean Setup Includes

A workable early setup usually has four pieces.

Shareable checkout. A payment link or hosted page for cards and, where relevant, local methods. The buyer completes the flow without the startup owning PCI scope.

Invoices that match the books. Sequential numbers, VAT or reverse-charge fields when selling across EU member states, and a status that flips when money clears. Google Docs PDFs work for the first few customers and break by the twenties.

Retries after failed cards. Soft declines often recover with a second attempt a day or two later. Without retries, a declined card becomes silent churn.

Payouts on a fixed cadence. Founders, contractors, and revenue-share partners need a schedule they can plan around. Money that leaves only when someone remembers to open the banking app creates support tickets that look like product bugs.

Until volume justifies owning webhooks and settlement logic, some European seed teams take first payments and send contractor payouts through Whop while pricing and customer records stay in the CRM. Keep the first version narrow. Prefer one primary currency, one pricing page, and one weekly reconciler.

Mistakes That Quietly Block Cash

Cards that fail with no follow-up. A hard decline should trigger a short email and a fresh link, not a closed ticket in the CRM.

Manual invoices as the only channel. They feel careful until someone forgets to send one, mistypes an amount, or loses the thread in a shared inbox. Cross-border EU sales make this worse when VAT treatment differs by buyer location.

Payouts tied to a founder’s calendar. Contractors in other time zones invoice late when settlement depends on whoever holds the bank login that week.

Settlement events that never reach ops. Celebrating ARR from a “paid” deal that never cleared is a common error. Wire settlement notifications into Slack or email before updating the board.

Wrong entity or messy VAT. Charging from the holding company instead of the trading entity, or collecting VAT without a process, creates cleanup that outlasts the pilot and slows the next diligence round.

When Custom Code Earns Its Place

Move toward a custom or heavily configured stack when three signals appear together. Pricing changes need engineering each time. Failed-payment recovery needs product-specific messaging. Finance wants ledger-level exports for audit. Until then, treat billing as infrastructure the company rents.

Startups that get paid cleanly in year one rarely win on clever billing code. They protect engineering time for the product, keep a human on exceptions, and replace manual steps only when volume makes the replacement obvious.