Stripe vs Paddle

Merchant of record versus payment processor: tax and VAT ownership

The central choice is who sits in the selling relationship and who is responsible for the operational work around a sale. With a payment processor arrangement, the software company generally remains the seller and must decide how it handles indirect tax obligations in each market. A merchant of record can take on defined sales and compliance duties under its terms. That distinction affects checkout identity, invoices, buyer support, tax administration and finance reporting, not just the payment interface.

Paddle Billing is a merchant-of-record service with global tax and regulatory compliance. Stripe offers standard payments and Stripe Managed Payments, a merchant-of-record solution. Managed Payments includes indirect tax compliance and remittance in more than 75 countries, as well as fraud prevention, dispute management, invoicing and global customer support. Stripe Tax is also available separately, with a no-code rate of 0.5% per transaction where the business is registered to collect taxes. These are different service choices; confirm the product and scope you would actually contract for.

Tax handling in general includes determining where a sale is taxable, applying a rate, collecting the amount, preparing filings and remitting funds. A provider’s calculation capability does not automatically transfer every obligation to that provider. Ask who registers, files, remits, handles exemptions and responds to tax questions in every target market. Clarify the treatment of refunds, credits, digital goods and business customers, and ask legal or tax advisers to review the contractual allocation for your company.

The commercial relationship also shapes customer communication. If buyers see Paddle as the seller, the support team needs to understand where to direct questions about invoices, refunds and payment methods. Under a Stripe setup, establish which company entity appears on statements and invoices and how support accesses payment details. Document these responsibilities before setting subscription policy or publishing a checkout flow.

• Ask for a country-by-country responsibility matrix covering calculation, collection, filing and remittance.
• Check the seller identity, invoice issuer and buyer-support path for each proposed product.
• Have finance and legal review the actual terms and confirm how the arrangement fits the company’s tax advice.

Subscription billing and invoicing

SaaS billing is a lifecycle that connects a commercial plan to a payment and then to product access. Before choosing a provider, describe the subscription events your product supports: initial checkout, renewal, upgrade, downgrade, pause, cancellation, credit and refund. Include proration rules, billing dates, trial conversion and usage measurement if they apply. The buyer should be able to explain what happens in the product when an invoice is open, paid, overdue or disputed.

Stripe Billing has a pay-as-you-go rate of 0.7% of Billing volume and a plan starting at $620.00 per month with a 1-year contract. Stripe Billing includes Smart Retries and recovery workflow automations. Paddle Billing includes merchant-of-record billing, tax and payment handling. Paddle’s standard transaction fee is 5% + 50¢ per transaction. Ask both vendors to map these commercial lines to your expected subscription model and clarify what the chosen service includes.

Invoice behavior deserves its own walkthrough. Bring examples for a new subscription, mid-cycle plan change, credit, refund and renewal. Confirm invoice numbering, tax fields, currency, customer identity, delivery, payment status and export format. If your company uses an accounting system, decide which system owns the invoice and how adjustments reach the general ledger. Avoid maintaining two competing balances for the same subscription.

Make entitlements explicit. A payment event should produce an intentional access state, with a defined grace period, notification and recovery path. Ensure the billing platform, product database and support console agree on the subscription identifier and current plan. The system should handle delayed or repeated events without granting duplicate access or revoking a paid account.

1. Write down plan rules, billing dates, proration, invoice requirements and the access changes tied to each state.
2. Ask both vendors to demonstrate the same new sale, plan change, refund and renewal examples.
3. Document the owner of invoice data, customer balances, subscription status and product entitlements.

Dunning and failed payments

A failed renewal is both a payment problem and a customer lifecycle event. The process should identify a failure, decide whether and when to retry, notify the buyer, provide a way to update payment details and eventually settle the subscription state. Your team needs clear rules for grace periods, access restrictions, cancellation and escalation to a person. A retry policy that finance cannot explain or support cannot see is difficult to operate even when automation is available.

Stripe Billing includes Smart Retries and recovery workflow automations. During an evaluation, ask which failure reasons can trigger retries, how schedules are configured, what events are emitted and where a customer updates a payment method. Verify how retry outcomes affect invoice status and product access. The goal is to make the recovery journey legible to the subscriber and internal teams.

