Should pricing be the same page for merchants and developers?

Yes, keep one pricing page as the single source of truth, but structure it so both can scan it. Merchants look for transaction fees and payout costs. Developers look for API limits, sandbox access and any per-call charges. Group the table by what the customer is doing, and link to it from both paths rather than maintaining two versions.

Do we need a separate developer portal from day one?

Not usually. Early on, a well-structured docs section with a quickstart, API reference and status link is enough. A full developer portal with dashboards, logs and key management can come later, often inside the product itself. What matters at launch is that a developer can make a first successful call quickly and find help when they get stuck.

How do we handle sales-led and self-serve merchants on one site?

Give both a route from the same pages. Self-serve merchants get a "Start now" button that leads to signup, while larger merchants get "Talk to sales" with a short form. State when sales makes sense, such as high volume or custom pricing, so smaller merchants don't wait for a call they don't need.

Should we show code on the home page?

A short, real code sample on the home page signals that the product is built for developers, and it works well if developers are a key buyer. Keep it brief and accurate, and pair it with a business-facing summary so merchants don't feel lost. If developers aren't central to your sale, move code to the developers page.

What proof matters most for a new payments startup?

Early on, the strongest proof is specific: named design partners or customers who agreed to be listed, the banks or processors you work with, a public status page, and clear payout terms. Investor names help too. Avoid generic claims like bank-grade security. Technical and finance buyers trust details they can check over adjectives.

All posts

Industries

Payments Company Website Design: Developer and Merchant Audiences on One Site

Payments company website design for two audiences: how to structure nav, pages and CTAs so merchants and developers both find their path, sized for a startup.

By Mehdi HassanOct 29, 20267 min read

The short answer

A payments company website should split early into two clear paths: merchants, who need pricing, payout timing, integrations and proof, and developers, who need docs, API reference, sandbox keys and status. Shared pages carry trust and compliance. Startups can borrow this dual-audience structure from large payments sites with far fewer pages, as long as each path ends in its own action.

Key takeaways

Merchants and developers ask different first questions. Give each a labeled path from the header.
Developers want docs, sandbox and status in one click. Merchants want pricing, payouts and integrations.
Shared trust pages, like security, licensing and partners, should serve both audiences in plain language.
A startup needs around six marketing pages plus docs, not the dozens a large payments company runs.
Each path needs its own CTA: "Get API keys" for builders, "Talk to sales" or "Start accepting payments" for merchants.

Part of Fintech Website Design: Building Trust Before the First Click

How should a payments company structure its website for merchants and developers?

A payments company should structure its website around two entry paths from the header: one for merchants and business buyers, and one for developers. Each path answers its own first questions and ends in its own action. Trust, security and licensing pages are shared, written so both audiences can read them.

Large payments companies such as Stripe have made this pattern familiar: product and solution pages for business buyers, and a prominent developers section leading to docs and API reference. A startup can't copy that scale, and doesn't need to. This guide shows how to keep the structure and cut the page count. For trust patterns across fintech, see our hub on fintech website design.

What do merchants and developers each need from a payments website design?

Merchants need to know what it costs, how fast they get paid, what it works with and whether businesses like theirs use it. Developers need to know how quickly they can make a first successful call, how good the docs are and whether the API is reliable. The same page rarely answers both well.

Question	Merchant	Developer
First thing they look for	Pricing and fees	Docs and quickstart
Proof they trust	Named customers, reviews, partners	Clear docs, SDKs, changelog, status page
Integration question	Does it work with my platform?	Which languages and SDKs exist?
Risk question	Payout timing, chargebacks, reserves	Uptime, rate limits, webhooks
Primary CTA	Start accepting payments or talk to sales	Get API keys or read the docs
Who signs off	Owner, finance or ops lead	Engineering lead

In many B2B deals both audiences are involved. A finance lead picks the provider and an engineer has to approve the integration. Your site has to let each of them check their part without wading through the other's content.

The navigation should name both audiences directly, usually with a Products or Solutions menu for merchants, a Developers link that goes straight to docs, and Pricing as a top-level item. Hiding the developer path inside Resources is the most common mistake on startup payments sites.

Products: what you sell, such as online payments, payouts, invoicing or cards, one line each.
Solutions: by business type or platform, only if you genuinely serve several.
Developers: docs, API reference, SDKs, status page and changelog in one menu.
Pricing: a top-level link with your full fee table.
Header actions: "Sign in" plus a primary CTA, with "Get API keys" or "Contact sales" as the secondary.

Which pages does a startup payments website need?

