Gaspard LEZIN
3rd Party Billing Explained: Models, Flows, and Provider
Understand 3rd party billing models, payment flows, compliance risks, and how to choose between in-house systems and external providers for your business.
A SaaS company can reach meaningful revenue before its billing system shows visible cracks. The first warning often appears when plan changes create inconsistent invoices, tax treatment differs by country, and failed renewals sit untouched because nobody owns the dunning workflow. At that point, the payment integration may still process transactions, but it no longer gives the finance, engineering, and support teams reliable control.
That's where 3rd party billing enters the discussion. An outside provider can handle parts of payment collection, invoicing, subscription administration, reconciliation, or settlement. The trade-off is practical, not theoretical. You reduce engineering and operational work, but you also introduce a provider into the flow of customer data, money, disputes, refunds, and compliance decisions.
Table of Contents
What Third-Party Billing Actually Means for Your Business
Consider a SaaS company that has reached $2 million in annual recurring revenue. Its homegrown payment connection began as a straightforward checkout integration, but growth has exposed the gaps. Proration behaves differently across plans, tax calculations need to account for multiple countries, and failed subscription payments require coordinated retries, emails, and account restrictions. The team hasn't necessarily chosen the wrong payment processor. It has outgrown the billing layer built around that processor.
Third-party billing means an external company performs some or all of the billing work between the merchant and the financial institutions that move the money. That company may be a payment gateway, a subscription billing platform, or a managed service provider. Depending on the arrangement, it may create invoices, collect payments, manage stored payment credentials, trigger webhooks, reconcile settlements, and remit funds to the merchant.
The narrow version is a gateway that routes a transaction and returns an approval or decline. The broader version is a billing platform that manages recurring plans, invoices, retries, refunds, customer records, and revenue-related reporting. Both can be called third-party billing, but they create very different operational dependencies.
Practical rule: Treat “billing provider” as a description of responsibility, not a guarantee that the provider owns the customer relationship or the legal risk.
The word “third-party” refers to the billing layer sitting between the merchant and the acquiring bank or other payment institution. It doesn't mean the payment network itself is the billing provider. In a common arrangement, the merchant sends billing details to the provider, the provider generates an invoice or payment request, the customer pays through that provider, and the provider remits the proceeds after fees. Stripe's explanation of third-party billing describes this separation between invoicing, collection, and remittance.
The value is clear. A merchant trades some control over the payment stack for lower engineering burden, a smaller direct card-data footprint, and faster access to features such as recurring billing and consolidated reporting. The difficult questions come later: who can change the billing logic, who answers a disputed charge, who issues the refund, and who pays when the provider's process fails?
Common Third-Party Billing Models Across Industries
The label covers several models that look similar at checkout but allocate responsibility differently. Start by identifying who sells to the customer, who appears on the customer's statement, and who has authority to reverse the charge.
A Merchant of Record, or MoR, is the legal seller in the transaction. This model is common for digital goods, software distribution, and marketplaces. The provider typically controls the checkout relationship, handles applicable tax obligations within the agreed scope, and takes a larger role in chargebacks and refunds. The merchant gives up more control, but the legal and operational burden can move with it. A detailed overview of the model is available in this guide to Merchant of Record payment structures.
A Payment Service Provider usually processes the transaction without becoming the seller. The SaaS company or retailer remains responsible for its product, customer terms, refunds, and most seller obligations. The provider supplies the gateway, payment methods, fraud tooling, token storage, settlement reports, and related infrastructure. The customer may see the merchant's trading name, the provider's descriptor, or a configured combination, depending on the setup.
Carrier billing uses an aggregator relationship. A telecom carrier places an outside vendor's charge on a phone bill, then collects the amount from the subscriber and remits it after deductions. The historical scale shows why controls matter. A U.S. Senate investigation described roughly 300 million third-party charges each year, representing more than $2 billion in annual charges, and more than $10 billion over the prior five years. It also reported that AT&T, Qwest, and Verizon had earned more than $650 million since 2006 through third-party billing. The Senate investigation recorded substantial concerns about unauthorized charges, making consent, dispute handling, and vendor oversight central issues.
Healthcare uses another established model. A medical billing company submits claims to insurers, tracks payer responses, and collects reimbursement for a provider. The provider remains responsible for the care and patient relationship, while the billing company operates within strict privacy and handling requirements. Baltimore County Public Schools' Office of Third Party Billing began recovering Medicaid costs in 1992, expanded to its Infants and Toddlers program in 1994, and added school-based health center billing in 1998. By fiscal year 2022, it had generated $8,060,569 from Medicaid and private insurance. The office's annual report illustrates how billing operations can become long-term funding infrastructure.
Model | Industry Example | Seller of Record | Chargeback Liability | Statement Descriptor |
|---|---|---|---|---|
Merchant of Record | Digital goods and software | Provider | Usually provider, subject to contract | Provider or configured merchant descriptor |
Payment Service Provider | SaaS and e-commerce | Merchant | Usually merchant | Merchant, provider, or blended descriptor |
Carrier Aggregator | Telecom and bundled services | Vendor or carrier, depending on arrangement | Often split, with carrier-facing dispute duties | Carrier bill or carrier descriptor |
Healthcare Billing Company | Clinics, schools, and public programs | Healthcare provider | Provider, payer, or patient process, depending on claim | Provider or billing service descriptor |
Refunds follow the same pattern. An MoR may issue them directly. A PSP may execute the refund but leave the merchant to approve it. A carrier may require the customer to dispute an unfamiliar line item through the telecom provider. The workflow may be outsourced, but the contract must say who decides, who funds the reversal, and how quickly it happens.
How Third-Party Payment Flows Work Behind the Scenes
A reliable integration separates the customer's payment experience from the internal records needed to prove what happened. The usual flow starts with checkout and ends only when the merchant has matched the settlement to its own order, invoice, or subscription record.
The payment path
Checkout capture: The customer enters payment details in a hosted form, embedded component, or provider-controlled checkout. The provider tokenizes the card data so the merchant's servers don't need to store raw card numbers. Tokenization can reduce the merchant's PCI DSS exposure, but it doesn't eliminate the need to document the remaining controls.
Authorization request: The gateway sends an authorization request through the acquiring side and card network to the issuing bank. The issuer returns an approval, decline, or response requiring another decision or authentication step.
Processor handling: The billing provider records the transaction, applies its rules, and associates the payment with an order, invoice, or subscription. In a tokenized architecture, the system can reuse the payment identity for later charges without copying the original card data.
Capture: Authorization and capture are separate events. A merchant might authorize an amount and capture it later, capture only part of it, or cancel the authorization. That distinction affects order status, available funds, refunds, and reconciliation.
Settlement: The acquirer and provider produce settlement records and remit funds according to their schedules. Batching and cutoff times affect when the merchant sees money and which transactions appear in a particular settlement file.
Reconciliation: The provider matches settlement activity against internal transaction records. Fees, partial captures, currency conversion differences, reversals, and timing gaps can create exceptions that need investigation before finance closes the period.
Oracle documents a representative flow in which a channel captures a gateway token, the billing system converts it into a tokenized payment method using an external payment-method ID as a correlation key, and that method supports one-time charges, recurring billing, and refunds. Oracle's payment process documentation shows why correlation IDs and server-to-server status events matter.
Stored credentials also have a lifecycle. Cards expire, get reissued, or become unavailable, so account updater services and provider events need to feed the subscription system. A successful retry without a corresponding internal status update can leave access active after a failed payment. The opposite problem is just as damaging, a customer pays successfully but the application still shows an unpaid invoice.
For cross-border implementations, teams should document the payment, currency, settlement, and reconciliation sequence before choosing a provider. These multi-currency payment implementation steps are a useful reference for that planning work.
Every handoff needs monitoring. Track webhook delivery, authorization outcomes, capture status, refund status, settlement arrival, and reconciliation exceptions as separate operational signals. A provider can execute the payment correctly while the merchant's own order or entitlement system remains wrong.
Who Bears the Risk When a Third Party Collects Payments
Outsourcing billing doesn't automatically outsource liability. The provider may secure the payment form, operate the gateway, and manage tokenized credentials, while the merchant remains the seller and still answers for what it sold.
Separate technical control from legal responsibility
The provider commonly manages card-data security, gateway configuration, uptime, and transaction records. The merchant usually controls the product description, pricing, customer terms, cancellation policy, renewal disclosures, and the decision to approve a refund. If the provider's retry logic charges a customer after the merchant has promised cancellation, the merchant still has a customer problem even if the API behaved exactly as configured.
A payment facilitator arrangement and a true MoR arrangement aren't interchangeable. In the first, the merchant generally keeps the seller relationship and carries more of the chargeback and regulatory exposure. In the second, the provider becomes the legal seller for the covered transaction and assumes a broader set of obligations, but the merchant pays for that transfer through fees, restrictions, and reduced control.
The contract can allocate financial responsibility between the parties, but it can't erase the customer's right to challenge an improper charge.
Refund timing exposes weak contracts quickly. If the merchant can approve a refund but the provider processes it only during a later operational window, support may promise something the payment system can't deliver. If a provider's terms exclude certain dispute categories, the merchant may still fund the loss or provide the evidence.
Before signing, ask for explicit answers to these points:
Compliance ownership: Which party handles card-data controls, consumer disclosures, tax obligations, privacy requests, and recurring-payment rules?
Dispute workflow: Who receives the notice, who gathers evidence, and who pays the disputed amount while the case is open?
Refund authority: Can the merchant issue refunds directly, and what happens when the provider or acquiring partner is unavailable?
Data access: Can the merchant export customers, invoices, payment tokens where legally permitted, transaction history, and dispute records?
Incident response: What notice, investigation, and cooperation duties apply after an outage or data incident?
Termination: How are active subscriptions, pending refunds, open disputes, and remaining balances handled after exit?
The practical risk split matters more than a vendor's feature list. This guide to chargebacks and payment disputes is useful when testing whether your proposed workflow gives support and finance enough control.
In-House Billing Versus Third-Party Providers
Building billing internally gives a team control over data models, pricing rules, entitlement logic, and provider routing. It also makes the team responsible for every edge case that a commercial billing platform has already encountered, including expired credentials, duplicate events, partial refunds, tax changes, and reconciliation breaks.
A third-party provider can shorten the path to production and reduce the amount of raw payment data touching the merchant's environment. The cost is recurring dependency. Fees vary by payment method and contract, and the merchant must accept the provider's API behavior, outage profile, data model, and roadmap.
Criteria | In-House Billing | Third-Party Provider |
|---|---|---|
Time to launch | Longer, because the team builds and tests the billing layer | Faster, using hosted tools, APIs, and existing payment operations |
Engineering control | Full control over pricing, events, and data structures | Control is bounded by provider APIs and configuration |
Compliance work | Merchant owns the implementation and ongoing evidence | Provider can reduce parts of the card-data burden, while merchant obligations remain |
Subscription logic | Custom logic for usage, tiered, or hybrid pricing | Built-in capabilities may accelerate standard models |
Reconciliation | Merchant designs reports and exception handling | Provider supplies settlement data, but internal matching is still required |
Scalability | Depends on internal architecture and operational staffing | Depends on provider capacity, limits, and service commitments |
Exit risk | Data and workflows remain internally controlled | Migration may be difficult if schemas and identifiers are proprietary |
The economics aren't limited to a processing fee. In-house billing consumes payments engineering time, compliance reviews, support operations, and maintenance work. A provider introduces transaction charges, platform costs, possible minimums, and the internal cost of monitoring an external dependency.
The right choice changes with the product. A business with unusual usage billing may need internal control over rating and invoice generation while outsourcing card collection. A creator selling memberships may prefer a hosted flow and automated access changes. A growing B2B platform should also study the billing challenges for growing platforms before assuming a manual process will remain manageable.
Build the rules that differentiate your business. Buy the payment plumbing that doesn't.
Hybrid architecture is often the workable middle ground. Keep the customer, product, entitlement, and accounting records in your systems. Let the provider handle payment collection, tokenization, and payment events. Store your own immutable transaction references so switching providers doesn't require rebuilding the business ledger.
For SaaS teams comparing implementation patterns, this billing API guide for SaaS startups can help frame the boundary between application logic and payment infrastructure. The decision should be based on staffing, compliance appetite, product complexity, and the cost of being wrong, not on the headline fee alone.
How to Evaluate a Third-Party Billing Provider
Start with requirements, not vendor demos. Write down the exact payment methods, countries, currencies, subscription events, refund rules, tax responsibilities, and settlement destinations your business needs. If a requirement can't be expressed as a test case, it isn't ready for procurement.
Map the operating requirements
Document the full lifecycle of a customer:
Checkout: Which payment methods and authentication steps must work?
Subscription: How are trials, upgrades, downgrades, pauses, cancellations, and prorations represented?
Failure: How configurable are retries, dunning messages, grace periods, and account restrictions?
Support: Can an agent locate an invoice, issue an approved refund, and explain the statement descriptor?
Finance: Can the team reconcile gross payments, fees, refunds, chargebacks, and net settlement?
Engineering: Are webhooks signed, replayable, observable, and covered by an uptime commitment?
Compliance: Where is data stored, and which obligations remain with the merchant?
Ask each provider to demonstrate failure paths, not just a successful card payment. Test duplicate webhook delivery, delayed events, an authorization that captures later, a refund after a cancellation, and a payment method that becomes invalid. Verify how API versioning works and how much notice the provider gives before changing fields or behavior.
Compare the complete cost stack
Request a written schedule covering per-transaction fees, fixed charges, platform minimums, overages, currency conversion, refunds, disputes, hosted checkout features, revenue recovery tools, and payout costs. Don't compare a provider's advertised rate with another provider's all-in cost.
Suby is one documented example of a single product with four uses: Suby Payments, an API-first checkout for cards and crypto; Suby Crypto, which handles the swap, sponsors gas, and settles to a non-custodial wallet or Suby balance; Suby Gating, for paid Discord, Telegram, downloads, and courses; and Suby Invoicing, where the client chooses the payment method while the business chooses the settlement outcome. Its documentation says customers can pay with cards, bank transfers, Apple Pay, Google Pay, or stablecoins such as USDC and USDT across multiple chains. Suby provides an API that lets businesses accept payments by card or crypto, and it offers native Discord and Telegram integrations for subscriptions, paid access, and online communities. Pricing depends on the payment method, so verify the exact method-specific figures on the Suby pricing page before making a comparison.
Verify evidence and contractual protection
Confirm security certifications through the issuing bodies rather than relying only on a sales presentation. Check the provider's PCI DSS status, request its SOC 2 Type II report where applicable, and review data residency options against your privacy obligations. Also ask for incident history, support escalation paths, service-level remedies, and a realistic export process.
A simple scoring matrix can prevent the lowest quoted price from dominating the decision:
Category | Weight | Evidence required | Score |
|---|---|---|---|
Payment and currency coverage | High | Live documentation and sandbox test | |
Subscription and proration logic | High | Demonstrated test cases | |
Webhooks and reliability | High | Technical limits and SLA | |
Reconciliation and reporting | High | Sample reports and export | |
Risk and dispute handling | High | Contract language and workflow | |
Commercial terms | Medium | Complete fee schedule | |
Migration and exit | High | Export specification and timeline |
Teams with complex revenue operations should also understand how a broader platform such as Revenue Cloud for RevOps leaders fits into the surrounding quote, contract, invoice, and revenue process. A payment provider won't automatically solve every upstream or downstream billing problem.
Next Steps for Implementing Your Billing Strategy
Choose the billing model that fits your team's engineering capacity, compliance appetite, customer support operation, and growth path. Upfront cost matters, but the expensive failure is usually an unowned exception, a broken migration, or a contract that leaves refunds and disputes unresolved.
Use a staged implementation plan:
Audit current performance: Review failed payments, retry outcomes, dunning activity, refunds, disputes, and reconciliation exceptions.
Map obligations: Record PCI DSS scope, privacy requirements, regional tax rules, renewal disclosures, and documentation duties.
Shortlist providers: Compare two or three candidates against the same payment, billing, settlement, and support requirements.
Run sandbox tests: Exercise successful payments and failure paths before moving live customers.
Negotiate the exit: Require data portability, clear termination procedures, support for open disputes, and a workable treatment of active subscriptions.
Pilot carefully: Route a low-risk product line or geography through the new provider before changing the entire customer base.
Monitor after launch: Give engineering, finance, legal, and support shared dashboards and fallback procedures.
Don't sign until those teams agree on timelines, success measures, ownership, and escalation paths. A billing migration is a financial systems project, not just a checkout release.
Suby provides an API for accepting card and crypto payments, with settlement to a bank account or stablecoins such as USDC, while its native Discord and Telegram integrations support subscriptions and paid access. If that payment and settlement model fits your billing strategy, visit Suby to review the available infrastructure and pricing by payment method.
