A payment aggregator usually lets businesses accept payments under a provider's umbrella merchant account, while a PayFac is a provider registered by an acquirer to facilitate transactions for onboarded merchants, and a Merchant of Record is the legal entity responsible for customer payment processing. Choose based on contract terms, ownership, onboarding, settlement visibility, dispute handling, and liability, not labels alone.
If you need to ship embedded payments on a deadline, do not choose based on labels alone. Choose based on ownership, legal responsibility, risk, and what your product, finance, and engineering teams can actually run.
Providers do not use these labels consistently. Some use payment aggregator and PayFac in overlapping ways, while others treat a PayFac as a type of aggregator. Mastercard defines a PayFac as a provider registered by an acquirer to facilitate transactions for submerchants, and Merchant of Record is defined around legal responsibility for processing customer payments. The practical takeaway is that the same term can point to different operating structures.
So the real question is not which definition wins. It is what your provider is offering in writing. Before you commit, confirm:
This guide is for marketplace founders, SaaS platform product leaders, and finance, ops, and engineering owners who need a decision they can execute. It skips taxonomy debates and compares these models through operator realities: ownership, onboarding responsibility, settlement visibility, dispute handling, reconciliation load, and migration constraints.
Keep scope limits in view from the start. Provider terms vary, card-network rules change over time (for example, Visa public change summaries tied to 18 April 2025 and Mastercard rules editions such as 3 June 2025), and market or product support is not uniform across countries, regions, or configurations. If you do not confirm those constraints, you are choosing between assumptions, not between models.
Related: What Is Dunning? A Platform Operator's Guide to Recovering Failed Recurring Payments.
Use this as a working summary. An aggregator usually means you process under a provider umbrella account. A PayFac is a provider registered by an acquirer to facilitate transactions for onboarded merchants. A Merchant of Record (MoR) is the legal entity responsible for customer payment processing. Final selection still depends on contract terms, operating model, and acquiring setup.
| Decision point | Payment Aggregator | PayFac | MoR |
|---|---|---|---|
| Who holds the Merchant Account | Provider holds one umbrella merchant account for client processing | Provider maintains a master merchant account used by onboarded merchants | The MoR entity, or a provider arrangement for that entity; confirm exact contract structure |
| Who controls the Merchant ID (MID) | Usually provider-level identity under the umbrella account; confirm whether any distinct MID is provided | Program-specific; do not assume every seller gets a dedicated MID | Usually tied to the MoR entity's processing identity; confirm processor assignment |
| Who holds the acquiring contract | Usually the provider in umbrella-account setups; confirm contract terms | PayFac is registered by an acquirer; that registration is required for payment facilitators | Often the MoR entity or its provider arrangement; confirm who signs the acquiring contract |
| Who boards each seller | Usually the provider under its umbrella model | Typically the PayFac; these programs can include signing merchant acceptance contracts on an acquirer's behalf | Model-specific; if sellers are involved, confirm where onboarding sits |
| Underwriting intensity | Program-specific; confirm depth and timing in provider terms | Program-specific; confirm depth and timing with the PayFac and acquirer | Program-specific; confirm scope by provider and market setup |
| Settlement visibility | Provider umbrella-account model; confirm what settlement detail is exposed in reporting | Can include receiving and distributing settlement for sponsored merchants, and some behavior is acquirer-dependent | Sits with the entity responsible for customer payment processing and its provider stack |
| Dispute handling | Contract-specific; confirm who handles refunds and chargebacks | Contract-specific; confirm role split across PayFac, platform, and sponsored merchant | MoR handles refunds and chargebacks |
| Reconciliation burden for finance | Depends on reporting granularity from the umbrella account | Depends on how settlement and reporting are structured across sellers | Often material because MoR scope commonly includes reporting and reconciliation |
| Best fit by business stage (starting hypothesis, not a rule) | No universal stage rule is established by this evidence set | No universal stage rule is established by this evidence set | No universal stage rule is established by this evidence set |
| Unknown until provider scoping | MID separation, payout export detail, dispute ownership, migration support | Settlement control, MID granularity, onboarding flow, support boundaries | Exact MoR scope across legal, financial, compliance, refund, and reporting obligations by market |
Treat any stage-fit assumption as a scoping hypothesis, not a final answer. If a provider cannot document the unknowns above in agreements, onboarding packets, and settlement or dispute artifacts, the model is not fully defined yet.
If you want a deeper dive, read What Is a Payment Facilitator (PayFac)? And Should Your Platform Become One.
The conflict is real because providers and networks describe related, but not always identical, roles in the payments stack. Some use Payment Aggregator and Payment Facilitator (PayFac) almost interchangeably, while others define PayFac as a narrower role tied to merchant onboarding and acquirer-facing responsibilities.
Provider and network language makes that overlap explicit. Stripe says an aggregator is often referred to as a PayFac or PSP, while also noting they are different businesses. Adyen defines a PayFac as a type of aggregator. Visa also uses aggregator-style naming for the PayFac role. Labels alone do not establish who owns the merchant relationship or other contractual responsibilities.
The practical differences often sit at the acquirer-and-network layer, not in the headline term. Confirm who is registered to facilitate transactions, who signs merchant acceptance contracts, what transaction data is required, and whether the setup uses an aggregated MID or a MID-per-user structure.
Use this rule in practice: if provider docs do not clearly state who owns the seller relationship, treat the label as shorthand, not architecture truth. Before accepting a provider definition, verify in contracts or onboarding materials:
Assess ownership in this order: merchant agreement, then Merchant ID (MID), then the bank role. If long-term control of merchant identity matters, do not launch until MID treatment is explicit in contract language.
Start with who signs the merchant acceptance contract. In Visa's Payment Facilitator (PayFac) model, the PayFac can sign on behalf of an acquirer and can own the merchant relationship directly. Visa also says the acquirer remains responsible for both the PayFac and sponsored merchants. In practice, relationship ownership and accountability can sit with different parties.
| Ownership question | Payment Aggregator framing | PayFac framing | What to verify in contract |
|---|---|---|---|
| Who signs the merchant agreement | Provider groups merchants under its umbrella account structure | PayFac can sign merchant acceptance contract on behalf of an acquirer (Visa model) | Exact named contracting parties and whether the bank is a party |
| Who gets the MID | Aggregator manages one merchant account and groups clients under it | PayFac can use a master account for onboarded merchants; scheme data can require merchant identity | Whether sellers receive a distinct MID, provider-linked identifier, or only transaction identity fields |
| Who can move or replace the bank setup | Provider labels alone do not prove architecture or switch rights | PayFac status is tied to acquirer registration (Mastercard, Rule 7.8 reference) | Substitution rights, re-onboarding terms, and migration support |
This is where teams often overestimate autonomy. A MID is assigned by a processor or acquiring bank, and merchant identity in transaction data does not by itself prove portability. Adyen's PayFac guidance says required transaction data points refer to the merchant (as Merchant of Record in that transaction context), but that is not a guaranteed right to move that identity across providers or banks.
Both aggregator and PayFac models can let merchants accept payments without a direct bank relationship. The practical difference is how clearly merchant identity, registration, and migration rights are documented for your program.
Before launch, have product and legal confirm these items in writing:
The rule is simple: if switching flexibility and merchant identity control matter, require explicit terms for merchant agreement ownership, MID handling, and bank dependency before go-live.
Related reading: What is a Merchant of Record (MoR) and How Does It Work?.
To choose well, map funds flow first, then liability. If your team cannot state who receives customer funds, who handles disputes, and how payouts tie back to transaction records, the label is not enough.
At card-rail level, authorization typically moves from the merchant side to the Acquirer, through the Card Network, and then to the Issuer for approval or decline. That same issuer-acquirer infrastructure is what moves funds from buyer to seller. After authorization, the models split:
Payment Facilitator (PayFac): the PayFac is registered by an acquirer to facilitate transactions for onboarded merchants.Merchant of Record (MoR): the MoR is the entity legally responsible for processing customer payments.| Model | Practical funds position | Liability/accountability center | Operator warning |
|---|---|---|---|
| Payment aggregator | Provider receives customer funds first, then forwards to the business | Review the provider agreement to identify liability allocation | Cash timing and visibility depend heavily on payout schedules and reporting detail |
| PayFac | PayFac operates under acquirer registration for onboarded merchants | PayFac carries meaningful sponsored-merchant responsibility, including disputes | More flexibility can come with more dispute-handling load |
| MoR | MoR is the legal payment entity for the transaction | MoR carries financial, legal, and compliance responsibility, including refunds and chargebacks | Liability is explicit; plan operations accordingly |
The clearest difference is how responsibility is allocated. In MoR, it is explicit on the MoR entity. In PayFac, liability expands as you sponsor and manage sellers. In aggregator structures, operational risk often shows up in payout timing and reporting visibility.
Payout timing matters too. Availability varies by country and industry, and one Stripe benchmark is an initial payout typically scheduled in 7-14 days after the first successful live payment.
One common break is treating synchronous API responses as final truth. Many flows are asynchronous, so final status may arrive later by webhook. If webhook handling is unreliable, including missing 2xx HTTP status code acknowledgments, finance records can drift.
Another common break is capture fragmentation. One authorization can map to multiple captures. Stripe allows up to 50 captures for one PaymentIntent, so one customer payment can produce many settlement records. Partial authorization adds more edge cases, and Stripe explicitly lists Visa, Mastercard, Discover, and Amex support in that context.
A third is payout composition visibility. Stripe recommends automatic payouts to preserve transaction-to-payout association. In manual payout mode, Stripe does not provide transaction-level composition for those payouts.
Before month-end close, make these checks mandatory:
If you want the clearest external liability center, MoR is the most explicit. If you want to sponsor and manage sellers directly, PayFac can fit, but it increases operational burden and liability. If funds land with a provider before remittance, treat payout timing and reporting fidelity as core product constraints.
You might also find this useful: How to Conduct a Payment Platform Post-Mortem: Root Cause Analysis for Outages and Errors.
Once you've mapped funds flow and liability, fit is mostly a business-model decision. Marketplaces usually need seller lifecycle control, SaaS platforms often need a fast path to embedded payments, and cross-border programs should consider Merchant of Record (MoR) when they are ready for a real accounting and responsibility shift.
| Business type | Usually strongest fit | Why it fits | What you must verify before signing |
|---|---|---|---|
Multi-seller Marketplace | Payment Facilitator (PayFac) style or marketplace-oriented model | Aligns with seller onboarding, payment splitting, holds, and payout control | Whether each seller must complete onboarding and KYC before payout, and who owns the merchant relationship |
SaaS Platform adding payments | Aggregator-like or provider-managed embedded payments model | Mainstream embedded-payments docs explicitly support SaaS platform use cases, often with the connected business as the customer-facing merchant | Who is the customer-facing merchant, and how responsibilities and control change if your setup evolves |
Cross-border Embedded Payments | Merchant of Record (MoR) | Can simplify selling where you are not set up locally and centralize customer-facing payment obligations | Who becomes the legal seller, who handles tax, refunds, and chargebacks, and how principal-versus-agent accounting will be assessed |
For a Marketplace, prioritize lifecycle control. You need reliable onboarding states, payout controls, and support for splits and holds once multiple sellers are live.
Your checkpoint is KYC gating before payout. If your provider cannot clearly show seller state transitions and payout readiness, treat that as a launch blocker.
For a SaaS Platform, prioritize speed now without closing future paths. A common pattern keeps the connected business as the customer-facing merchant, which can be a practical first step when you want to launch payments quickly.
The main risk is unclear control boundaries later. Ask early how responsibilities and control change as your setup evolves.
For cross-border Embedded Payments, MoR can be a strong fit when local setup is the blocker. It can centralize payment, tax, refund, and chargeback responsibility under the MoR entity.
The tradeoff is a real shift in responsibility, not just processing convenience. Confirm legal-seller implications and have finance assess principal-versus-agent treatment before signing.
Two recurring anti-patterns are easy to avoid: choosing on headline fees alone, and choosing on familiar labels alone. Fees miss operating impacts like fund availability and customer experience, and label overlap between aggregator and PayFac means you should validate onboarding ownership, payout controls, and merchant-relationship boundaries directly.
For a step-by-step walkthrough, see Choosing Escrow, MoR, or Direct Payment by Operational Ownership.
A major cost is often not processing fees but post-launch operating drag: reconciliation workload, dispute operations, onboarding delays, exception handling, and migration friction when your Merchant Account setup no longer fits.
This gets harder because labels often hide ownership. Visa materials use "merchant aggregator" as an alias for Payment Facilitator (PayFac) in some contexts, while other sources describe different business models. Price the operating responsibilities, not just the label.
Reconciliation is the first hidden bill. If payout grouping is not system-determined, you are responsible for reconciling payouts to transaction history, and external-acquirer data can add separate report streams. Before signing, require a walkthrough that maps one payout to underlying transactions and then to your internal ledger without manual spreadsheet joins.
Dispute operations are the second miss. This is active work: the merchant decides whether to accept or respond to a dispute, so your team needs clear ownership for triage, evidence, deadlines, and seller boundaries. If a provider says "we handle disputes," confirm whether they only surface cases or also own response strategy and evidence submission.
Exception handling is the third. Failed payments come from multiple paths, including issuer declines, blocked payments, invalid API calls, and provider-side validation refusals. If your team only sees "declined," support cannot separate customer payment issues from integration or platform-control failures.
Migration friction is the cost that lands last and often hurts most. Moving between aggregator-like setups, PayFac, and Merchant of Record (MoR) can require changes to onboarding, payout routing, reporting, and merchant-relationship ownership. Do not assume MID or merchant-account portability unless the contract says so.
Unclear seller responsibility is a common break. In Visa's PF model, a PF can sign a merchant acceptance contract on behalf of an acquirer, and the acquirer is responsible for PF and sponsored-merchant acts. If contract language and operating design do not match, escalations follow quickly.
Delayed onboarding is another predictable failure mode. In platform flows, users must complete onboarding and KYC before payouts, and some providers keep charges and payouts disabled until verification requirements and payout setup are complete. If your plan assumes instant activation, go-live revenue timing can slip.
Data gaps between provider reports and internal ledgers are a quieter failure mode. A 2-day rolling basis for balance availability in some account models can still leave finance blocked if transaction-level traceability is missing. If you cannot tie transactions and payouts reliably before close, accounting risk is already in production.
Use one guardrail. If your team cannot distinguish likely issuer-side declines from integration or platform-validation failures, pause rollout and fix observability first. You need refusal reasons, provider event IDs, and internal order or invoice IDs in one place before you scale.
180 days in some connected-account models)MID ownership boundariesIf observability, onboarding-state control, and reconciliation traceability are not provable in live demos or sample reports, treat that as a commercial risk, not an implementation detail.
Need the full breakdown? Read How MoR Platforms Split Payments Between Platform and Contractor.
Before launch, require a written decision packet that fixes ownership and escalation. If ownership is still verbal, the model is not launch-ready. Your minimum packet should include:
Payment Aggregator, Payment Facilitator (PayFac), or Merchant of Record (MoR)Approve based on operating facts, not the label alone.
| Decision point | If provider says Payment Aggregator | If provider says PayFac | If provider says MoR | What you need in writing |
|---|---|---|---|---|
| Merchant relationship | Confirm whether businesses are processing without their own Merchant Account, and whether "aggregator" is being used loosely | In Visa materials, a PF is a third-party agent and a sponsored merchant is a merchant whose payment services are provided by the PF | The MoR is the legal entity selling to the end customer | Who contracts with each merchant or seller, who signs, and who owns the customer-facing sale |
| Acquirer responsibility | Confirm who sits with the Acquirer and whether merchant acceptance is delegated | Visa states a PF can sign on behalf of an acquirer, and the acquirer remains responsible for PF and sponsored-merchant acts | Confirm whether your platform is outside direct merchant contracting or still holds defined obligations | Named contracting parties, delegated authority, and accountability path for compliance escalations |
| Onboarding and KYC | Confirm onboarding requirements by market/program and merchant profile | Confirm who collects required information for each sponsored merchant | Confirm what onboarding still applies to your platform, sellers, or service providers | Market-by-market onboarding constraints, required data owner, and remediation owner when requirements change |
| Liability and support | Do not assume provider verification or support removes your obligations | Do not assume provider verification satisfies independent legal KYC duties or fraud monitoring | MoR positioning often assigns payment, tax, compliance, refund, and chargeback liabilities to the MoR entity | Exact support boundaries for disputes, fraud, refunds, and compliance investigations |
Finance and ops should have auditable transaction-to-payout traceability before approval. Test one path from transaction ID to provider event ID to payout ID to internal ledger entry. If that requires manual reconstruction, you may be accepting accounting risk at launch.
Compliance should document policy gates and onboarding design choices. Connected-account requirements depend on location, business type, requested capabilities, and service-agreement type. Platforms also choose up-front (eventually_due) vs incremental (currently_due) collection, and requirements can change over time.
Require written market and program coverage confirmation. For PF or marketplace-style setups, confirm who handles registration in the relevant network path. Visa's April 2021 risk guide states the acquirer must register the payment facilitator or marketplace through PRM after due-diligence attestation.
Keep provider verification and your legal obligations separate in the packet. Stripe states platforms should not rely on its verification to satisfy independent legal KYC obligations and still must monitor for and prevent fraud.
Close-process pressure can be significant. If you cannot assemble this packet with written ownership, coverage, and support boundaries, pause launch. Undocumented ownership is still unowned risk.
We covered this in detail in MoR vs. PayFac vs. Marketplace Model for Platform Teams.
After the ownership packet is approved, lock the operating model before writing payment state code. Use this order: model ownership, then event contracts, then idempotent retries, then reconciliation exports and dashboards.
Start with one explicit ownership decision: who is acting as the Merchant of Record (MoR), whether your setup is closer to a Payment Facilitator (PayFac) model with seller activity, or whether a Payment Aggregator is processing under its umbrella Merchant Account. In Stripe Connect-style integrations, this choice affects funds flow, including how charge types distribute funds and which account is debited for refunds and chargebacks.
Your webhook and ledger design should match the activity scope you must observe.
| Build area | MoR-like implementation focus | PayFac or aggregator-like implementation focus | Risk if wrong |
|---|---|---|---|
| Event intake | Platform-level payment, refund, dispute, and payout states for the selling entity | Platform events plus seller or connected-account activity tied to each onboarded merchant | Blind spots in disputes, refunds, or seller balances |
| Payment state model | One primary seller of record, customer-facing sale owned by the platform entity | Seller-aware states, account mapping, and per-merchant attribution | Finance cannot explain who owned the transaction or why a balance moved |
| Per-transaction data | Order and customer data centered on the platform sale | Extra merchant or seller data may be required per transaction in some PayFac programs | Reconciliation and support cases lack required exception data |
In Stripe Connect, platforms use two webhook types, and Connect webhooks are the channel for connected-account activity. If your model includes connected-account activity (for example, many PayFac-style implementations), this channel becomes central. In at least one Adyen PayFac flow, seller or MoR data points are required per transaction. If seller-level processing exists in your model, make that data required in your event schema.
Make every write path retry-safe. Use an idempotency key on POST requests, and design webhook consumers to handle duplicate or concurrent deliveries without duplicate ledger effects.
Design for actual retry windows. Live webhook delivery retries can run up to 3 days, sandbox retries are three attempts over a few hours, idempotency keys can be pruned after 24 hours, and event-list backfill is limited to the last 30 days. Build two controls: duplicate-safe consumers and a missed-event reconciliation path.
Before go-live, require evidence for three checks:
If finance cannot tie internal states to payout reconciliation outputs, launch readiness is incomplete.
Post-launch, keep one practical control until variance is stable: a regular mismatch review between processor outputs and internal finance reports. This is an operating control, not a card-network mandate, and it helps catch missed events, wrong account attribution, and manual ledger drift early.
This pairs well with our guide on Banking Partnerships for Fintech Platforms: How to Choose Between BaaS and MoR.
Decide the model only after you can answer ownership, control, onboarding, and risk questions with a clear yes or no. If key answers are still unknown in your contract packet, customer-facing terms, and operating design, you are not ready to commit.
| Yes/no check | What to verify before you say yes |
|---|---|
| 1. Do you know which entity is the Merchant of Record for each transaction? | The MoR is the entity with legal responsibility for the transaction, including disputes and refunds. |
| 2. Do your customer-facing website, payment flow, and terms clearly name that MoR entity? | The MoR should be explicit on customer-facing surfaces, not implied internally. |
| 3. Do you know who holds the Merchant Account? | In an aggregator setup, multiple clients can process under one umbrella Merchant Account. |
| 4. Do you know who controls the Merchant ID (MID)? | Confirm whether you receive your own MID or operate within a provider-managed account structure. |
| 5. Do you know whether each seller is treated as a sponsored merchant? | In PayFac models, card-network merchant requirements still apply to sponsored merchants. |
| 6. Do you know who signs the merchant acceptance contract with each seller? | In PayFac models, this can be signed on behalf of an acquirer, so verify the exact contracting path. |
| 7. Do you accept who carries dispute and refund liability? | If your entity is MoR, account for that exposure before launch. |
| 8. Do you know who covers losses when a connected account balance goes negative? | Some configurations can still leave the platform in the end responsible. |
| 9. Do you know your seller onboarding burden? | Confirm required seller data, review steps, and exception handling for your provider program before a seller can process. |
| 10. Do finance and engineering have enough provider references and reports to trace payments to balances and payouts? | Verify traceability from transaction events through balance movement to payout reporting. |
Use one internal rule: if more than three critical answers are "unknown," do not commit to provider terms yet. Then assign immediate next actions by owner:
If more than three answers are still unknown, use the Gruv docs to tighten ownership, event, and reconciliation decisions before signing terms.
Switch models before your current setup slows onboarding, weakens payout control, or increases risk pressure. If your Acquirer setup, Merchant Account structure, or MoR allocation no longer fits how you operate, migration can be safer before the next growth step.
| Trigger | What it usually means | Migration signal |
|---|---|---|
| New geographies | A traditional payfac rollout may be country-by-country | If launch timing matters, confirm your model can enter each market without extra market-by-market rollout work |
| Higher dispute or fraud exposure | Network monitoring becomes an operating constraint | Visa monitors fraud, disputes, and enumeration monthly; if pressure is rising, adjust model or controls before required mitigation measures |
More complex Marketplace payouts | You need explicit funds-and-fees booking across balances | If payouts now require split logic across user balance accounts and a platform liable balance account, reassess your model |
| Contract limits on portability | Portability can be constrained by provider terms | If contract terms do not clearly support migration of payment data or stored credentials, treat that as an early migration trigger |
Timing rule: migrate before growth exposes a known weakness. In parallel, check dispute pressure and payout complexity early rather than waiting for network monitoring or reconciliation friction to force the change.
Merchant Account portability and payment-data migration supportThe right choice is not the label. It is explicit ownership: who owns the merchant relationship, who carries transaction and compliance liability, and how disputes, settlement, and exceptions are handled when something breaks.
That is why this is an operating decision, not a naming exercise. A payment aggregator can let you process without your own Merchant Account. A Payment Facilitator (PayFac) is a formal role registered by an Acquirer. The Merchant of Record (MoR) is the entity legally authorized and responsible for customer payments, including financial, legal, and compliance liability. Those differences matter even when provider language sounds similar.
Before vendor commitment, run one checklist session with product, engineering, and finance together. Put the contract language on screen and confirm:
If those answers do not match the merchant agreement, onboarding flow, and reporting outputs, treat the model label as unverified. This matters even more for cross-border rollout, where market and program coverage is not automatic and some program rules include country constraints.
Choose the model that matches your actual funds flow and your willingness to own risk and operations, then verify it in documents before launch. If you need model-specific rollout validation, review provider docs and confirm country or program fit with sales or your provider contact before locking architecture.
If you want a model-fit review against your rollout scope and market/program constraints, talk to Gruv.
Not consistently. Some providers use the terms in overlapping ways, while others treat a PayFac as a type of aggregator. In practice, confirm whether the provider is onboarding sponsored merchants as a registered PayFac or processing you under the provider's existing merchant setup.
Merchant of Record is the entity legally authorized and responsible for processing customer payments. It carries financial, legal, and compliance responsibility, including refunds and chargebacks. PayFac and aggregator labels more often describe onboarding and payment-access structure, while legal accountability depends on who is the MoR and how the provider model is set up.
No. In some aggregator or provider-managed setups, you can accept payments without your own Merchant Account, and you might not receive your own MID. Confirm in writing whether the MID is dedicated to you or tied to the provider's account structure.
For a Marketplace, start with funds flow: if you collect from customers and pay out sellers, you need clear support for seller onboarding, payouts, and account-level responsibility. For a SaaS Platform, direct-charge patterns are often positioned as a better fit for software platforms. Use the model that matches your actual funds flow and risk ownership, not just the provider's naming.
In an MoR setup, the MoR typically carries that burden because it is liable for transaction compliance and post-transaction issues such as refunds and chargebacks. In PayFac structures, the PayFac has rule obligations, while bank-side responsibility still remains material. For platform setups, verify exactly which account covers refund and dispute losses before treating risk ownership as settled.
Confirm who signs the merchant agreement, who owns the merchant relationship, whether the provider is operating as a PayFac tied to an acquirer, whether you get your own Merchant Account or MID, and which account covers refund, dispute, and negative-balance losses. Then check that those answers match onboarding, settlement reporting, and legal terms. If those artifacts conflict, treat the label as unverified.
Avery writes for operators who care about clean books: reconciliation habits, payout workflows, and the systems that prevent month-end chaos when money crosses borders.
Includes 3 external sources outside the trusted-domain allowlist.
Educational content only. Not legal, tax, or financial advice.
The hard part is not calculating a commission. It is proving you can pay the right person, in the right state, over the right rail, and explain every exception at month-end. If you cannot do that cleanly, your launch is not ready, even if the demo makes it look simple.
Step 1: **Treat cross-border e-invoicing as a data operations problem, not a PDF problem.**
Cross-border platform payments still need control-focused training because the operating environment is messy. The Financial Stability Board continues to point to the same core cross-border problems: cost, speed, access, and transparency. Enhancing cross-border payments became a G20 priority in 2020. G20 leaders endorsed targets in 2021 across wholesale, retail, and remittances, but BIS has said the end-2027 timeline is unlikely to be met. Build your team's training for that reality, not for a near-term steady state.