Paddle’s merchant-of-record model includes payment handling, fraud protection, chargebacks and buyer support. Ask Paddle to walk through the failed-payment experience under the precise service you are considering. Clarify which messages Paddle sends, what the software company can customize, how support can see progress and which final outcomes are sent to your product. A provider’s responsibility for a payment does not remove your customer-success team’s role.

Test a realistic sequence in a sandbox or guided demonstration: renewal fails, retry is scheduled, the customer receives a notice, payment details change, the next attempt succeeds, and access remains consistent. Also test the unsuccessful path and the support escalation. Capture who owns the customer message, how duplicate notifications are prevented and what finance needs to reconcile the recovered payment.

• Request a failure-reason and retry-policy walkthrough, including the final subscription status.
• Confirm which party sends notices and hosts the payment-method update journey.
• Align retry, grace-period and access rules with support policy and finance reconciliation.

Webhooks and lifecycle-email triggers

Billing events often trigger product access, onboarding, renewal reminders and customer-success tasks. Build a small event map before implementation: checkout completed, invoice paid, payment failed, subscription changed, cancellation scheduled, subscription ended, refund issued and dispute opened. For each event, identify the system that emits it, the consumer, the customer-facing action and the fallback if delivery is delayed.

Evaluate Stripe and Paddle against the events your application depends on. Use a technical walkthrough to confirm exact event types, payload fields, signature verification, retry behavior, ordering expectations and replay options. Ask whether test environments can exercise the same events as production and how delivery failures are surfaced to an operator.

Keep lifecycle email tools downstream of a reliable subscription state. A welcome email should follow a confirmed purchase; a payment reminder should follow a specific failed-payment state; a cancellation message should distinguish an immediate end from a scheduled end. Use idempotent consumers so repeated event delivery does not send duplicate messages or apply the same entitlement change twice. Store the provider event identifier and the internal action outcome for diagnosis.

This separation lets finance, engineering and customer success reason from one authoritative subscription state. The billing provider can report a payment outcome, the application can decide access, and the messaging system can deliver an appropriate communication. Define the boundaries explicitly rather than allowing a webhook handler to silently become the owner of all three responsibilities.

1. Create an event-to-action map for product access, finance updates, support visibility and customer messages.
2. Ask each vendor to demonstrate signature checks, failed delivery handling and safe replay for required events.
3. Test duplicate and out-of-order delivery in your integration and confirm that lifecycle messages remain accurate.

Payouts, reconciliation and migration between providers

Payouts are not the same as subscription revenue. Finance should reconcile gross transactions, fees, taxes, refunds, disputes, credits and net deposits to the underlying invoices and customer subscription status. Ask for sample exports and confirm stable transaction, invoice, customer and payout identifiers. Agree on the accounting period, currency treatment, timing differences and owner of unresolved variances before launch.

Paddle payouts have a minimum threshold of $100, adjustable up to $100,000, and a $15 SWIFT fee may apply in certain countries. Confirm the applicable threshold, payout schedule, bank route, currency and deductions for your entity. For Stripe, ask for the account-specific payout schedule, reserve policy, payment-method settlement timing and any currency or bank fees. Keep the payout schedule in the cash forecast and the reconciliation procedure in the finance runbook.

Migration between providers requires a plan for identity, consent and payment continuity. Inventory customers, active subscriptions, plan identifiers, billing dates, tax details, invoices, credits, refunds, disputes, entitlements and downstream events. Payment credentials may have provider-specific restrictions, so do not assume they can be copied directly. Ask the receiving provider what migration assistance and customer actions are supported. Paddle offers a migration service intended to move subscribers without putting them at risk; request a scoped plan and clarify its boundaries.

Run a representative migration rehearsal with test customers or a controlled cohort. Compare source and destination subscription counts, next billing dates, amounts, currencies and access status. Reconcile the last source payout and the first destination payout as separate flows, and decide how support will answer questions during the overlap. Establish a freeze window, customer notice, escalation owner and rollback condition before moving production subscriptions.

• Request sample payout and transaction exports, then map them to invoices and accounting fields.
• Confirm payment-credential transfer constraints and the customer steps required for a successful move.
• Use a pilot, reconciliation checkpoint and documented rollback threshold before the full cutover.