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.

•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

•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

•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

•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

•Consumer

Do local customer obligations change the payment experience?

Check:

•Disclosures

•Subscription terms

•Cancellation

•Refund

•Pricing

•Customer-service requirements

Owner: Legal / Product / Payments

•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

•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:

•Current legislation

•Regulator or government guidance

•Tax authority where applicable

•Relevant payment/acquiring rules

•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.