Decision map
Payments
Which seller, funds-flow, billing, tax, and payment-risk operating model should the product adopt?
Recommendation
Start with Payments
Product, finance, and platform teams defining direct or multi-party payment acceptance, recurring or metered billing, invoicing, transaction tax, and payment-risk responsibilities.
Scope
Use this boundary to avoid solving adjacent problems in the wrong layer.
Included
- Direct customer payment acceptance and operating-model selection
- Merchant-of-record responsibility as an independent high-consequence decision
- Subscription lifecycle, usage metering and rating, and invoice collection
- Marketplace connected-account, funds-flow, and payout design
- Transaction sales-tax and VAT automation
- Transaction and payment-abuse risk controls
Excluded
- Corporate income tax and legal or tax advice
- General bot, account, and application abuse prevention
- Identity proofing beyond its prerequisite role in connected-account onboarding
- Accounting ledgers and financial reporting outside payment and billing operations
Important tools
These tools represent distinct routes inside this decision area; open the relevant Task before treating any as a default.
Decision sequence
Make the foundational ownership decisions before adding specialized capabilities.
Who is the seller or Merchant of Record for the transaction?
Resolve the seller identity and responsibility model before comparing payment APIs or downstream billing capabilities.
Is this a direct merchant sale or a multi-party platform flow?
Connected accounts, routed funds, split payments, payouts, negative balances, and loss allocation activate the marketplace branch.
What commercial relationship produces the charge?
Separate one-time acceptance, subscription lifecycle, metered usage, and invoice collection before choosing implementation surfaces.
Which transaction-tax and payment-risk operations remain with the business?
Verify the selected seller and funds-flow model, jurisdiction, contract, eligibility, tax coverage, and risk controls rather than assuming coverage.
Decision groups
Each Task owns a distinct user decision rather than a product feature label.
Seller and funds-flow model
These Tasks determine the responsible seller, direct or multi-party flow, connected accounts, payouts, and allocation of transaction obligations.
Billing and collection lifecycle
These Tasks determine recurring relationship state, usage ingestion and rating, and invoice communication and collection.
Transaction tax and risk
These Tasks determine remaining transaction-tax operations and payment-specific abuse controls.
Common confusions
These boundaries prevent adjacent Tasks from collapsing into one generic shortlist.
- Merchant of Record is treated as only a payment-provider implementation route.
- Seller identity and transaction obligations materially alter tax, support, refund, dispute, payout, data, eligibility, and migration responsibilities.
- Subscription Billing and Usage-Based Billing are treated as the same lifecycle.
- Subscription Billing owns recurring commercial state; Usage-Based Billing adds event ingestion, aggregation, rating, and a usage source of truth.
- An invoice is treated as only an internal subscription artifact.
- Invoices can be created independently or by subscriptions and own itemization, delivery, status, and collection.
- Payment Fraud Prevention is treated as a general-purpose abuse and identity category.
- Payment Fraud Prevention acts on transaction and dispute risk; bot defense and identity proofing remain Security decisions.
What to defer
Do not add specialized identity systems before the product has the requirement they serve.
The product has only one-time charges and no recurring or metered commercial relationship.
Subscription state, renewals, meters, aggregation, and rating are not yet active.
The business is the only seller and does not route funds to connected participants.
Connected-account onboarding, split funds, payouts, and platform loss allocation do not apply to a direct merchant flow.
Related starter stacks
See how these decisions appear inside complete application starting points.
Authoritative resources
Standards and primary documentation supporting the Category boundaries.
Sources
Claim-level references used for this decision map.
- 1Payments
Stripe · Accessed Official
- 2What Is a Merchant of Record?
Stripe · Accessed Official
- 3What is Paddle?
Paddle · Accessed Official
- 4How subscriptions work
Stripe · Accessed Official
- 5How usage-based billing works
Stripe · Accessed Official
- 6Create and configure a meter
Stripe · Accessed Official
- 7How invoicing works
Stripe · Accessed Official
- 8How Connect works
Stripe · Accessed Official
- 9Accept a marketplace payment
Stripe · Accessed Official
- 10Risk settings
Stripe · Accessed Official