# I launched Payment Stack Guide: choose how to get paid > I launched Payment Stack Guide, an evidence-led guide to Merchant of Record and direct payment providers, with comparisons and decision tools. Author: [Flavio Copes](https://flaviocopes.com/about/) | Published: 2026-07-29 | Topics: [News](https://flaviocopes.com/tags/news/) | Canonical: https://flaviocopes.com/paymentprocessor/ Today I launched [Payment Stack Guide](https://paymentprocessor.dev). It helps you choose how to get paid online. The site starts with the decision most payment comparisons skip: **Will another company be the legal seller, or will you remain the merchant?** That choice affects much more than the transaction fee. It changes who handles sales tax and VAT, disputes, fraud, invoices, billing support, payouts, and the customer relationship. Payment Stack Guide makes those responsibilities visible before comparing providers. ## Why I built it Every product eventually needs a checkout. During this Summer of Code I built several products, paid reports, courses, and tools. I kept returning to the same questions. Should I use Paddle or Polar? Should I use Stripe directly? Is a Merchant of Record worth the higher fee? Can this provider onboard a business in my country? What will happen to existing subscriptions if I switch later? The usual comparison starts with a table of prices and features. That is not enough. A direct payment provider can have a lower fee because it does a smaller job. You remain the seller. Tax registration, filing, disputes, billing operations, accounting, and compliance can still be yours. A Merchant of Record can take on more of that work, but it becomes the seller to the buyer. That can mean higher fees, product restrictions, less control, different payout timing, and more dependence on one provider. Neither model is always better. The right answer depends on the business, the product, the countries involved, and the work you want to operate yourself. I wanted one place that explains that decision clearly, with sources and real numbers. ## What is in the guide The launch version has 16 provider profiles. Eight are Merchant of Record providers. Eight let you remain the merchant. The profiles include Paddle, Polar, Lemon Squeezy, Gumroad, FastSpring, Stripe Managed Payments, Stripe Payments, PayPal Checkout, Adyen, Mollie, Square, Braintree, and others. Each profile covers: - who is the legal seller - seller and buyer country coverage - supported products and business models - checkout, subscriptions, invoicing, and payment methods - public or negotiated pricing - payouts and reserves - which responsibilities belong to the provider, the merchant, or both - strengths, limitations, and situations where it may not fit - dated sources and the next review date There are also 13 practical guides. They explain topics like the online payment lifecycle, payment fee anatomy, sales tax and VAT with direct payments, refunds and chargebacks, subscription operations, payout timing, and payment provider portability. Four direct comparisons cover the pairs I think are most useful at launch: - Paddle vs Polar - Paddle vs Stripe Payments - Stripe Payments vs Stripe Managed Payments - Stripe Payments vs PayPal Checkout The comparisons do not declare one universal winner. They describe the scenario where each option makes sense. ## The decision tools I built four browser tools around the research. The [provider matcher](https://paymentprocessor.dev/tools/provider-matcher/) creates a shortlist from your product, company stage, preferred responsibility model, and priorities. The [country checker](https://paymentprocessor.dev/tools/country-checker/) separates seller onboarding from buyer coverage. These are often mixed together, but they answer different questions. The [effective cost calculator](https://paymentprocessor.dev/tools/effective-cost/) compares documented public formulas using the same revenue and transaction assumptions. It includes international cards, currency conversion, subscriptions, disputes, plan fees, and operating costs. If a provider only offers negotiated or contradictory pricing, the calculator does not invent an exact number. The [migration decision tool](https://paymentprocessor.dev/tools/migration-decision/) helps answer a different question: is switching worth it? It combines the new quote, current costs, migration work, payout delays, reserves, payment method portability, subscription imports, and customers who may need to enter their payment details again. You can save the report in your browser or share it through the URL. There is no account and no database receiving the numbers you enter. ## How I built it Payment Stack Guide is a static Astro site. The provider profiles, comparisons, guides, company records, field stories, migration links, country coverage, and calculator formulas live in structured JSON files. A provider record has one shared shape: ```js { slug: 'paddle', name: 'Paddle', model: 'merchant-of-record', legalSeller: 'provider', pricing: {}, responsibilities: [], lastReviewed: '2026-07-27', nextReview: '2026-10-27', sources: [], } ``` Astro content collections load the files. Zod validates their structure during the build. That validation also checks the meaning of the data. A Merchant of Record cannot be marked as leaving the merchant as the legal seller. Every pricing source must exist in the profile. Review dates must be current. Contradictory or negotiated pricing cannot expose a fake exact formula. At launch, the validator checks 16 providers, 15 company records, 4 comparisons, 13 guides, 15 field stories, 13 fee formulas, 30 migration routes, 12 country scenarios, and 42 dated provider sources. Alpine.js runs the interactive tools in the browser. The calculator logic is made of small JavaScript functions. Plain CSS handles the design. There is no server-rendered application, account system, or database. The production build validates the research, generates the static pages, then audits headings, canonical URLs, structured data, internal links, responsive tables, the sitemap, and color contrast. The difficult part was not generating the pages. It was defining what the site is allowed to claim. Payment providers change prices, country support, product rules, and terms. A polished page can become wrong quickly. Every important claim needs a source, a review date, and a visible limit. ## Connected to migratingto.dev Choosing a provider is only half the problem. Leaving one can be harder than joining it. Payment Stack Guide explains the provider and the decision. [migratingto.dev](https://migratingto.dev) contains the detailed migration playbooks. The two sites connect through 30 routes between Paddle, Polar, FastSpring, Gumroad, Stripe Billing, and Stripe Managed Payments. I kept them separate on purpose. One site helps you choose. The other helps you move. ## The Summer of Code continues Earlier this week I launched [Calculum](https://flaviocopes.com/calculum/). Then came [migratingto.dev](https://flaviocopes.com/migratingto/), [Disaster Lab](https://flaviocopes.com/disasterlab/), and now Payment Stack Guide. Four public launches in four days. They look like different products, but they follow the same idea. Take a difficult decision. Make the assumptions visible. Turn the result into something practical. Use AI agents to increase the output, then use schemas, sources, tests, and review to keep that output under control. This is the part of the Summer of Code I enjoy most. An idea can become a real product quickly. Then I can use it, remove what does not work, and decide if it deserves to exist. The Summer of Code is still in full swing. ## Try it Start at [paymentprocessor.dev](https://paymentprocessor.dev). If you do not know which model fits, begin with [who should be the legal seller?](https://paymentprocessor.dev/start/). If you already have a shortlist, put your real numbers into the [effective cost calculator](https://paymentprocessor.dev/tools/effective-cost/). The site is free. If a claim is wrong, a source is stale, or an important provider is missing, let me know.