Regulations, licensing and tax

Publication-ready pillar section Regulations, Licensing and Tax A payment provider can support a country without every merchant, product, or payment model being automatically ready to launch there. That distinction is easy to miss because the technical question is often answered first. A merchant checks the PSP dashboard and sees that the country is supported. The preferred payment methods are available. Engineering confirms that the existing integration can submit transactions. Commercial concludes: Payments are covered. Then another set of questions begins. Can the product legally be offered to customers in that market? Does the merchant need a different entity or contractual structure? Does the business activity fall within a regulated category? Do local consumer rules change the way subscriptions, refunds, disclosures, or renewals must work? Does Finance need to change tax registration, VAT/GST treatment, invoicing, or reporting? Does the PSP or acquirer need to underwrite the new geography or business configuration again? The payment API did not fail. The market-entry analysis was incomplete. That is why regulation, licensing, tax, and provider review belong on the payment expansion critical path. Payment availability does not equal permission to launch “Provider supports Country X” can mean several different things. It may mean: * The PSP has infrastructure capable of processing there. * A payment method is technically available there.

* The provider operates through an acquiring or banking relationship in the market. * Certain merchant categories can be onboarded there. It does not necessarily mean: * Every product can be sold there. * Every merchant category is supported. * Every foreign entity can use every acquiring configuration. * No local authorization or registration is relevant. * Existing KYC/KYB is sufficient for the new activity. * Tax and invoicing remain unchanged. * The provider has approved this merchant’s specific expansion. Those are separate questions. Card-network rules themselves illustrate why merchant acceptance depends on more than API connectivity. Visa’s current rules include merchant-agreement, acquirer, risk, licensing, regional, and acceptance requirements rather than treating merchant acceptance as one global technical state. The broader compliance principle is similar: regulatory obligations depend on the regulated activity, participant, jurisdiction, and risk rather than on the technical ability to transmit a payment instruction. FATF’s current standards, for example, explicitly require countries and institutions to apply measures on a risk-sensitive basis rather than treating all relationships identically. For a merchant, the operational lesson is: A supported country is a starting point for feasibility—not proof that the planned business model has been approved.

Which compliance questions change by market? A useful way to avoid late surprises is to separate the questions by owner. Business: can we offer this product or service? The first compliance question may have nothing to do with payment processing. The merchant should determine whether the intended product, service, or commercial model is permitted in the target market and whether specific conditions attach to offering it. Questions can arise around: * Regulated products or services * Restricted business categories * Digital platforms * Marketplaces * Financial products * Gaming * Travel * Subscription models * Age-restricted products * Other regulated or sensitive activities The answer can depend heavily on the business model. A marketplace, for example, may face obligations that do not apply to a merchant selling its own inventory. Within the EU, the Digital Services Act illustrates this type of business-model-specific variation: it creates responsibilities for categories such as online marketplaces and other intermediary services, including specific trader-traceability and transparency requirements. Those obligations do not apply simply because a payment is accepted in euros; they arise from the nature of the service being provided. That is why commercial viability should be checked against the actual product model, not merely against a PSP country list.

Merchant: does the legal or entity setup change? Entering a market can create questions around: * Which merchant entity contracts with the customer * Which entity contracts with the PSP or acquirer * Whether an existing foreign entity can operate the planned model * Whether a local entity would be required or commercially useful * Whether corporate registration or local presence changes other obligations This does not mean every new country requires local incorporation. The correct question is: Does the target operating model work with the legal entity we already have? If not, entity work can become one of the longest-lead-time parts of the launch. That is why entity feasibility should be reviewed before engineering assumes the merchant configuration is fixed. Where this becomes material, the deeper question belongs in Do You Need a Local Entity to Accept Payments?

Payments: do acquiring or payment rules change? Payment processing introduces another regulatory and contractual layer. The merchant may need to ask: * Is the desired payment method available to this merchant category? * Can the existing entity use the intended acquiring route? * Does the provider support the activity in this market? * Are there authentication or transaction requirements that differ? * Are there payment-network or acquirer restrictions? A payment method can be technically present in a country but unavailable to: * A particular merchant category * A foreign entity * A particular transaction type * A specific business model Provider capability therefore needs to be checked at the level of: merchant + entity + country + product + payment method + transaction model. Not: country supported = yes.

