Does a Merchant Need a Payments Licence?
Does a Merchant Need a Payments Licence? For most ordinary merchants, accepting payment for the business's own goods or services is not, by itself, the same thing as operating a regulated payment service for other people. That distinction is the most useful starting point. A reta
Does a Merchant Need a Payments Licence?
For most ordinary merchants, accepting payment for the business's own goods or services is not, by itself, the same thing as operating a regulated payment service for other people.
That distinction is the most useful starting point.
A retailer charging a customer's card for merchandise it sells is one thing.
A SaaS company collecting its own subscription fee is another version of the same basic commercial relationship.
A platform that collects money from buyers, keeps it pending, divides it among sellers, and later transfers the funds is doing something materially different.
So the practical answer is:
An ordinary merchant generally should not assume it needs its own payments licence merely because it accepts customer payments through a bank, acquirer, or PSP. The regulatory question changes when the business starts providing payment services to third parties, controlling or transmitting their funds, operating payment accounts, issuing stored value, or otherwise performing activities that a jurisdiction treats as regulated payment activity.
This is not a global exemption. The conclusion depends on the actual payment flow, contracts, jurisdiction, and role of every participant. That qualification is central to the article brief.
Current UK FCA guidance gives an unusually clear example: simply accepting a debit or credit card as payment for your own goods or services does not generally amount to providing the regulated payment service of executing card transactions. The FCA uses a restaurant accepting a customer's card to pay for a meal as its example.
The same guidance takes a very different view of an ecommerce platform that collects buyer money and later remits funds to third-party merchants: depending on the precise arrangement and any applicable exclusion, that platform can be providing regulated payment services and may need authorisation or registration.
That is the line merchants need to understand.
Being paid is not the same thing as being in the payments business.
Merchant vs payment service provider: what is the difference?
A merchant's primary commercial activity is usually selling something.
A payment service provider's regulated activity is, depending on the jurisdiction and permissions involved, providing services that enable or execute payments for payment-service users.
The UK's Payment Services Regulations framework, for example, covers regulated categories including operation of payment accounts, execution of payment transactions, acquiring payment transactions, money remittance, payment initiation, and account information services.
That leads to a useful distinction:
Ordinary merchant model
Payment-service model
Customer owes the business for the business's own product/service
Business provides payment functionality involving another party's money
Payment settles toward the merchant as payee
Business may collect, hold, control, transmit, acquire, or route funds for others
PSP/acquirer provides payment infrastructure
Business itself may be providing part of the regulated payment service
Merchant uses a payment method
Business may operate payment accounts, payment instruments, money transmission, acquiring, or related services
Main business is the underlying product/service
Payment functionality can be a business activity in its own right
The names a company gives itself do not determine the answer.
Calling a product:
“checkout infrastructure”
rather than:
“payment services”
does not change who controls the money.
Nor does calling yourself:
“a marketplace”
automatically determine whether you require a licence.
Regulators examine the activity and contractual structure.
What does an ordinary merchant payment flow look like?
Consider an online retailer selling its own inventory.
CUSTOMER
|
| buys retailer's product
v
MERCHANT
|
| sends payment request
v
PSP / ACQUIRER / PAYMENT INFRASTRUCTURE
|
| payment is processed and settled
v
MERCHANT
The merchant is the seller and payee.
It uses regulated financial/payment infrastructure to collect the price of its own product.
In the FCA's current perimeter guidance, the simple act of accepting payment by debit or credit card for the merchant's own goods or services is not generally treated as the merchant itself providing the regulated execution-of-payment-transactions service.
A SaaS company collecting:
$50/month for its own software subscription
can have the same broad payment relationship.
The fact that:
billing is recurring;
a PSP stores a token;
the payment crosses a card network;
an acquirer settles the funds
does not by itself convert the SaaS merchant into the PSP.
Using a PSP does not normally make the merchant the payment institution
This is an important point for companies entering online payments for the first time.
The merchant and PSP perform different functions.
The merchant can:
offer the product;
determine its price;
create the order;
request payment;
provide refunds;
manage the customer relationship.
The PSP, acquirer, bank, or other regulated participant can perform the regulated payment-service functions applicable to its role.
Current FCA guidance likewise distinguishes merchant acquiring from the merchant being paid. Its definition of acquiring involves a payment service provider contracting with a payee to accept and process transactions resulting in funds being transferred to that payee.
So:
Using payment infrastructure is not the same as becoming payment infrastructure.
But the analysis can change if the merchant starts doing more than collecting its own receivables.
When can a merchant cross into regulated payment activity?
The most useful warning sign is this:
The money no longer belongs only to you.
That is not a legal test by itself.
It is a strong signal that the payment flow deserves closer regulatory analysis.
The brief highlights several business-model changes that should trigger that review: marketplace payments, holding seller money, payment splitting, customer-to-customer transfers, wallets and stored value, payment accounts, embedded financial services, and payment services offered to other merchants.
Marketplace or platform payments
Consider a marketplace:
BUYER
|
| pays $100
v
PLATFORM
|
| keeps $15 commission
| seller is economically due $85
v
SELLER
That looks simple from a product perspective.
The regulatory questions are more important:
Who legally receives the buyer's $100?
Does payment to the platform discharge the buyer's obligation to the seller?
Does the platform control an account containing seller money?
Who instructs the transfer of the seller's $85?
Who contracts with the seller for payment services?
Does a licensed PSP hold and split the funds without the platform ever possessing them?
Those distinctions can determine whether the platform itself is providing a payment service.
In the UK, FCA guidance specifically addresses ecommerce platforms that collect buyer funds and remit them to merchants. It says a platform providing payment services as a regular occupation or business activity will need to consider authorisation or registration if no exclusion or exemption applies. The FCA also identifies escrow-style arrangements as an example that is likely to involve regulated payment services.
That is why Marketplace Payment Licensing deserves its own deeper treatment.
Holding seller or customer funds
A business should pay particular attention when it receives money that economically belongs to another person and retains it before forwarding it.
The regulatory significance depends on jurisdiction and structure, but custody or control of third-party funds frequently changes the analysis.
For example, the UK FCA's ecommerce-platform guidance treats an arrangement where a platform controls or manages an account containing buyer funds and subsequently transfers corresponding amounts to the seller as potentially different from a simple commercial-agent arrangement.
The operational question should therefore be:
At each point in the flow, whose money is this and who can decide where it moves next?
That is more useful than merely asking whether the company's database contains a field called:
balance.
Splitting payments
“Split payments” is a product description, not a legal conclusion.
There is an important difference between:
Model A
The marketplace receives $100 and itself determines/transfers $85 to a seller.
and:
Model B
A licensed payment provider receives the funds and executes an allocation under a regulated platform/payment arrangement without the marketplace itself taking possession of seller funds.
Both product interfaces may display:
$15 marketplace fee / $85 seller share.
The underlying funds flow is different.
The fact that a merchant calculates an economic split therefore does not automatically prove that it is providing regulated payment services.
But split-payment functionality is a strong reason to document:
who receives the money;
who holds it;
who has legal control;
who contracts with each payee;
who executes the transfer.
Transferring money between customers
The analysis changes materially if customers can place money into the business's system and direct it to other users.
A service resembling:
Customer A → platform → Customer B
is not the same transaction as:
Customer → merchant for merchant's own subscription.
In the United States, for example, FinCEN's federal money-transmitter definition focuses on accepting currency, funds, or other value from one person and transmitting it to another person or location, while also making clear that classification depends on the facts and circumstances and includes specified limitations.
A peer-to-peer transfer feature therefore deserves its own licensing analysis rather than being treated as an extension of ecommerce checkout.
Wallets and stored value
A merchant can also cross into a different regulatory category when it creates monetary value that customers can store and later spend.
The important distinction is between something such as:
merchant credit redeemable only with that merchant
and:
monetary value designed to be used as a broader payment mechanism.
The regulatory treatment varies by jurisdiction.
In the UK, electronic money is defined around electronically stored monetary value representing a claim on the issuer, issued on receipt of funds for making payment transactions and accepted by persons other than the issuer, subject to applicable exclusions.
That is why an apparently simple product request:
“Can we let customers keep money in an in-app wallet?”
can move a project from ordinary merchant billing into a more complicated regulatory design discussion.
The dedicated Payment Institution vs Electronic Money Institution article should own that distinction in depth.
Offering payment accounts
Allowing users to maintain a genuine payment account and use it to make or receive third-party payments can also move a business toward regulated payment activity.
Under the UK framework, payment services expressly include services relating to payment accounts and the execution of payment transactions. The FCA describes a payment account as an account used for execution of payment transactions and emphasizes the account's purpose and functionality when determining the perimeter.
A merchant ledger used internally to record:
customer owes us $50
is not automatically the same thing as operating a payment account.
Again, functionality matters more than terminology.
Offering payments to third-party merchants
A SaaS company may begin as:
software business accepting its own subscription fees.
Then it adds:
That can fundamentally alter the regulatory analysis.
If the SaaS business merely embeds technical functionality from a regulated PSP and the PSP contracts for and provides the relevant payment service, that differs from the SaaS company itself contracting with merchants to acquire, transmit, or provide other regulated payment services.
UK FCA guidance specifically notes that merely providing technical services such as payment data processing, storage, terminals, or gateways does not itself constitute acquiring. It separately says that “master merchants” or payment facilitators contracting with payees for acquiring services can fall within acquiring.
EU PSD2 contains a related distinction: technical service providers that support payment services without entering into possession of the funds can fall outside the payment-service scope for those technical activities, apart from separately regulated payment-initiation and account-information services.
This creates an important product-design question:
Are you embedding someone else's regulated payment service—or have you started providing the payment service yourself?
Does handling payment data require a payments licence?
Not necessarily.
Payment processing can mean several different things.
A software company might:
format API requests;
tokenize identifiers;
store transaction metadata;
display payment status;
provide checkout software;
maintain gateway infrastructure.
That technical involvement is not necessarily the same thing as taking possession or legal control of customer funds.
Both current UK guidance and the EU PSD2 framework recognize circumstances where technical services supporting payments can be distinguished from the regulated movement of funds.
But technical architecture alone is not sufficient to decide the perimeter.
A company that calls itself a “technology provider” can still be providing a regulated payment service if its actual contractual and funds-flow role fits the relevant legal definition.
The U.S. shows why labels alone are dangerous
There is no single U.S. licence simply called:
“the ecommerce payments licence.”
At the federal Bank Secrecy Act level, FinCEN's definition of money transmitter is facts-and-circumstances based. It contains limitations for a person acting only as a qualifying payment processor and for a person accepting/transmitting funds only as an integral part of that person's own sale of goods or provision of non-money-transmission services.
FinCEN's payment-processor guidance also illustrates that even the processor limitation depends on the actual structure: its published framework refers to factors such as facilitating payment for goods/services, using qualifying clearance and settlement systems, operating under a formal agreement, and having an agreement at least with the seller or creditor receiving the funds.
State money-transmission laws remain a separate layer. The Conference of State Bank Supervisors maintains state-by-state information on agent-of-payee exemptions and notes that state money-transmission frameworks continue to be implemented through state law even as states adopt a model modernization framework.
California provides a useful illustration. Its regulator has published payment-processing opinions in which receiving money for transmission could fall within the state's Money Transmission Act but a specific agent-of-payee exemption applied because the particular statutory conditions were satisfied. The regulator emphasizes that these conclusions depend on the stated facts and circumstances.
So:
A federal conclusion does not automatically answer every state licensing question.
Does using a PSP remove payment licensing concerns?
It can substantially change the analysis.
It does not make the question disappear.
A licensed or otherwise appropriately regulated PSP can perform payment functions that the merchant may not want—or be authorised—to provide itself.
That can allow the merchant to focus on:
selling its own product
while the provider handles:
acquiring / payment execution / settlement infrastructure / other authorised payment services
according to the specific relationship.
But the merchant still needs to understand the contract and money flow.
Ask:
Who is the PSP's customer?
Who is the payee?
Whose merchant account is used?
Who receives the funds?
Does the PSP hold seller balances?
Can the merchant instruct transfers between third parties?
Is the merchant merely passing data to the PSP, or is it contractually providing payment services to another business?
Using a PSP is an operating-model choice.
It is not a generic legal exemption.
Merchant of Record changes the payment relationship—but is not a magic compliance exemption
A Merchant of Record (MoR) arrangement can materially change the relationship among the underlying business, customer, PSP, and payment system.
Depending on the specific contract and jurisdiction, the MoR can become the customer-facing merchant for the transaction and take responsibility for defined aspects of payment acceptance, refunds, disputes, tax, or related transaction operations.
But the term:
Merchant of Record
is not itself a universal payments-licensing exemption.
The underlying business can still retain responsibilities relating to its product, service, data, contractual obligations, regulated activity, seller relationships, or other local requirements. The brief explicitly requires MoR to be treated as a change in allocation of responsibility rather than something that eliminates every regulatory obligation.
The useful launch question is therefore not:
“Does an MoR mean we don't need compliance?”
It is:
“Which exact regulated, tax, payment, consumer, and operational responsibilities move to the MoR under this model, and which remain with us?”
The separate Merchant of Record Regulatory Responsibilities article should own that analysis.
Three merchant models, three different regulatory questions
Example 1 — Online retailer selling its own inventory
The retailer buys or manufactures its products.
Customers buy from the retailer.
The retailer accepts card and local payment methods through its PSP.
Funds settle to the retailer under its merchant arrangement.
Core licensing question:
Is the retailer merely accepting payment for its own goods?
Under current UK FCA guidance, that ordinary card-acceptance activity does not generally amount to the retailer providing the regulated payment service itself.
Other compliance:
Still potentially relevant.
Example 2 — SaaS company collecting its own subscriptions
The SaaS business sells access to its own software.
Its customers pay monthly.
A PSP processes recurring card or bank payments.
Core licensing question:
Is the company simply collecting its own subscription receivable?
If yes, that is structurally different from providing payment services to third-party merchants.
Now imagine the same SaaS company adds:
“Our customers can use us to accept payments from their customers.”
The payment-perimeter analysis needs to be reopened because the SaaS business may now be participating in third-party payment activity.
Example 3 — Marketplace collecting and paying sellers
The marketplace has thousands of sellers.
A buyer pays $200.
The platform keeps a commission and later sends the balance to the seller.
Now the business must determine:
who is selling to the buyer;
who receives the buyer's payment;
whether the platform controls seller funds;
who executes the transfer;
whether the PSP, platform, or seller provides each payment service;
whether a marketplace, commercial-agent, agent-of-payee, payment-facilitator, MoR, or other relevant legal structure applies in that jurisdiction.
Current FCA guidance demonstrates how significantly this can change the licensing analysis compared with an ordinary retailer.
Accepting payments internationally adds another layer
A business can avoid providing regulated third-party payment services and still face substantial international payment-compliance work.
That is because:
payment licensing ≠ all payment compliance.
The precise position varies by market.
A merchant expanding internationally may need to consider:
whether its PSP/acquirer can lawfully serve it in that market;
local consumer-protection rules;
card and payment-method requirements;
tax;
privacy/data rules;
sanctions;
currency/FX requirements;
local registration or entity requirements;
cross-border payment rules.
The regulatory environment itself can also change while a merchant is preparing to launch. In the EU, for example, the European Commission's current payment-services timeline shows that PSD2 remains under legislative revision: the Council and Parliament reached political agreement on the PSD3/Payment Services Regulation package in November 2025, and the Council confirmed final compromise text in April 2026. Businesses building a future EU payment model should therefore recheck the applicable framework immediately before launch rather than relying on an old PSD2 summary.
This is exactly why Cross-Border Payment Regulations and Regulatory Requirements by Market should remain separate cluster pages rather than being squeezed into one merchant-licensing article. The broader cluster is explicitly designed to help businesses understand how licensing choices can slow or reshape launches.
No payment licence does not mean no compliance
This is one of the most important distinctions in the article.
A merchant can correctly conclude:
“We are not providing a regulated payment service that requires our own PI licence under this structure.”
and still have substantial obligations.
For card acceptance, PCI SSC states that PCI DSS applies to entities involved in payment-card processing and that even a merchant outsourcing all payment processing retains responsibilities relating to the third-party provider and compliance validation.
For personal information involving EU individuals, the GDPR can apply to companies established in the EU and to certain companies outside the EU offering goods or services to people in the EU; the Commission emphasizes obligations such as lawful processing, purpose limitation, data minimisation, accuracy, security, and accountability.
For U.S. sanctions, OFAC states that U.S. persons must comply with applicable sanctions and encourages risk-based compliance programs; its guidance also recognizes sanctions exposure for businesses engaged in online commerce and payment-related activity.
And merchants can separately face:
consumer-protection obligations;
refund and dispute rules;
tax obligations;
card-network rules;
contractual KYC/KYB requirements from payment partners;
industry-specific regulation.
None of those issues becomes a payment licence merely because it affects payments.
That distinction keeps launch teams from solving the wrong compliance problem.
KYC from your PSP does not mean you are a payment institution
Merchants sometimes interpret an extensive PSP onboarding process as evidence that the merchant itself is entering a regulated payment business.
That conclusion does not follow.
A PSP, bank, or acquirer can require extensive information about:
the business;
owners;
directors;
products;
transaction flows;
countries;
expected volume;
websites;
settlement accounts
because the provider has onboarding, risk, network, banking, and regulatory obligations.
The merchant's obligation to complete that due diligence is separate from the question:
Does the merchant itself require a payments licence?
Do not collapse:
provider KYC
into:
merchant licensing.
A better licensing test starts with the funds flow
Before asking a lawyer or regulator:
“Do we need a payment licence?”
document the proposed system.
Use a simple map:
WHO BUYS?
|
v
WHO SELLS?
|
v
WHO CONTRACTS WITH THE BUYER?
|
v
WHO ACCEPTS THE PAYMENT?
|
v
WHO LEGALLY RECEIVES / CONTROLS THE FUNDS?
|
v
DO THE FUNDS BELONG TO ANY THIRD PARTY?
|
v
WHO INSTRUCTS WHERE THEY GO NEXT?
|
v
ARE THEY HELD, SPLIT, STORED, CONVERTED
OR TRANSMITTED?
|
v
WHICH PSP / BANK / ACQUIRER PERFORMS
THE REGULATED FINANCIAL ACTIVITY?
This turns:
“We're an ecommerce platform with embedded payments.”
into facts that can actually be analyzed.
The brief uses the same merchant-first approach: actual fund flow, customer contracts, control of funds, third-party transfers, stored value, settlement, and participant location matter more than labels.
A Payment Licence Trigger Map
Use the following as a screening framework, not a legal test.
Proposed activity
Licensing signal
Sell your own product and accept payment through PSP
Usually lower direct payment-licensing concern; confirm locally
Collect your own SaaS subscription
Usually lower direct payment-licensing concern; confirm locally
Provide checkout software without possessing funds
Technical-service analysis
Collect buyer funds for third-party sellers
Elevated analysis
Hold seller funds before payout
Elevated analysis
Transfer funds between unrelated users
Elevated analysis
Provide acquiring/payment acceptance to other merchants
Elevated analysis
Issue broadly usable stored monetary value
E-money/stored-value analysis
Operate user payment accounts
Payment-services/account analysis
Provide payment initiation/account information services
Specific regulated-service analysis in relevant regimes
Perform FX as a service
Separate FX/licensing analysis may apply
Use an MoR
Responsibilities change; analyze the actual contract/model
The purpose is not to tell a merchant:
red = licence required.
It is to identify when an ordinary merchant-flow assumption is no longer sufficient.
How compliance slows launches when the model is unclear
The worst time to discover a licensing question is after the payment product has been built.
Imagine a platform spends six months developing:
customer wallet
→ internal balances
→ seller split
→ delayed withdrawal
→ cross-border transfers.
Then, two weeks before launch, somebody asks:
“Which regulated entity legally holds these balances?”
Now a design problem has become a launch problem.
The brief identifies this pattern directly: regulatory classification, licensing, local entities, safeguarding, banking relationships, AML/KYC controls, fund-flow changes, regulatory/provider due diligence, and country-specific processes can all delay a payment launch if resolved too late.
A much better sequence is:
commercial model
→ funds-flow design
→ regulatory analysis
→ provider/licensing choice
→ product architecture
→ implementation
→ launch.
Not:
build everything
→ ask compliance whether it is legal.
What options does a business have if the proposed model is regulated?
Discovering that a payment feature may be regulated does not necessarily mean:
abandon the product.
The business generally needs to compare several structural possibilities, subject to the actual jurisdiction.
Become licensed
This can provide greater direct control over the payment capability.
It also creates a regulated operating function with the corresponding application, governance, capital, safeguarding, compliance, reporting, audit, and supervisory requirements applicable to that licence and jurisdiction.
This is a strategic decision rather than simply a compliance project.
Partner with an appropriately regulated provider
The payment provider can perform defined regulated activities while the merchant/platform focuses on its underlying business.
The merchant still needs to design its contracts and product so that it does not inadvertently perform regulated activity outside the provider's role.
Redesign the funds flow
Sometimes the requirement is created by the architecture rather than the business goal.
Instead of:
platform receives seller money → platform later transfers it
a provider-controlled flow may be possible in which the regulated provider manages the seller funds according to an appropriate marketplace/platform arrangement.
Whether that solves the regulatory issue depends on the jurisdiction and contract.
Use an agent or other permitted provider model
Some regulatory regimes allow payment institutions or banks to provide services through appropriately registered or structured agents.
For example, the current UK PSRs framework includes an agent regime, while FCA guidance stresses that the agent provides the principal's payment services rather than purporting to provide the services independently.
Again, that is a jurisdiction-specific structure, not a global shortcut.
Consider a Merchant of Record model
An MoR can change who performs and assumes defined buyer-facing payment responsibilities.
The economic and operational trade-off is generally greater outsourcing of transaction responsibilities in exchange for less direct control over parts of the payment model.
The exact regulatory effect must be determined from the contract and target market.
Questions to answer before launching a new payment flow
Before product or engineering commits to the architecture, the business should be able to answer these questions:
What are we selling, and who is legally selling it?
Who contracts with the buyer?
Who is the payee?
Whose merchant/acquiring account processes the payment?
Who legally receives and controls the funds?
At any point do we hold money economically belonging to another person?
Do we split or transmit funds to third parties?
Can users transfer balances between each other?
Are we creating stored monetary value or a payment account?
Are we offering payment functionality to other merchants as a business service?
Which licensed or regulated providers participate, and exactly what do they perform?
Which countries or U.S. states are involved?
Is foreign exchange part of the service?
Which compliance obligations remain even if we do not require our own payment licence?
What changes if the payment provider, acquiring structure, or Merchant of Record changes?
If those answers are unclear, it is too early to declare:
“No payment licence required.”
Those public sources support a limited but useful conclusion:
The licensing position must still be determined for the merchant's actual business model, contract, payment flow, product, and jurisdiction.
FAQ: Does a merchant need a payments licence?
Does an ecommerce merchant need a licence to accept credit cards?
Not merely because it accepts cards for its own goods or services. Current UK FCA guidance, for example, says the simple act of accepting a debit or credit card as payment for your own goods/services does not generally constitute providing the regulated payment service of executing the card transaction. Other jurisdictions need their own analysis.
Does a SaaS company need a payment licence to collect subscriptions?
A SaaS company collecting payment for its own software is fundamentally different from a SaaS platform providing payment services to its customers. The analysis should be reopened if the product expands into collecting, controlling, holding, or transmitting third-party funds or providing regulated payment functionality to other merchants.
Using a PSP does not by itself make the merchant a payment institution. The PSP and merchant perform different roles. However, the merchant should examine its own activity rather than assuming the provider's licence covers anything the merchant chooses to build. Current UK guidance explicitly distinguishes ordinary merchant card acceptance from regulated payment services.
Does a marketplace need a payment licence?
Potentially, depending on its funds flow, contractual role, jurisdiction, and applicable exclusions or provider arrangements. A marketplace that merely calculates seller entitlements while a regulated PSP controls the funds can have a different regulatory position from a platform that itself receives, holds, and later remits buyer money to sellers. UK FCA guidance specifically warns that ecommerce platforms collecting and remitting merchant funds may be within the payment-services perimeter.
Does splitting a payment require a licence?
Not automatically. “Split payment” describes an economic or technical feature, not a regulatory conclusion. The relevant questions include who receives the funds, who controls them, who executes the transfers, and whether a licensed provider or the platform itself provides the payment service.
Does an in-app wallet require a payments licence?
It can introduce a substantially different regulatory analysis. If the wallet represents stored monetary value, permits third-party payments, or enables transfers, payment-services or electronic-money/stored-value rules may become relevant depending on jurisdiction. Current UK rules, for example, separately regulate qualifying electronic money.
Does a Merchant of Record mean the underlying business needs no payment licence?
Not as a universal rule. An MoR can change which entity is the customer-facing merchant and which transaction responsibilities it performs, but the underlying company's remaining obligations depend on the contract, service, jurisdiction, and business model. An MoR should be analyzed as an operating structure, not a blanket exemption.
Can a business need no payment licence but still have payment compliance obligations?
Yes. Payment licensing is only one compliance layer. Merchants can still face requirements related to card-data security, privacy, consumer protection, tax, sanctions, refunds, disputes, payment-network rules, and provider due diligence. PCI SSC, for example, says merchants that outsource all card processing still retain defined PCI DSS responsibilities.
The key question is not whether you accept payments
For an ordinary merchant, accepting customer payments is normally part of selling.
The licensing analysis becomes materially more important when payment becomes a service the business performs for someone else.
That often means asking whether the business:
holds someone else's money
moves money between other parties
operates payment accounts
issues broadly usable stored value
provides acquiring or payment acceptance to other merchants
initiates payments for users
or:
builds a marketplace flow in which the platform controls seller funds.
The correct starting point is therefore not:
“We process payments. Which licence do we need?”
It is:
“What exactly do we do in the payment flow, whose money is involved, and which regulated participant performs each activity?”
For a straightforward retailer or SaaS merchant, that analysis may confirm that the business can accept payments through its PSP without becoming a payment institution itself.
For a marketplace, wallet, embedded-finance product, or platform moving third-party money, it may reveal that the architecture needs a licensed provider, a different funds flow, an agency or platform arrangement, an MoR, or the company's own regulatory authorisation.
Resolving that question before engineering hard-codes the funds flow is one of the most effective ways to prevent compliance from becoming a last-minute launch blocker.
This article provides general information and does not constitute legal, regulatory, tax, financial, or compliance advice. Payment-services and money-transmission rules vary by jurisdiction and can depend heavily on contractual relationships and the precise flow and control of funds. Businesses should confirm the regulatory treatment of a proposed payment model with qualified counsel and, where appropriate, the relevant regulator and payment providers before launch.
🙂 🙂 🙂 🙂 🙂 🙂 🙂
Recommended title
Does a Merchant Need a Payments Licence?
The article should own one precise question: does an ordinary business need its own payment licence simply because it accepts money from customers, and what changes when that business begins providing payment functionality for other parties? That is the distinction at the center of the controlling brief.
SEO title
Does a Merchant Need a Payment Licence? A Practical Guide
Alternative:
Do Merchants Need a Payment Processing Licence?
The first is preferable because it leads with the exact search intent without implying that “payment processing licence” is one universal regulatory category.
Meta description
Most merchants do not need a payment licence simply to accept payment for their own goods or services. Learn when marketplaces, wallets, stored value, seller funds, embedded payments, money transfers, and other payment models can change the regulatory analysis.
URL slug
/solve/compliance-slows-launches/licensing-regulatory-requirements/does-a-merchant-need-a-payments-licence/
Short alternative:
/does-a-merchant-need-a-payment-licence/
Primary keyword
does a merchant need a payment licence
Secondary keywords
merchant payment licence
payment processing licence
ecommerce payment licence
licence to accept payments
merchant payments regulation
These are the targets established by the brief.
Search intent
Direct-answer informational + commercial investigation.
The reader is usually trying to launch or expand payments and determine whether accepting customer money changes the business into a regulated payment provider—or whether it can continue operating as an ordinary merchant using a licensed bank, acquirer, or PSP.
SEO / EDITORIAL GUIDANCE — NOT PART OF THE ARTICLE
Recommended featured-answer block
Place this within the first 150 words:
Most ordinary merchants do not need their own payment licence simply to accept payment for their own goods or services through a PSP or acquiring bank. The analysis can change when a business starts providing payment services to third parties—for example by holding seller funds, transferring money between users, operating payment accounts, issuing stored value, or providing payments to other merchants. The exact answer depends on the jurisdiction and funds flow.
This directly answers the search query without creating an unsafe universal exemption.
Recommended excerpt
Accepting payments for your own products is not the same thing as providing payment services to others. A merchant's licensing position can change when it starts holding seller funds, transferring money between third parties, issuing stored value, operating payment accounts, or embedding payments for other merchants. The key is to analyze the actual flow and control of funds rather than the company's label.
Internal links
The brief specifies four primary cluster links.
Suggested anchor
Destination
what activities payment licences actually cover
Payment Licensing Explained
when collecting and paying sellers changes the regulatory analysis
Marketplace Payment Licensing
how Merchant of Record changes regulatory responsibility
Merchant of Record Regulatory Responsibilities
rules that can change when payments cross borders
Cross-Border Payment Regulations
Additional natural links:
Payment Institution vs Electronic Money Institution when discussing wallets/stored value.
Money Transmitter Licensing in the U.S. section.
Foreign-Exchange Licensing when conversion itself becomes part of the service.
Regulatory Requirements by Market in the international-launch section.
Recommended anchor-text variations
Avoid repeatedly linking the exact phrase payment licence.
Use:
regulated payment services
marketplace payment licensing
payment-institution requirements
electronic money and stored value
U.S. money transmitter rules
Merchant of Record responsibilities
cross-border payment regulation
country-specific payment requirements
Recommended authoritative source set
Use primary sources wherever a specific regulatory claim survives into publication.
UK — FCA Payment Services perimeter guidance
The strongest direct source for the article's main SEO answer. The FCA explicitly distinguishes ordinary acceptance of payment for the merchant's own goods/services from regulated payment services and provides detailed ecommerce-platform examples.
EU — PSD2 and European Commission
Use EUR-Lex for the current PSD2 payment-services scope and exclusions, including technical-service and commercial-agent provisions. Use the European Commission's live payment-services timeline for the status of PSD3/PSR reform.
U.S. federal — FinCEN
Use FinCEN for money-transmitter definitions, facts-and-circumstances analysis, the payment-processor limitation, and funds integral to a company's own sale of goods/services.
U.S. states — CSBS and state regulators
Use CSBS to show that agent-of-payee and money-transmission treatment remains state-specific, then cite the relevant state regulator for any state-specific conclusion. California DFPI is a useful authoritative illustration of an agent-of-payee analysis.
Card-data compliance — PCI SSC
Use PCI Security Standards Council for the distinction between outsourcing card processing and retaining PCI responsibilities.
Privacy — European Commission
Use Commission GDPR materials for EU privacy claims rather than payment-industry summaries.
U.S. sanctions — OFAC
Use current OFAC guidance for U.S. sanctions claims.
Visual opportunity 1 — Merchant vs Payment Service
ORDINARY MERCHANT
CUSTOMER
↓
MERCHANT
Own goods/services
↓
PSP / ACQUIRER
Provides payment infrastructure
↓
MERCHANT RECEIVES ITS PAYMENT
PAYMENT-SERVICE SIGNAL
CUSTOMER / USER
↓
PLATFORM
Receives / holds / controls funds
↓
Determines transfer to
THIRD-PARTY SELLER / USER
Headline:
Getting paid is not the same as providing payment services.
Alt text:
Diagram comparing an ordinary merchant accepting payment for its own goods with a platform receiving, controlling, and transmitting third-party funds.
Visual opportunity 2 — Payment Licence Trigger Map
ACCEPT PAYMENT FOR YOUR OWN GOODS?
|
YES
|
v
Lower direct
licensing signal
|
v
DO YOU ALSO:
├─ hold third-party funds?
├─ pay sellers?
├─ transfer user money?
├─ operate payment accounts?
├─ issue stored value?
├─ provide acquiring?
└─ offer payment services
to other merchants?
|
+------+------+
| |
NO YES
| |
v v
Merchant Regulatory
compliance perimeter
analysis analysis required
Add prominently:
Screening framework only. Jurisdiction-specific analysis required.
Visual opportunity 3 — Marketplace Funds-Flow Test
BUYER PAYS
↓
WHO LEGALLY RECEIVES THE MONEY?
↓
WHO CONTROLS IT?
↓
HAS THE SELLER ALREADY BEEN PAID
LEGALLY WHEN THE PLATFORM RECEIVES IT?
↓
WHO INSTRUCTS THE NEXT TRANSFER?
↓
WHO HOLDS THE PAYMENT-SERVICE
CONTRACT WITH THE SELLER?
↓
WHICH REGULATED PSP / BANK /
ACQUIRER PERFORMS THE ACTIVITY?
Headline:
Regulators care about the flow, not the product label.
Visual opportunity 4 — Licensing vs Compliance
Question
Licensing
Broader compliance
Are we providing a regulated payment service?
✓
Do we need PI/EMI/money-transmitter authorisation?
✓
PCI DSS
✓
Privacy/data protection
✓
Sanctions
✓
Consumer requirements
✓
Refunds/disputes
✓
Tax
✓
Provider KYC/KYB
✓
Card-network requirements
✓
Headline:
“No payment licence required” is not the same thing as “no payment compliance required.”
High-value long-tail search opportunities
The final article naturally covers:
do I need a licence to accept online payments
does ecommerce need a payment licence
payment processing licence for ecommerce
does a SaaS company need a payment licence
do I need a licence to accept credit cards
do marketplaces need payment licences
does split payment require a payment licence
do embedded payments require a licence
do I need a licence to hold customer funds
do I need a licence for an in-app wallet
payment licence vs PSP
merchant vs payment institution
payment processor vs merchant
does using a PSP remove licensing requirements
Merchant of Record payment licence
payment licence for marketplace sellers
payment licence for platform business
U.S. merchant money transmitter licence
UK merchant payment institution licence
payment licensing for international merchants
Regulatory fact-check list before publication
Because this is a high-stakes regulatory article, revalidate immediately before publication:
UK
Current PSRs 2017 status.
FCA PERG 15 merchant-acceptance guidance.
Ecommerce-platform/commercial-agent guidance.
Payment-services agent regime.
Current e-money guidance.
EU
PSD2 current legal status.
Formal adoption/publication status of PSD3 and the Payment Services Regulation.
Transition/application dates if adopted.
Member-state implementation issues relevant to any specific example.
As of August 2026, current EU official sources show political agreement on the PSD3/PSR replacement package and subsequent confirmation of the compromise text, so this item is especially time-sensitive.
United States
Current federal FinCEN definition.
Payment-processor and integral-payment limitations.
States in which the business operates.
Agent-of-payee or payment-processor exemptions in each applicable state.
Whether NMLS licensing is required.
Do not write:
“FinCEN says we aren't a money transmitter, therefore we need no state licence.”
The state analysis is separate.
Amber-flag claims
Avoid these formulations:
“Merchants don't need payment licences.”
Too absolute.
“Every ecommerce company is exempt.”
No global exemption exists.
“If you're selling your own goods, you can never need a financial licence.”
Other products/activities can change the analysis.
“Using a PSP means the PSP's licence covers everything.”
Incorrectly broad.
“If money passes through your bank account, you are a payment institution.”
Not a universal legal test.
“If you never touch the money, you're automatically unregulated.”
Some regulated services, such as payment initiation, do not require possession of funds. Current UK rules specifically regulate payment initiation services.
“Split payments require a payments licence.”
Architecture and control matter.
“Marketplaces always need a payment licence.”
Provider and legal structure can change the result.
“Commercial agent solves marketplace licensing.”
Jurisdiction-specific conditions matter; in the UK the exclusion is narrow and the FCA provides detailed limits.
“An in-app wallet always means e-money.”
Depends on functionality and applicable definition/exclusions.
“Merchant of Record eliminates regulatory obligations.”
Explicitly contrary to the brief's required distinction.
“A payment licence is the only compliance issue.”
Incorrect.
Unsupported and should not be published.
merchant payment services for receiving customer payments;
Merchant and MoR/Terminal3 models for at least some documented payment methods.
Before stronger regulatory positioning, internally verify:
licences/registrations relied upon by that entity;
acquiring model;
merchant versus MoR structure;
Terminal3 contracting entity;
marketplace/platform model;
treatment of seller funds;
split-payment architecture;
payout structure;
safeguarding model where relevant;
merchant-account ownership;
supported jurisdictions;
local provider relationships;
FX role;
Do not publish:
The correct message is narrower:
A regulated payment-provider or MoR structure can change which entity performs payment activities, but a merchant still needs to assess its own business model and jurisdiction.
Cluster differentiation audit
Field
Does a Merchant Need a Payments Licence?
Primary question
Does accepting customer payments itself require a licence?
Core answer
Usually distinguish own-sale acceptance from third-party payment services
Primary audience
Merchants, SaaS, ecommerce, international businesses
Primary object
Merchant's role in funds flow
Main distinction
Accepting payment ≠ providing payment services
Key trigger
Third-party money/control
Marketplace boundary
Introduce risk; link to Marketplace Payment Licensing
E-money boundary
Introduce stored value; link to PI vs EMI
U.S. boundary
Introduce money transmission; link to Money Transmitter Licensing
MoR boundary
Explain model change; link to MoR Regulatory Responsibilities
International boundary
Explain additional analysis; link to Cross-Border Regulations
Compliance distinction
No licence ≠ no compliance
Primary framework
Payment Licence Trigger Map
Launch insight
Determine regulatory model before engineering hard-codes funds flow
Conclusion
Ask what the business does with whose money, not whether it “accepts payments”
This keeps the article firmly within its assigned role in the Licensing and Regulatory Requirements cluster rather than turning it into a general payment-licensing guide.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