A startup payments website needs about six marketing pages plus documentation: home, product, pricing, developers, security and compliance, and about or contact. Add solution pages only when you have real customers in each segment to show.

Home: one sentence on what you do and for whom, then a split into merchant and developer paths.
Product: how payments, payouts and reporting work, with real interface screenshots.
Pricing: every fee in a plain table. Our fintech pricing page guide covers the patterns.
Developers: quickstart, a code sample, SDK list, sandbox access and a status link.
Security and compliance: PCI scope, licensing or partner relationships, and data handling in plain words.
About and contact: who you are, who backs you and how to reach sales or support.

The developer page can borrow heavily from developer-tool sites. Our guide to API company website design covers getting a developer to their first successful call, which is the moment that matters most.

A hypothetical page map for a seed-stage payouts startup

For example, suppose a startup offers payouts to contractors through an API. Its home page leads with "Pay contractors in any country from one API," then splits into two cards: "For finance teams" and "For developers."

The finance path covers payout timing, supported countries, fees and a demo request. The developer path goes to a quickstart with a copyable request, sandbox keys after signup and a status page. Security, licensing and partner-bank information live on one shared page that both paths link to. That's six pages, plus docs, and both buyers find what they need.

How do you show trust and compliance on a payments site?

You show trust on a payments site by stating plainly who you are, who you partner with to move money, what security standards you meet and how merchants get support. Merchants worry about payouts and chargebacks. Developers worry about reliability. Compliance pages should answer both in plain language.

State your regulatory position
Say whether you're licensed directly or work through partner banks or processors, in language counsel approves.
Explain PCI scope
Tell merchants what they're responsible for and what you handle, without implying certifications you don't hold.
Publish a status page
A public status page with incident history is strong proof for developers and ops teams.
Show payout terms
Payout timing and any reserves are trust questions. Put them on pricing and product pages, not only in the terms.
Use real proof
Named customers and partner logos only with permission. Our guide to fintech website compliance covers disclosure placement.

Should a payments company build its site in Next.js or a visual builder?

A payments company should usually build in Next.js if docs, status, code samples and the marketing site need to feel like one product, and choose a visual builder if marketing needs to ship pages without engineering help. Both can work. The deciding factor is who maintains the site after launch.

Pros

Next.js keeps marketing pages, docs and code samples in one codebase
Fine control over performance, security headers and analytics
Easy to embed live API examples or calculators
Fits teams where engineers already own the web stack

Cons

Marketing may need a developer for layout changes without a good CMS
Initial setup takes more engineering than a visual builder
Requires a clear owner for updates after launch
Visual builders can be faster for frequent campaign pages

If you're already on a builder and outgrowing it, our guide to Framer to Next.js migration cost explains what moving involves. For motion that helps explain money flows without slowing pages, see our guide to website animation.

Frequently asked questions

Should pricing be the same page for merchants and developers?: Yes, keep one pricing page as the single source of truth, but structure it so both can scan it. Merchants look for transaction fees and payout costs. Developers look for API limits, sandbox access and any per-call charges. Group the table by what the customer is doing, and link to it from both paths rather than maintaining two versions.
Do we need a separate developer portal from day one?: Not usually. Early on, a well-structured docs section with a quickstart, API reference and status link is enough. A full developer portal with dashboards, logs and key management can come later, often inside the product itself. What matters at launch is that a developer can make a first successful call quickly and find help when they get stuck.
How do we handle sales-led and self-serve merchants on one site?: Give both a route from the same pages. Self-serve merchants get a "Start now" button that leads to signup, while larger merchants get "Talk to sales" with a short form. State when sales makes sense, such as high volume or custom pricing, so smaller merchants don't wait for a call they don't need.
Should we show code on the home page?: A short, real code sample on the home page signals that the product is built for developers, and it works well if developers are a key buyer. Keep it brief and accurate, and pair it with a business-facing summary so merchants don't feel lost. If developers aren't central to your sale, move code to the developers page.
What proof matters most for a new payments startup?: Early on, the strongest proof is specific: named design partners or customers who agreed to be listed, the banks or processors you work with, a public status page, and clear payout terms. Investor names help too. Avoid generic claims like bank-grade security. Technical and finance buyers trust details they can check over adjectives.

Mehdi Hassan · CEO & Design Director

Copywriter, designer and developer, and founder of Designify Studio. Over five years, 60+ projects across 14+ industries, for startups that have raised $300M+.

Want this done for you? Website, $8,000.

A multi-page marketing site, written and designed by us, developed in Next.js and animated. $8,000, one-time, up to 6 pages. Book a free 30-minute call to see if it fits.

Schedule Call