How to Accept Payments Internationally Without Incorporating in Every Market Four companies decide to enter the same foreign market. They sell comparable digital products to the same customer population. All four can eventually display a payment button. But almost everything behind that button can be different. Merchant A uses a cross-border PSP The merchant remains the seller. Its existing legal entity contracts with a PSP or acquirer that accepts foreign merchants. Customers pay through a cross-border acquiring arrangement, and the merchant receives settlement under the provider's international structure. Merchant B receives provider-supported local acquiring The merchant still uses its existing entity, but its PSP has a local acquiring arrangement that can support eligible foreign merchants under the applicable provider, acquirer, network, and jurisdictional rules. Merchant C operates through payment facilitation The underlying business becomes a sponsored merchant or sub-merchant rather than maintaining the same direct acquiring relationship it would have under traditional acquiring. Visa describes a payment facilitator as a third-party agent that can contract with sponsored merchants on behalf of an acquirer and can receive and distribute transaction proceeds on their behalf. Mastercard similarly defines a payment facilitator as a service provider registered by an acquirer to facilitate transactions for submerchants. (Visa) Merchant D uses a Merchant of Record
A separate company becomes the contractual seller for defined transactions under the agreed structure. The provider may take responsibility for significant parts of payment acceptance, tax collection, refunds, consumer contracting, and related operations, subject to the agreement and applicable law. All four businesses may appear to have achieved the same result: Customers can pay. They have not built the same operating model. That distinction is the foundation for accepting international payments without incorporating in every country. Avoiding incorporation does not make responsibilities disappear. It changes who holds them, how the transaction is acquired, where funds settle, and how much control the merchant retains. The strategic objective should therefore not be: “Avoid local entities everywhere.” It should be: Use the least structurally complex model that provides sufficient market access while preserving the customer, payment, data, economic, and operational control the business needs.
What “accepting payments without local incorporation” actually means A merchant generally does not create a legal subsidiary in every country merely because a customer there places an order. But payment acceptance depends on much more than customer location. The structure can depend on: * Merchant entity * Merchant activity * Customer country * Acquirer * PSP * Card network * Payment method * Merchant category * Currency * Settlement model * Local regulation * Tax * Provider underwriting * Bank requirements A foreign merchant may therefore be able to serve a country through one model while another merchant cannot. The fact that customers are located in Country X does not, by itself, establish that: * A Country X corporation is required. * A Country X bank account is required. * Domestic acquiring is available. * Local payment methods are available. * Local settlement is available. * The merchant has domestic network treatment. Those are separate questions.
The four main no-incorporation models For most merchants, the practical models fall into four broad categories: 1. Cross-border PSP or acquiring 2. Provider-supported local acquiring 3. Payment facilitation or merchant aggregation 4. Merchant of Record They are not interchangeable.
Model 1: Cross-border PSP or acquiring This is usually the simplest conceptual model. The merchant uses an existing legal entity and contracts with a PSP or acquiring provider that is willing and permitted to process customers located in another country. Simplified: Foreign customer ↓ Merchant's existing legal entity ↓ PSP / acquirer ↓ Card network or payment rail ↓ Customer's issuer / bank ↓ Settlement through merchant's provider arrangement The merchant remains the merchant selling the product. What stays with the merchant Typically, subject to contract and jurisdiction: * Customer relationship * Product * Pricing * Checkout * Merchant branding * Refund policy * Customer service * Payment strategy * Fraud policy * Commercial economics The provider supplies payment access. It does not necessarily become responsible for the merchant's wider legal, tax, product, or consumer obligations. Acquiring The payment may be acquired cross-border relative to the merchant, customer, or issuer market depending on the actual acquiring configuration and network rules. The phrase global PSP does not tell you where the acquirer sits. Ask: * Which acquirer receives the transaction? * In which jurisdiction? * Which merchant entity is contracted? * Which MID or sponsored configuration is used? * How will the network classify the payment? Settlement The merchant might receive: * Local-currency settlement * Home-currency settlement * Multi-currency settlement * Provider-led currency conversion depending on the provider.
Cross-border acquiring does not inherently determine settlement currency. The European Banking Authority, for example, has stated in the context of PSD2 that acquiring payment transactions does not automatically require the acquiring payment institution itself to maintain the merchant's payment account; the answer depends on the design of the acquiring model and how funds are transferred. (European Banking Authority) That illustrates the broader principle: Acquiring relationship and destination bank account are related but separate architectural layers. Main advantage Low structural overhead. A merchant can sometimes test customer demand before committing to local corporate infrastructure. Main limitation The merchant may not receive: * Domestic acquiring * Domestic fee treatment * Local card schemes * All local payment methods * Local settlement * Local merchant identification And the route may have different: * Approval performance * cost * settlement * eligibility * provider limits than a domestic acquiring setup. Best fit Often appropriate for: * Early market testing * SaaS * Digital products * Smaller volumes * International card-heavy customer populations * Merchants that value centralized operations
Model 2: Provider-supported local acquiring This is structurally more interesting. A merchant uses its existing corporate entity but works through a provider that has domestic acquiring capabilities or relationships in the target market. The merchant therefore hopes to obtain some of the advantages associated with local processing without independently building the full local acquiring infrastructure. Possible architecture: Foreign merchant ↓ Global/regional PSP ↓ Local acquiring relationship ↓ Domestic or market-specific processing configuration ↓ Issuer The crucial word is possible. Not every provider can sponsor every merchant into every local acquiring structure. What may become local Depending on the model: * Acquirer * Merchant processing configuration * MID or sub-merchant configuration * Routing * Card scheme access * Currency * Settlement But these characteristics must be verified individually. Do not assume: provider has an office locally = merchant receives local acquiring or: merchant has a locally labeled MID = transaction receives domestic treatment Who holds the acquiring relationship? That is one of the most important questions. Possible answers include: Merchant directly The merchant has a direct acquiring agreement but did not need to form a separate local subsidiary under the applicable provider structure. PSP The provider holds or manages the acquiring arrangement and connects eligible merchants through its platform. Sponsored model
The merchant operates through an intermediary structure under the acquirer's sponsorship arrangements. These configurations create different: * Contractual relationships * MIDs * settlement * portability * risk allocation * pricing Main advantage Potential access to deeper local payment infrastructure without replicating a corporate structure in every market. Depending on the exact setup, that could include: * Domestic card processing * Local currency * Specific local methods * Market-specific routing * More suitable settlement None should be promised until provider eligibility is confirmed. Main limitation Provider dependency. The merchant may not control: * Underlying acquirer * MID * routing * contract * token portability * settlement structure to the same extent as under direct acquiring. Best fit Potentially attractive to: * Gaming merchants * Larger digital merchants * Businesses needing local payment depth * Companies whose volumes justify deeper optimization but not a local subsidiary
Model 3: Payment facilitation and aggregation Payment facilitation moves more of the acquiring relationship to an intermediary. Visa's 2024 description of its payment-facilitator framework says the core participants are: Acquirer → Payment facilitator → Sponsored merchant The payment facilitator can contract with sponsored merchants on an acquirer's behalf and, at the acquirer's option, receive and distribute settlement proceeds. Visa also states that sponsored merchants remain subject to Visa merchant requirements. (Visa) Mastercard describes the corresponding concept as a service provider registered by an acquirer to facilitate payment transactions for submerchants. (Mastercard) This is materially different from a traditional direct acquiring relationship.
Foreign merchant versus sub-merchant Consider two businesses. Direct merchant Merchant → contracts with acquirer → receives merchant account/MID configuration → maintains direct acquiring relationship Sponsored merchant Sponsored merchant → contracts through payment facilitator → payment facilitator contracts with acquirer → acquirer sponsors payment facilitator → transactions carry the required facilitator/sub-merchant identification The sponsored merchant remains a real underlying business. It does not become invisible. Visa requires payment facilitators to assign unique identifiers to sponsored merchants for transactions, specifically to enable monitoring of their activity. (Visa) What responsibility moves? Potentially: * Merchant onboarding administration * Acquirer connectivity * Settlement distribution * Risk monitoring * Reporting infrastructure * Merchant agreement administration But not everything. The sponsored merchant still has responsibilities under: * Merchant rules * applicable laws * customer contracts * product requirements depending on the model. Visa explicitly says its sponsored merchants remain subject to merchant requirements. (Visa)
Payment facilitation does not automatically solve the local-entity problem This is a particularly important qualification. Payment facilitation is sometimes described commercially as though it allows any merchant to access acquiring anywhere without local infrastructure. Network rules can restrict that. Visa's global payment-facilitator model states that a sponsored merchant must be located within the acquirer's jurisdiction. Its broader risk guide similarly states that, under its described PF location model, the payment facilitator and sponsored merchant must be located within the relevant acquirer's licensed jurisdiction. (Visa) That does not mean every network, market, provider, or structure follows identical rules. It means: “Use a PayFac” is not a universal substitute for determining merchant-location and acquiring eligibility. The provider must explain the actual permitted structure.
Payment facilitator versus PSP These terms are often incorrectly used as synonyms. PSP describes a broad payment-service role. A PSP may provide: * Gateway services * Acquirer connectivity * Fraud tooling * tokenization * reporting * settlement services * payment methods It might or might not operate as a registered payment facilitator for a particular acquiring relationship. A payment facilitator has a more specific acquiring role under network/acquirer arrangements. Mastercard requires an acquirer to register a service provider as a payment facilitator before it acts in that capacity. (Mastercard) Therefore: Every PayFac can provide payment services. But: Not every PSP relationship is a PayFac relationship. Ask the provider which legal and network role it actually occupies.
Model 4: Merchant of Record Merchant of Record changes the commercial relationship more fundamentally. Under a genuine MoR arrangement, the MoR becomes the seller to the customer for the transactions covered by the model. Simplified: Customer ↓ Merchant of Record ↓ Payment provider / acquiring ↓ Underlying product supplier The underlying company supplies the product or service through the commercial arrangement with the MoR. This can shift substantially more responsibility than ordinary payment processing. Depending on the contract and jurisdiction, an MoR may assume responsibility for areas such as: * Customer contracting * Payment acceptance * Taxes associated with the sale * Consumer billing * Refund processing * Chargebacks * Payment-method relationships But the term Merchant of Record is not permission to assume that every legal, product, privacy, regulatory, or tax obligation has transferred. The actual agreement and applicable law determine the boundaries.
Merchant versus Merchant of Record This distinction should be explicit. Conventional PSP model Merchant sells Provider processes. Merchant-of-Record model MoR sells to the customer for the covered transaction Underlying business supplies through the agreed commercial arrangement. This affects: * Customer receipt * Billing identity * Terms * payments * tax responsibilities * refunds * commercial control That is why MoR should not be evaluated merely as: “A PSP that does more tax work.” It represents a different commercial architecture.
The price of outsourcing responsibility is reduced control Merchant of Record can remove substantial operational burden. It can also reduce merchant control over: * Provider relationships * Pricing implementation * Settlement architecture * Merchant descriptors * Payment routing * Local acquiring decisions * Customer contract * Tax treatment * payment data * migration depending on the arrangement. The correct question is: Which responsibilities are we intentionally outsourcing, and which ones are strategically important enough to retain?
The No-Incorporation Payment Model Matrix This is the core decision framework for the article. Dimension Cross-border PSP Provider-supported local acquiring Payment facilitator Merchant of Record Local incorporation May not be required, subject to eligibility May sometimes be avoided under provider structure Depends heavily on acquiring/network jurisdiction rules Underlying supplier may not need local sales entity for the covered transaction, subject to law/model Seller to customer Merchant Merchant Sponsored/sub-merchant MoR Direct acquiring relationship Often merchant/PSP-specific Varies Generally PF/acquirer structure Usually MoR/payment structure Local acquiring Usually no Potentially Can be available under permitted PF structure Controlled by MoR MID control Merchant/provider-dependent Provider/acquirer-dependent Sponsored/sub-merchant identification model Primarily controlled by MoR/payment stack Customer relationship High merchant control High Generally merchant-facing, subject to model More shared/transferred Pricing control High High Usually high Contract/model-dependent Tax responsibility Merchant retains core responsibility Merchant retains core responsibility Merchant obligations remain Significant transaction-level responsibilities may move, but exact scope must be verified Settlement Merchant receives provider payout Provider/acquirer arrangement PF may receive/distribute settlement MoR settles contractual proceeds to supplier Refund operation Merchant/provider Merchant/provider Merchant/PF structure
Generally MoR-led under model Chargeback relationship Merchant/acquirer/PSP Merchant/provider/acquirer PF/acquirer structure with sponsored merchant responsibilities MoR generally manages acquiring dispute process Data control High High to medium Medium to high depending on provider Often more constrained Payment routing control Medium-high Potentially high Provider/PF dependent Usually lower Portability Usually strongest Provider/acquirer dependent Can be constrained Usually more difficult Launch speed Often high Medium-high if eligibility already exists Potentially high after onboarding Potentially high operationally Integration burden Low-medium Medium Low-medium Often low-medium Operational dependency PSP PSP + local acquiring partners PayFac High dependency on MoR Best strategic use Market testing Deeper market access Platform/aggregated access Maximum operating delegation Every cell needs verification for the actual country and provider. The table compares structural tendencies, not guaranteed product features.
What actually moves in each model The easiest way to compare the four structures is to ask who owns each layer. Layer 1: Customer Who is selling? This determines whether the merchant or MoR is the contractual seller. Layer 2: Product Who is responsible for delivering what was sold? A payment provider does not automatically assume responsibility for the merchant's underlying product. Layer 3: Payment relationship Who accepts the customer's money? Possible answers: * Merchant * merchant through PSP * sponsored merchant through PayFac * MoR Layer 4: Acquiring Who contracts with the acquirer? Possible answers: * Merchant * PSP/provider under specific structure * PayFac * MoR Layer 5: MID Who owns or controls the merchant identification used for acquiring? This can materially affect portability. Layer 6: Settlement Who receives proceeds from the acquiring chain first? Visa's PF model, for example, permits the PF to receive and distribute transaction proceeds on behalf of sponsored merchants under the applicable arrangement. (Visa) Layer 7: Merchant payout Who ultimately sends usable funds to the underlying business? That can be: * Acquirer * PSP * payment facilitator * MoR depending on the model. Layer 8: Refunds and disputes Who receives the consumer request? Who has network-level responsibility? Who funds the refund? Who provides evidence? Those can be different entities. Layer 9: Tax Who is the seller for the transaction and what obligations attach to that role?
Do not assume a payment structure automatically answers every corporate, indirect-tax, income-tax, permanent-establishment, withholding, or invoicing question. Layer 10: Data Who has access to: * Customer * payment * token * transaction * dispute * settlement data? This becomes particularly important when migrating providers.
Accepting payments is not the same as receiving money A merchant can be technically able to accept a payment and still have an unsuitable funds flow. The useful architecture is: Customer payment → authorization → capture → clearing → acquirer/provider settlement → provider balance → deductions/reserves → FX where applicable → merchant payout → merchant bank account The provider may call several of these events “settlement.” The merchant should distinguish them. Provider settlement Funds become available under the provider's internal or contractual structure. Merchant payout Funds are transmitted to the merchant's account. Merchant-accessible funds The merchant can actually use the money. Those events can occur at different times.
Do you need a local bank account? Not necessarily merely because the merchant avoids incorporation. But this cannot be generalized. A local bank account might be required because of: * Acquirer policy * PSP payout requirements * settlement structure * tax * reserves * marketplace operation * local regulation Or it may simply be commercially useful. Alternative structures can include: * International merchant bank account * Multi-currency bank account * Provider settlement balance * Virtual account * Central treasury account Availability is provider- and jurisdiction-specific. The deeper banking question belongs in Do You Need a Local Bank Account? For this operating-model comparison, ask: Can the selected no-incorporation model deliver usable funds into an account our existing entity is legally and operationally able to hold? If the answer is no, the payment-acceptance solution is incomplete.
Settlement currency matters independently of incorporation Avoiding a subsidiary does not mean avoiding currency decisions. Consider a Polish customer purchasing from a U.S. SaaS company. Possible architecture: Customer sees: PLN Transaction processes: PLN Provider settles: EUR Merchant receives payout: USD Merchant functional currency: USD Another provider may allow: Customer: PLN Processing: PLN Provider balance: PLN Merchant payout: PLN A third may convert automatically. The incorporation question does not decide any of these. Always map: Presentment currency → processing currency → settlement currency → payout currency → merchant functional currency That prevents a merchant from choosing an attractive no-incorporation structure that creates unnecessary FX elsewhere.
Merchant archetype 1: SaaS company testing demand Consider a U.S. SaaS merchant entering the Netherlands. It does not yet know whether Dutch demand will justify: * Local operations * staffing * local acquiring * treasury infrastructure Likely starting principle Use the least complex provider model that can support the minimum viable payment experience. The merchant may begin with: * Existing entity * Cross-border PSP/acquiring * EUR pricing * cards and available wallets * relevant local bank method if the provider can support it lawfully for the merchant Why this makes sense The company is trying to answer: Do enough customers want the product? It is not yet trying to optimize every basis point of acquiring economics. What to measure * Time to launch * Completed-order rate * Authorization * Method selection * Payment cost * FX * Settlement timing * Support contacts * Revenue What would change the decision? A more sophisticated structure becomes more attractive when: * Revenue becomes material * Local payment gaps reduce conversion * Cross-border card performance underperforms * settlement becomes expensive * B2B operations require deeper local presence Do not form an entity solely because the first provider cannot support a particular feature without confirming whether that is a provider limitation or a true market requirement.
Merchant archetype 2: Gaming merchant seeking local payment depth Consider a gaming merchant with substantial users across Southeast Asia. International cards work for some customers, but wallet and local-bank-method coverage is commercially important. Possible model Provider-supported local acceptance or local acquiring without direct incorporation may be attractive if available. The merchant wants: * Local methods * Local currency * Fast confirmation * Strong mobile flows * Cards * More market-specific payment performance Strategic question Can the provider supply those capabilities while the gaming company remains the merchant? If yes, the company may avoid building multiple subsidiaries simply to access payments. But verify: * Merchant category eligibility * Acquirer * local methods * MID structure * customer country * settlement * refunds * recurring capability * data * provider portability When PayFac can help A payment-facilitation structure may simplify onboarding and merchant access where permitted. But network jurisdiction rules remain relevant. Visa's global PF framework states that sponsored merchants must be within the acquirer's jurisdiction, demonstrating why the exact sponsored structure must be verified rather than generalized across countries. (Visa)
Merchant archetype 3: Marketplace that needs seller payouts A marketplace has a different problem. It can be easy to ask: “Can we accept payments without incorporating?” The harder question is: What happens to the sellers' money? Buyer payment and seller payout are separate flows. Simplified: Buyer → payment → marketplace/payment infrastructure → platform entitlement → seller entitlement → reserve/refund adjustment → seller payout → beneficiary bank or wallet A provider being able to accept buyer cards does not establish that the platform can: * Hold seller money * split funds * operate safeguarded balances * perform KYC * pay foreign beneficiaries * convert currencies * comply with payment-services rules These activities can raise regulatory issues depending on jurisdiction and structure. In the EU, PSD2 establishes authorization and supervision requirements for payment-service providers and includes safeguarding and payment-service rules; the current EU framework applies to regulated payment services rather than becoming optional because the marketplace lacks a subsidiary in every buyer country. (European Banking Authority) A marketplace should therefore treat: buyer collection and seller payout as separate architecture projects. The detailed payout problem belongs in International Payouts for Marketplaces.
Merchant archetype 4: Large merchant seeking direct control Now consider a multinational merchant processing hundreds of millions in a major market. It currently uses a no-incorporation structure successfully. Customers can pay. But the merchant wants: * Direct acquiring contracts * Its own MID architecture * Acquirer negotiation * Route control * local settlement * direct local bank relationships * better provider portability * deeper treasury integration At this stage, avoiding incorporation may become less valuable. Why? No-incorporation structures often exchange infrastructure simplicity for provider dependency. At scale, the merchant may decide that additional structural complexity buys useful control. Potential triggers include: * Material payment volume * Acquisition cost savings * Authorization opportunities * domestic scheme requirements * local treasury needs * tax or operating presence * resilience * provider concentration This does not mean every large merchant should incorporate. It means the value of control rises with scale.
When does incorporation become worthwhile? The decision should not be driven by prestige or an assumption that mature merchants “should” have local subsidiaries. Consider incorporation when a specific advantage requires it. Potential triggers include: Acquiring An acquirer or payment structure requires a locally eligible merchant entity. Payment methods Important domestic methods become available only under a local merchant structure. Economics Direct local acquiring creates sufficiently large total savings. Authorization Matched transaction tests establish meaningful improved completed-order performance under a structure that requires local establishment. Banking The merchant needs domestic banking unavailable to the foreign entity. Operations The business now has: * Employees * offices * inventory * suppliers * local expenses that make a domestic operating company sensible independently of payments. Regulation The product or business activity requires locally authorized operations. Tax Qualified advisers determine that the commercial structure requires or materially benefits from local establishment. Payment teams should not make the last two decisions alone.
The No-Incorporation Control Gradient Another useful way to understand the models is as a control gradient. More merchant control Direct cross-border acquiring Merchant retains more: * Customer relationship * Payment contracts * routing * data * settlement ↓ Provider-supported local acquiring Merchant retains commercial relationship but depends more heavily on provider infrastructure. ↓ Payment facilitator Merchant remains underlying seller but acquiring administration and sponsorship move further toward intermediary. ↓ Merchant of Record The commercial sale itself moves into the provider's operating structure for the covered transaction. More outsourced responsibility As you move down the gradient, the merchant may gain: * Faster infrastructure access * Less acquiring administration * Less payment operational burden * More bundled compliance functionality while potentially giving up: * Direct contracting * Payment control * provider portability * data access * economics transparency * customer control The right point is different for each merchant.
Direct control versus outsourced responsibility A provider offering to “handle everything” should trigger a due-diligence question: What exactly is everything? Break the proposition into a responsibility map. Responsibility Merchant PSP PayFac MoR Acquirer Product delivery Usually merchant No No Contract-dependent No Customer seller Merchant in PSP/PayFac models No Usually no Yes for covered transaction No Checkout technology Merchant/provider Often Often Often Sometimes Acquirer relationship Merchant/provider-specific May coordinate PF relationship MoR structure Core Merchant underwriting Merchant subject to review Supports PF/acquirer MoR/acquirer Responsible within model Transaction routing Merchant/provider Often PF/provider MoR/provider Acquiring route Settlement Merchant receives eventually Can administer Can distribute MoR pays supplier under agreement Acquirer funds eligible counterparty Customer refunds Merchant-led in conventional model Executes Shared by structure Generally MoR-led Network/acquiring support Chargebacks Merchant exposure generally remains Supports PF/acquirer structure MoR structure Network-facing responsibility Tax Merchant in ordinary model Usually not assumed Usually not assumed Transaction obligations may move materially No general transfer Product regulation Merchant No No Not automatically No The table is a governance tool, not a substitute for contracts or legal advice.
Provider contract versus acquiring relationship One of the biggest sources of confusion is assuming: “We signed a PSP contract, therefore the PSP is our acquirer.” Not necessarily. A payment provider may connect the merchant to: * One acquirer * Several acquirers * A PayFac structure * Local acquiring partners * Bank-payment operators The merchant-facing provider contract can sit above several underlying relationships. For every country, maintain: Merchant contractual entity PSP legal entity Acquirer Acquirer country MID / sponsored merchant configuration Settlement provider Payout entity This should be part of the merchant's payment architecture documentation.
MID ownership matters more when you migrate No-incorporation structures can appear equivalent while the merchant stays with the provider. The differences often become visible during migration. Ask: * Who owns the MID? * Do we have a direct MID? * Are we a sponsored merchant? * Can transaction tokens move? * Can stored credentials be migrated lawfully and technically? * What happens to subscriptions? * Who handles old refunds? * Who handles chargebacks after termination? * What settlement reserves remain? The greater the provider's role in the structure, the more important the exit architecture becomes.
Customer relationship Payment outsourcing does not always mean customer outsourcing. In a conventional PSP model: Merchant → customer remains the primary commercial relationship. In a genuine MoR arrangement: MoR → customer becomes the transactional seller relationship for the covered sale. That can affect: * Terms * receipts * statement descriptors * refund communication * tax documentation * customer service * data A merchant whose brand and direct customer relationship are strategically critical should examine this carefully before choosing an MoR merely for launch speed.
Data control Payment architecture also determines who sees and controls important information. Review: * Customer identity * Customer email * Payment method * token * issuer data * authorization result * decline reason * dispute * refund * settlement * country * tax data Ask whether the merchant receives: * Raw transaction data * Normalized data * portable tokens * provider-only references A model that saves three months of integration effort but traps critical recurring-payment credentials may have a much higher eventual migration cost.
Pricing control No-incorporation models also differ economically. A merchant may pay: Cross-border PSP * Interchange/network cost * PSP/acquirer pricing * cross-border charges where applicable * FX * settlement/payout charges Provider-supported local acquiring Potentially: * Local or regional acquiring charges * PSP margin * FX * settlement charges * additional service costs PayFac Pricing may bundle: * acquiring * risk * merchant onboarding * processing * settlement distribution * platform services MoR Pricing may include a substantially broader bundle reflecting: * payment acceptance * tax functions * refunds * consumer contracting * risk * operational services Do not compare the headline percentages directly. The services being purchased are not equivalent.
Compare total economics Use: Total operating-model cost Payment processing * FX * settlement/payout * fraud * disputes * refund operations * provider fees * internal payment operations * tax/compliance administration attributable to model * integration * migration/portability cost * entity overhead where applicable Then evaluate: Cost per completed order Total relevant operating-model cost ÷ completed paid orders A structure with higher payment fees may still be economically better if it replaces enough internal operational work. Conversely, a seemingly easy model can become expensive at scale.
Time to launch matters—but define it properly “No incorporation” is often justified by speed. That can be valid. But measure: Decision approved → provider selected → contract complete → merchant underwriting complete → integration complete → method approval complete → settlement validated → refund tested → production transaction Time to launch Elapsed calendar time from approved market decision to a validated production payment capability Do not stop the clock when an API key is issued.
Settlement timing Similarly: Settlement delay Elapsed time from the defined completed-payment event to merchant-accessible usable funds Specify the events. Do not compare: * Acquirer funding time in one model with: * Bank-credit time in another. The relevant merchant outcome is cash availability.
Provider dependency No-incorporation structures reduce one kind of dependency—local corporate infrastructure—but may increase another. Provider concentration ratio Revenue dependent on provider-controlled acquiring structures ÷ total processed revenue Track by country. Also record: * Alternative provider availability * Token portability * Contract termination period * MID ownership * Method portability * settlement migration * reserve release A market in which 100% of revenue depends on one provider-exclusive local route deserves contingency planning.
Migration cost A good operating model should have an exit plan before it has a problem. Estimate: Migration cost Engineering * contract work * customer reauthentication where necessary * token migration * parallel processing * settlement overlap * reconciliation * customer support * operational headcount The lowest-cost model to launch can therefore be the highest-cost model to leave.
Revenue contribution The ultimate objective is not payment infrastructure. It is merchant economics. Calculate: Market contribution Revenue retained from the market minus: * Payment expense * FX * refunds * fraud * disputes * provider fees * direct operating cost * structural overhead A sophisticated local payment arrangement is not automatically better if the country does not generate enough retained revenue to justify it.
The no-incorporation model selection sequence Stage 1 — Test whether the existing entity is eligible Ask the provider: * Can our existing entity contract? * Is our merchant category supported? * Can customers in the country be served? * Which payment methods are available? * Which acquiring route will be used? * Where will we receive funds? If this satisfies customer and financial needs, stop. Do not add complexity without a reason. Stage 2 — Identify missing local capabilities Possible gaps: * Local card processing * Local wallet * Bank method * Local currency * settlement * authorization * cost Then determine whether the provider can add them without incorporation. Stage 3 — Evaluate sponsored or PayFac structure Only where: * Merchant eligibility is confirmed * Network/acquirer location rules permit it * Merchant category is supported * Settlement is acceptable * portability tradeoffs are understood Stage 4 — Evaluate Merchant of Record Consider MoR when the merchant intentionally wants to outsource broader transactional responsibility, rather than merely obtain another payment method. Stage 5 — Consider incorporation Only when the remaining gap justifies it. That gap might be: * acquiring * regulation * banking * economics * local operations * commercial presence
What would disprove the no-incorporation strategy? The article's thesis is not that merchants should always avoid incorporation. A no-incorporation model becomes less attractive if evidence shows: * Important local methods remain inaccessible. * Approval performance materially underperforms a viable domestic model. * Processing costs become materially higher at scale. * FX becomes expensive. * Settlement is too slow. * Provider dependency creates unacceptable risk. * Token or data portability is inadequate. * Regulatory requirements necessitate local establishment. * Banking requirements make the structure impractical. * Existing physical operations already justify a local entity. At that point incorporation may no longer be unnecessary complexity. It can become infrastructure that supports the underlying business.
The operating-model measurement framework Track every market using the same high-level metrics but segment by operating model. Time to launch Days from market approval to validated production readiness Completed-order rate Completed paid orders ÷ eligible checkout sessions Authorization rate Issuer-approved authorization attempts ÷ eligible authorization attempts reaching issuers Use matched traffic when comparing acquiring models. Effective payment cost Relevant payment expense ÷ processed payment value Cost per completed order Relevant payment and operating-model cost ÷ completed paid orders Settlement delay Time from defined payment completion to merchant-accessible funds Operating headcount Track payment, finance, reconciliation, compliance, and support effort attributable to each market/model. Provider dependency Revenue dependent on the provider-specific structure ÷ country revenue Migration cost Estimated cost and time required to move the merchant to an alternative structure. Revenue contribution Retained market revenue after payment and directly attributable operating-model costs
Merchant decision matrix Merchant situation Start with Add complexity when SaaS testing demand Cross-border PSP Local methods/performance justify it Gaming merchant needing wallets/local payments Provider-supported local access Volume justifies direct acquiring/control Marketplace Regulated marketplace/PayFac/payout structure appropriate to jurisdiction Seller scale and regulatory model require deeper infrastructure Small digital merchant PSP or MoR depending desired responsibilities Scale changes economics Merchant prioritizing tax/payment outsourcing Evaluate MoR Control or economics become limiting Large merchant Cross-border or sponsored route during entry Direct local acquiring/entity creates measurable value Subscription merchant Model preserving token and recurring control Provider limitations create migration/renewal risk
Operating-model FAQ Can a foreign company accept payments in another country without creating a subsidiary there? Sometimes. Whether it can do so depends on the merchant activity, provider, acquiring structure, payment method, merchant category, regulation, tax position, banking arrangement, and jurisdiction. Customer location alone does not establish an incorporation requirement. Can a global PSP give a foreign merchant local acquiring? Potentially under some provider and market structures, but “global coverage” does not prove domestic acquiring. Verify the underlying acquirer, merchant eligibility, MID structure, network treatment, and settlement. Does using a payment facilitator mean I do not need a local entity? Not universally. Visa's global payment-facilitator framework includes jurisdictional requirements for sponsored merchants, illustrating why PayFac arrangements must be evaluated against the actual acquirer and market structure. (Visa) Is a payment facilitator the same as a PSP? No. PSP is a broad functional term. Mastercard defines a payment facilitator specifically as a service provider registered by an acquirer to facilitate transactions for submerchants. (Mastercard) Is a Merchant of Record the same as a payment facilitator?
No. A payment facilitator facilitates acquiring for underlying sponsored merchants. A genuine MoR is the transactional seller to the customer under its commercial model. The contractual and regulatory details still require jurisdiction-specific review. Does avoiding incorporation eliminate tax obligations? No. Entity structure and transaction-related tax obligations are separate questions. The applicable obligations depend on the sale, customer, product, jurisdiction, merchant structure, and tax rules. Does avoiding incorporation mean I do not need a local bank account? Not necessarily. Bank-account requirements can arise independently from acquiring, PSP policy, settlement, tax, reserves, or other operations.
Final merchant recommendation Merchants expanding internationally should not begin with: “How can we avoid incorporating?” Begin with: “What capabilities do we actually need to serve this market?” Define: 1. Customer relationship 2. Payment methods 3. Acquiring depth 4. MID/control requirements 5. Settlement 6. Currency 7. Refunds and disputes 8. Data ownership 9. Tax and regulatory responsibilities 10. Portability Then choose the simplest structure that satisfies them. Use a cross-border PSP when existing merchant infrastructure can reach the customers and the additional local optimization does not yet justify more complexity. Use provider-supported local acquiring when local payment depth matters but independent domestic corporate/acquiring infrastructure does not yet make commercial sense. Use payment facilitation when a legitimate sponsored-merchant model fits the merchant, jurisdiction, acquirer, and network requirements and the merchant accepts greater intermediary dependency. Use a Merchant of Record when the business intentionally wants to transfer a materially broader portion of the transactional seller role—not merely find a shortcut around incorporation. Incorporate when the business can identify a sufficiently valuable reason that the simpler models cannot solve. That reason might be acquiring control, banking, regulation, economics, domestic payment access, local operations, treasury, or a broader commercial presence. The important principle is:
Avoiding local incorporation does not remove the payment architecture. It determines who owns each part of it. The strongest international payment model is therefore not necessarily the one with the fewest entities. It is the one with the least unnecessary structure while preserving the control the merchant will actually need as the market grows.
Original practical asset: The No-Incorporation Payment Model Matrix This should become the article's primary proprietary graphic and downloadable decision tool. Four columns Cross-Border PSP Provider-Supported Local Acquiring Payment Facilitator Merchant of Record Rows * Seller to customer * Merchant entity * Acquiring access * Direct acquiring relationship * MID ownership/control * Local method access * Customer relationship * Payment data * Pricing control * Settlement * Currency * Refunds * Chargebacks * Tax responsibility * Provider dependency * Portability * Time to launch * Operating burden Then add a final row: Best fit Market validation | deeper local payments | sponsored merchant access | broad transactional outsourcing
Supporting visual: Four Ways Into One Market SAME CUSTOMER MARKET | +------------------+------------------+ | | | | | | CROSS-BORDER PSP LOCAL ACCESS VIA PAYMENT GLOBAL PROVIDER FACILITATOR | | | Merchant remains Merchant remains Sponsored seller seller merchant | | | Cross-border Local acquiring PF + Acquirer acquiring where eligible structure | | | Merchant payout Merchant payout PF distributes settlement
| MERCHANT OF RECORD | MoR is seller | MoR payment/acquiring | Contractual payout to underlying supplier Central message: One market. Four ways to assign payment responsibility. Alt text: “Four international payment operating models compared: cross-border PSP, provider-supported local acquiring, payment facilitator, and Merchant of Record, showing differences in merchant relationship, acquiring and settlement.”
The uploaded brief makes this article the operating-model comparison for the Entity, Settlement & Cross-Border Funds cluster. Its central job is to show that a merchant can sometimes enter a market without creating a local subsidiary—but only because the acquiring, merchant relationship, settlement, tax, or payment responsibilities are structured differently among the merchant and its providers. Editorial interpretation Unique evidence anchor: Four merchants enter the same foreign market through four different structures: cross-border PSP, provider-supported local acquiring, payment facilitation, and Merchant of Record. Editorial position: Avoiding incorporation does not eliminate payment complexity. It relocates responsibility or changes the commercial structure. Merchants should choose the least structurally complex model that provides the market access, customer ownership, payment control, economics, settlement, and portability they actually require. Common assumption challenged: “If we do not incorporate locally, the payment provider handles everything.” Merchant decision supported: Which no-incorporation model provides sufficient payment access without surrendering more commercial and operational control than necessary. Selected format: Operating-model comparison.
Structural rationale: Start with four merchants selling into the same market, then follow who owns each layer: customer contract, acquiring, MID, payment acceptance, settlement, refunds, disputes, tax, data, and migration.
SEO recommendations SEO title: How to Accept Payments Internationally Without a Local Entity H1: How to Accept Payments Internationally Without Incorporating in Every Market Meta description: Compare cross-border PSPs, local acquiring through providers, payment facilitators, and Merchant of Record models for accepting international payments without local incorporation. URL slug: /accept-payments-without-local-incorporation/ Primary keyword: accept payments without local incorporation Secondary keywords: * accept international payments without local entity * payment processing without local company * foreign merchant local payments * cross-border merchant payment processing * PSP without local incorporation * international payment operating models * local acquiring without incorporation * Merchant of Record international payments Related entities: Foreign merchant, local entity, payment service provider, acquirer, payment facilitator, sub-merchant, sponsored merchant, Merchant of Record, MID, merchant account, settlement, payout, local acquiring, cross-border acquiring, multi-currency settlement. Article excerpt: Merchants do not necessarily need to incorporate in every country where customers pay them. But cross-border PSPs, provider-supported local acquiring, payment facilitation and Merchant of Record models shift different responsibilities. This guide explains how to choose among them.
Internal-link recommendations Do You Need a Local Entity to Accept Payments? Link early from the discussion of incorporation requirements. Suggested anchor: when a local entity is actually required to accept payments Do You Need a Local Bank Account? Link from settlement. Suggested anchor: when a local bank account may be required Can You Access Local Acquiring Without Incorporating? Use this as the deeper technical follow-up from provider-supported local acquiring. Suggested anchor: how local acquiring can sometimes be accessed without incorporation Merchant of Record vs PSP Link prominently from the MoR section. Suggested anchor: Merchant of Record vs PSP Also link selectively to: * What Is Local Acquiring? * Domestic Merchant IDs Explained * Multi-Currency Settlement Explained * How Cross-Border Settlement Works * International Payouts for Marketplaces
Authoritative source recommendations Prioritize current primary material from: * Visa rules and payment-facilitator documentation * Mastercard rules and payment-facilitator documentation * European Banking Authority for payment-services and acquiring interpretation in the EEA * European Commission payment-services legislation * National financial regulators * Central banks * Tax authorities * Domestic payment-system operators * Provider/acquirer contractual documentation
Particularly useful foundational evidence includes: Visa: Its global PF framework identifies the acquirer, payment facilitator, and sponsored merchant as distinct participants and states that a PF may contract with and distribute settlement to sponsored merchants under the acquiring model. (Visa) Mastercard: Defines payment facilitators as acquirer-registered service providers facilitating transactions on behalf of submerchants. (Mastercard) EBA: Confirms that acquiring payment transactions does not inherently require the acquiring payment institution itself to maintain the merchant's payment account; the flow depends on the acquiring model. (European Banking Authority) EU framework: PSD2 provides the regulatory framework for payment-service providers and acquiring in the EU, including authorization, supervision, safeguarding, payment execution, and related obligations. (European Banking Authority)
Proposed human contribution Payments strategist — required Review: * Four-model taxonomy * Strategic tradeoffs * Customer-control implications * Merchant maturity recommendations Acquiring specialist — required Review: * Cross-border acquiring * Sponsored local acquiring * PayFac * MID ownership * Acquirer jurisdictions * Merchant eligibility Legal/compliance reviewer — required Review: * Merchant-location implications * Payment facilitator qualification * Seller/MoR language * Regulatory responsibilities * Entity statements Commercial operations reviewer — strongly recommended Review: * Refund operations * Disputes * customer service * migration * provider dependence Do not assign named individuals until they have reviewed and approved the piece.
Financial fact-check items Verify: * PSP pricing * PayFac pricing * MoR pricing * Cross-border assessments * acquiring fees * FX * settlement fees * payout fees * reserves * refund fees * dispute fees * operating headcount * migration costs Do not publish a generic claim that a no-incorporation structure is cheaper than incorporation.
Banking fact-check items For each market/model verify: * Required settlement account * Local bank-account requirement * Eligible foreign account * virtual-account support * settlement country * payout country * payout entity * reserve account * refund funding * account-currency requirements Never convert one provider's banking rule into a country-wide requirement.
Currency fact-check items Verify separately: * Presentment currencies * processing currencies * settlement currencies * payout currencies * supported balances * automatic conversion * provider FX * bank FX * refund currency * chargeback currency Do not describe the model as “multi-currency” unless the precise multi-currency capability is specified.
Country-specific fact-check items Before claiming no-incorporation access in any market, verify: * Merchant entity eligibility * Acquirer country * Network jurisdiction * Merchant-location requirement * Payment methods * domestic acquiring eligibility * PayFac eligibility * sponsored-merchant eligibility * Merchant of Record legality/model * settlement * bank account * product category * tax * licensing * current effective date The Visa payment-facilitator location requirements are particularly important evidence that broad global models can still contain country/jurisdiction constraints. (Visa)
Regulatory, legal, tax and treasury fact-check items Verify: * Who is legally selling * Merchant-of-record relationship * Payment-service licensing * Merchant-location rules * Acquirer authorization * Payment facilitator registration * Marketplace status * VAT/GST/sales tax * permanent-establishment exposure * consumer protection * invoicing * data * FX controls * cross-border settlement * sanctions where relevant This article provides general information and does not constitute legal, regulatory, tax, accounting, investment, or treasury advice. Merchants should confirm applicable obligations and financial arrangements with qualified advisers, banking partners, payment providers, and relevant authorities.
Amber-flag claims Require evidence before publication if adding any claim that: * Country X does not require incorporation. * Country X requires incorporation. * Provider X provides local acquiring without a local entity. * A PayFac removes the need for local establishment. * MoR removes all merchant tax obligations. * MoR assumes all regulatory responsibility. * A foreign merchant receives domestic interchange. * A provider-controlled MID produces domestic treatment. * A local bank account is unnecessary. * Local settlement is available. * Settlement is faster under one model. * One model improves authorization. * One model is cheaper. * Tokens are portable. * A provider can pay out internationally. * Marketplace seller payouts are permissible under the payment-acceptance arrangement. Each may be true under specific conditions. None should be generalized.
* Which countries accept foreign merchant entities * Contracting entities * Cross-border acquiring * Local acquiring available without incorporation * Sponsorship arrangements * Payment-facilitator relationships * MID ownership * Merchant-of-record capabilities, if any * Local payment-method eligibility * Bank-account requirements * Settlement currencies * Payout currencies * Multi-currency balances * Local settlement * International settlement * FX * Refunds * Chargebacks * Reserves * Token portability * Data access * Marketplace support * Seller payouts * Provider migration processes
A safe eventual positioning direction would be: An international payment partner can help merchants compare cross-border, local-acquiring, sponsored and other operating models—but the merchant should verify the underlying acquiring, settlement, entity and contractual structure market by market.
Provider-specific verification requirements Ask every provider to complete this operating-model record: Merchant * Contracted merchant entity * Merchant country * Merchant category * Seller to customer Acquiring * Acquirer * Acquirer country * Direct/sponsored relationship * MID owner * Local/cross-border classification * Card/network scope Payment method * Production methods * Merchant eligibility * Local method restrictions Settlement * Initial settlement recipient * Settlement currency * Merchant payout entity * Payout country * Payout currency * Bank-account requirements * Reserve Customer operations * Descriptor * Refund owner * Chargeback owner * support escalation Tax and commercial * Seller of record * Invoice issuer * tax responsibilities contractually assumed * customer terms Data * Customer-data availability * Payment-data availability * Token ownership * Token portability * Retention after termination Migration * MID portability * Token migration * Subscription migration * historical refunds * open disputes * reserve release That record is more useful than asking: “Do you support Country X?”
Cluster sameness-audit fields Article: How to Accept Payments Without Local Incorporation Opening: Four merchants enter the same market through four structurally different payment models. Primary format: Operating-model comparison. Unique evidence anchor: Responsibility shifts among merchant, PSP, acquirer, PayFac, and MoR. Editorial position: Use the least structurally complex model that preserves the necessary level of control. Common assumption challenged: Avoiding incorporation means the provider handles everything. Merchant decision: Select among cross-border PSP, provider-supported local acquiring, payment facilitation, MoR, or eventual incorporation. Main technical distinction: Avoiding the legal entity does not eliminate acquiring, settlement, tax, banking, or operational responsibility. Original framework: The No-Incorporation Payment Model Matrix. Primary metrics: Time to launch, completed-order rate, payment cost, settlement delay, operating headcount, provider dependency, migration cost, and retained revenue contribution. Conclusion: Start with the simplest viable structure; add entities only when a measurable commercial, acquiring, banking, regulatory, or operational advantage requires them. CTA direction: Compare entity and banking requirements next—not a generic provider sales CTA. FAQ: Operating-model-specific FAQ.
Adjacent-content boundary: This piece does not own the full legal-entity question, local-bank-account requirements, local-acquiring-without-incorporation mechanics, detailed cross-border settlement, settlement-currency selection, or marketplace payout regulation. This gives the Entity, Settlement & Cross-Border Funds cluster a clear third step in the decision journey: Do I need an entity? → Do I need a local bank account? → If not, which no-incorporation payment model should I use? → How should settlement and currency then be structured?
Not sure which payment solution fits?
Use the merchant matching prototype to understand the types of providers to evaluate.
Explore matching ↗