Licensing: is regulated authorization relevant? “Do we need a license?” is one of the most consequential questions to discover late. But it is also one of the easiest questions to oversimplify. Licensing can depend on what the merchant is actually doing. For example, a business merely selling its own goods is structurally different from one that: * Holds funds for third parties * Facilitates transactions between buyers and sellers * Provides financial services * Operates a regulated digital service * Conducts another activity requiring authorization The relevant authorization may belong to: * The merchant * A payment institution * A banking partner * Another participant in the model The pillar should not answer those legal questions country by country. The strategic requirement is: Determine early whether the business model creates regulated activity that changes the market-entry design. If licensing is relevant, it can affect: * Legal structure * Payment flow * Provider selection * Launch sequence * Commercial model That makes it a market-selection dependency, not a post-integration checklist item.

Consumer: do the customer obligations change? International expansion can also change what the merchant must communicate or provide to customers. Depending on the jurisdiction and business model, relevant questions may include: * Pricing disclosures * Subscription renewal * Cancellation * Refunds * Consumer rights * Delivery * Complaint mechanisms * Trader information * Checkout disclosures These requirements can affect payment UX even when they originate outside the payment stack. That creates an important bridge between Compliance and Product. A merchant might technically be able to charge a recurring payment while still needing to change: * Consent language * Renewal notices * Cancellation flow * Customer disclosures before the local product is ready. The payment capability can therefore be globally standardized while the customer-facing contractual experience remains market configurable.

Tax: what must Finance verify? Tax should be kept distinct from payment regulation. The payment team should not attempt to answer: What tax do we owe in this country? It should ensure that Finance has asked the question before launch. Relevant topics can include, depending on the merchant and jurisdiction: * VAT * GST * Sales tax * Registration * Place-of-supply rules * Import treatment * Marketplace/platform obligations * Invoicing * Digital reporting * Withholding * Permanent-establishment or other corporate-tax questions The exact analysis belongs with qualified tax advisers and relevant tax authorities. The point for payment planning is that tax can change: * Displayed price * Charged amount * Invoice * Merchant entity * Settlement/accounting * Reporting architecture EU ecommerce provides a good illustration of why these requirements are not static. The European Commission updated its VAT ecommerce and One Stop Shop guidance again in July 2026 to account for changes introduced through the VAT in the Digital Age package, with additional changes taking effect over subsequent years. That is exactly why international tax logic should not be hard-coded from an old launch assumption.

Provider: does geographic expansion trigger another review? One of the most overlooked dependencies is the PSP or acquirer itself. The merchant may already be approved. That does not necessarily mean every future country, product, entity, transaction pattern, or payment method is automatically covered by that approval. Expansion can alter facts relevant to underwriting, such as: * Customer geography * Transaction volume * Payment methods * Business activity * Entity * Delivery model * Settlement * Risk profile The provider may therefore need: * Updated information * New KYC/KYB * Additional underwriting * Acquirer approval * Merchant-category review * Payment-method approval depending on the actual setup. That is different from regulation. Regulation asks: What does the applicable legal framework require? Provider underwriting asks: Will this provider/acquirer support this merchant configuration under its own obligations, risk appetite, network relationships, and policies? The two can influence one another. They should not be described as the same thing. This is the natural place to route readers into how geographic expansion triggers re-underwriting.

Regulation versus provider underwriting A merchant expanding internationally may encounter five different rule layers that look similar from the outside: Layer Typical source Merchant question Law / regulation Legislature, regulator, tax authority What are we legally required or permitted to do? License / authorization Relevant regulator or authority Does this activity require regulated permission? Payment-network rule Card or payment network What rules apply to acceptance or processing? Acquirer / PSP requirement Provider/acquirer Will this configuration be onboarded and supported? Merchant policy Merchant itself What standards do we choose to impose globally? These layers can produce similar requests. For example: Provide more information about the business model. That request could arise because of: * Regulatory due diligence * Network rules * Acquirer underwriting * PSP risk policy The merchant should not assume that: provider requires it means: local law universally requires it. Likewise: the law permits it does not mean: every PSP must support it. This distinction makes market-entry conversations substantially more precise.

The Market-Entry Compliance Question Map Before a country becomes a committed launch, ask seven groups of questions. 1. Business Can the product or service be offered under the intended model? Check: * Product/category restrictions * Sector-specific rules * Platform/marketplace implications * Customer type * Delivery model Owner: Legal / Compliance / Business

2. Merchant Does the legal structure support the intended market? Check: * Contracting entity * Foreign-vs-local merchant treatment * Entity changes * Relevant corporate registration * Banking relationship where connected Owner: Legal / Corporate / Payments

3. Payments Does the proposed payment configuration work for this merchant? Check: * PSP availability * Acquirer availability * Payment methods * Merchant category * Transaction type * Authentication * Settlement configuration Owner: Payments / PSP / Acquirer

4. Licensing Does any part of the planned activity require authorization? Check whether the merchant's role changes from: selling to potentially: * Facilitating * Holding * Transmitting * Providing regulated services Do not infer the answer; verify it. Owner: Legal / Compliance / external specialist

5. Consumer Do local customer obligations change the payment experience? Check: * Disclosures * Subscription terms * Cancellation * Refund * Pricing * Customer-service requirements Owner: Legal / Product / Payments

6. Tax What must Finance establish before transactions begin? Check: * Registration * VAT/GST/sales-tax treatment * Invoicing * Reporting * Marketplace/platform treatment * Cross-border tax implications Owner: Tax / Finance

7. Provider Does the new market require PSP or acquirer re-review? Check: * Updated KYC/KYB * Geographic expansion * New entity * New method * New product * Revised volumes * Acquirer review Owner: Payments / Compliance / provider

Move compliance onto the market-entry critical path The worst time to discover a regulatory dependency is after the merchant has already: * Signed local commercial contracts * Built checkout * Announced a launch * Hired a local team * Integrated a payment method * Committed revenue forecasts At that point, even a legitimate and solvable requirement becomes expensive because other decisions depend on it. The better sequencing is: Target market → business-model feasibility → entity / licensing / tax questions → provider and acquiring feasibility → product and payment configuration → engineering → launch. This is not a claim that every legal or tax question must be resolved in full before technical work begins. It means the merchant should identify blocking classes of requirements before making decisions that are costly to reverse. A useful launch status is therefore not simply: PSP coverage confirmed. It is: Compliance feasibility known The merchant knows: * Which questions have been cleared * Which require configuration * Which require professional advice * Which require provider review * Which could block launch That is the level of certainty expansion teams actually need.

The most important market-entry compliance question Before committing to the target country, ask: Which regulatory, licensing, tax, entity, or provider-review dependency could invalidate our current launch design if we discover it later? Then place that dependency on the critical path. If the answer is: We do not know yet, the market is not necessarily unsuitable. But it is not yet compliance-feasible. That is a fundamentally different state from: our PSP supports it. This content provides general information and does not constitute legal, regulatory, tax, accounting, or financial advice. Requirements vary by jurisdiction, business model, merchant structure, provider, payment method, and regulated activity. Merchants should verify current requirements with qualified advisers, relevant authorities, and their payment providers or acquirers.

The brief makes this section the pillar’s regulatory-feasibility gate. It should not become a country-law explainer. Its job is to show why market entry can be commercially and technically plausible while still being blocked by business-model rules, licensing, entity structure, tax, consumer obligations, or a provider/acquirer review that was never scoped at the beginning. A. Brief interpretation Section-owned question: Which legal, licensing, tax, and provider-review questions can turn an apparently supported country into a market the merchant is not yet ready to launch? Merchant problem: Expansion teams often validate PSP coverage, methods, and integration first, then discover that the product, merchant structure, regulatory status, consumer obligations, tax treatment, or acquiring approval needs additional work. Editorial position: Regulatory, licensing, tax, and provider-underwriting feasibility should be investigated during market selection—not after product and engineering commitments are already made. Key distinction: Technical payment availability is not the same as legal permission, regulatory readiness, or an approved PSP/acquirer configuration. Evidence anchor: A provider can technically process in a country while the merchant’s specific product, category, entity, or payment model still requires additional review or market-specific work. Primary merchant decision: Which regulatory, licensing, tax, or provider-review dependency could block the launch if discovered late?

B. C. Original section asset Market-Entry Compliance Question Map Area Core question Potential blocker discovered late Primary owner Business Can this product/service be offered under this model? Product/category restriction or required business-model change Legal / Compliance Merchant Does the existing entity structure work? New entity or corporate-registration requirement Legal / Corporate Payments Can the desired merchant configuration be processed? Acquirer/method/category incompatibility Payments Licensing Is regulated authorization relevant? Required license or need to redesign flow Legal / Compliance Consumer Do customer obligations change? Checkout, renewal, refund, or disclosure redesign Legal / Product Tax What must Finance establish? Registration, invoice, tax-calculation or reporting change Tax / Finance Provider Does PSP/acquirer need to review the expansion? Re-underwriting, KYC/KYB, new approval Payments / Compliance Decision statuses For each question classify the market as: Cleared Current structure is supportable based on verified advice/requirements. Configuration required Market can launch, but product/payment/operational changes are needed. Professional determination required Legal, regulatory, licensing, or tax advice is still required. Provider review required PSP, acquirer, bank, or method approval remains open. Structural blocker Current business/payment architecture cannot launch without material change. This should be used as an operational planning tool, not a compliance certification.

D. Internal-link plan I would use four primary links in this section. The brief specifically warns against turning the section into a legal directory. Recommended anchor text Destination Purpose Link type KYC requirements by country KYC Requirements by Country Deep dive when country-specific identity/business verification differs Specialist compliance page how geographic expansion triggers re-underwriting How Geographic Expansion Triggers Re-Underwriting Explain why an existing PSP approval may need reassessment Specialist compliance/underwriting page whether you need a local entity to accept payments Do You Need a Local Entity to Accept Payments? Route entity-structure questions out of this section Entity/settlement specialist page Contextual anchor tied to merchant model, e.g. compliance requirements for marketplaces Relevant Business-Model Compliance page Handle vertical-specific regulated questions Business-model compliance page Country-guide rule Only add a Country Payment Guide if the published section introduces an actual jurisdiction-specific example. For example, if an EU example later expands into France or Germany specifically, link that country guide there. Do not insert a generic country-guide link simply because regulation varies by country. Reciprocal links back to the pillar Recommend these natural anchors from supporting pages: * international market-entry payment requirements * payment challenges when entering new markets * international payment expansion

* regulatory considerations in global payment expansion

E. SEO support Suggested H2 Regulations, Licensing and Tax Retain exactly as specified. Suggested H3s Payment availability does not equal permission to launch Which compliance questions change by market? Regulation versus provider underwriting The Market-Entry Compliance Question Map Move compliance onto the market-entry critical path These preserve broad strategic search intent without competing directly with country-specific legal or KYC pages. Secondary semantic terms Use naturally: * international payment regulations * payment compliance by country * international payment compliance * market entry compliance * payment licensing * merchant licensing * payment regulation by country * PSP underwriting * geographic re-underwriting * cross-border ecommerce tax * international ecommerce VAT * merchant entity requirements * payment provider policy * consumer payment requirements * regulated activity * international tax compliance Featured-snippet opportunity A concise answer box could appear immediately after the opening: Why can regulation delay international payment expansion? Because technical PSP coverage does not establish that a merchant’s specific product, legal entity, payment flow, licensing position, consumer obligations, tax treatment, or acquiring configuration is approved for that market. Those dependencies should be reviewed before the launch architecture is fixed. Supporting visual Market-Entry Compliance Question Map Recommended presentation: TARGET MARKET | +--> BUSINESS

| Can we offer the product? | +--> MERCHANT | Does the entity structure work? | +--> PAYMENTS | Is the configuration supported? | +--> LICENSING | Is authorization required? | +--> CONSUMER | Do customer obligations change? | +--> TAX | What must Finance verify? | +--> PROVIDER Is re-underwriting required?

LAUNCH CRITICAL PATH Use visual badges for: * Cleared * Configuration required * Professional determination * Provider review * Structural blocker Alt text Market-entry compliance question map showing the business, merchant entity, payments, licensing, consumer, tax, and PSP or acquirer review questions a merchant should investigate before launching payments in a new country.

F. Evidence and verification plan Because this section deals with highly time-sensitive law, tax, and provider requirements, the publication version should keep its factual claims deliberately high-level unless a primary source is cited. Claims currently grounded by primary sources Risk-based compliance is not one universal checklist FATF’s current recommendations support a risk-based approach in which measures should be proportionate to identified risks. Use this only as general AML/CFT framing. FATF recommendations are standards; they are not a substitute for domestic law. Network/payment acceptance has non-technical merchant requirements Visa’s current April 2026 rules contain separate acceptance, merchant-agreement, risk, licensing, and regional requirements. This supports the article’s distinction between technical connectivity and approved merchant/payment configuration. Do not infer that Visa rules themselves determine whether a merchant may legally operate its underlying business. Business-model obligations can differ The EU Digital Services Act is a valid example of a regulation imposing differentiated obligations on types of online intermediary services such as online marketplaces. Use it only as an example. Do not imply every ecommerce merchant falls within the same DSA obligations. International tax obligations evolve

The European Commission’s current ecommerce VAT guidance was updated in July 2026 and explicitly incorporates future changes from the VAT in the Digital Age reforms. This is useful evidence for the editorial point that tax/invoicing assumptions require current verification.

Claims requiring country-specific primary research before publication Any statement that a particular market: * Requires a local entity * Requires a local bank account * Requires a merchant license * Requires a particular tax registration * Requires local invoicing * Restricts a merchant category * Requires specific subscription disclosures * Requires data localization * Requires specific authentication * Requires a named payment license * Treats a platform as a regulated payment institution should be checked against: 1. Current legislation 2. Regulator or government guidance 3. Tax authority where applicable 4. Relevant payment/acquiring rules 5. Qualified local legal/tax advice for consequential conclusions

Law-versus-policy fact-check requirement Every consequential claim should be labeled internally as one of: * Law/regulation * Regulator guidance * Tax rule * License condition * Card/payment-network rule * Acquirer requirement * PSP policy * Merchant policy If the editorial team cannot assign the claim confidently, do not publish it as a regulatory fact.

Provider claims requiring direct verification Before stating that a PSP/acquirer requires re-underwriting for a specific expansion, verify: * Merchant * Existing approved countries * New customer country * Merchant entity * Product/business model * Merchant category * Payment method * Acquirer * Expected volumes * Settlement configuration Do not say geographic expansion always triggers re-underwriting. The article should retain: “may trigger” or “can require” unless a provider-specific rule is sourced.

Tax claims requiring Finance/tax review Verify before publishing country examples involving: * VAT * GST * Sales tax * Place of supply * Tax registration * Marketplace deemed-supplier rules * Digital services tax * Import tax * Invoicing * E-invoicing * Withholding * Permanent establishment * Repatriation Do not let the payments team become the apparent source of tax advice.

* Merchant onboarding/re-underwriting by country * KYC/KYB requirements by market * Merchant-category eligibility * Business-model restrictions * Local acquiring eligibility * Entity requirements * Local bank requirements * Licensing support * Compliance review * Tax/invoice capability * Geographic expansion support * Regulatory update processes Avoid wording such as:

unless an extremely specific verified service supports the claim.

G. Human review recommendation This section needs more cross-functional review than most of the pillar because the failure modes sit between organizational functions. Primary reviewer — International payments compliance/legal lead Validate law-versus-provider distinctions, regulated-activity framing, entity issues, and licensing language. Tax reviewer — International tax specialist or merchant tax lead Review VAT/GST/invoicing language and any future jurisdiction-specific examples. Payments/acquiring reviewer — Head of Payments or acquiring specialist Validate merchant eligibility, provider approval, network/acquirer layers, and re-underwriting framing. Merchant onboarding/underwriting reviewer Review claims about geographic expansion, category changes, additional review, and KYC/KYB. Product/business-model reviewer where needed Particularly useful for marketplace, subscription, gaming, travel, digital goods, or other business-model examples. The section should pass one final editorial test: A reader should finish understanding that “our PSP operates there” is only one line in a market-entry compliance assessment—and that the expensive mistakes occur when the other lines are discovered after the launch has already been designed.