Payment Methods for Marketplaces
Payment Methods for Marketplaces: Designing Buyer Acceptance and Seller Payouts as Two Separate Systems A marketplace can successfully charge 10,000 buyers. If it cannot reliably pay 2,000 sellers, its payment system is still broken. That is the structural difference between mark
Payment Methods for Marketplaces: Designing Buyer Acceptance and Seller Payouts as Two Separate Systems
A marketplace can successfully charge 10,000 buyers.
If it cannot reliably pay 2,000 sellers, its payment system is still broken.
That is the structural difference between marketplace payments and ordinary ecommerce.
An ecommerce merchant usually begins with a relatively direct commercial problem:
customer → merchant
A marketplace introduces another party:
buyer → platform → seller
And once the platform takes a commission, delays seller availability, handles refunds, absorbs disputes, converts currency, retains reserves where applicable, or pays sellers across borders, that apparently simple transaction becomes a sequence of distinct financial states.
The buyer may have paid.
The seller may still not be payable.
The marketplace may have received settlement.
The seller may still not have received a payout.
And a later refund or dispute can reverse the economics after funds have already moved.
That leads to the core marketplace payment principle:
Buyer acceptance and seller payout should be designed as two systems—and reconciled as one ledger.
A marketplace that optimizes only the checkout side has solved only half of its payment problem.
Why marketplace payments are structurally different
Consider a hypothetical $100 marketplace order.
The buyer pays:
$100
Suppose the marketplace's commercial agreement gives it:
$15 platform commission
and the seller is economically entitled to:
$85 before other applicable adjustments.
It is tempting to represent that as:
Buyer → $100 → Marketplace → $85 → Seller
That diagram is too simple for real operations.
Between buyer payment and seller payout, the platform may need to answer:
Was the payment merely initiated or actually confirmed?
Was it authorized, captured, settled, or otherwise completed under that method?
Is the seller fully onboarded?
Is the seller permitted to receive payouts?
Has the order reached the state in which seller funds become available?
Is part of the seller balance reserved or pending?
Has a refund occurred?
Is there an open dispute?
Which party bears fraud or dispute exposure?
Which currency was the buyer charged?
In which currency is the seller balance maintained?
Which currency can the seller actually receive?
Has FX occurred?
Which fees were deducted?
What happens if the seller's bank rejects the payout?
The marketplace payment system therefore has at least three layers:
Pay-in
How the buyer pays.
Platform money state
How the platform attributes the transaction among buyer payment, platform economics, seller entitlement, adjustments, and risk.
Pay-out
How the seller ultimately receives usable funds.
Those layers can share one provider.
They do not become the same financial event merely because one provider handles them.
Do not select buyer payment methods before defining the transaction model
“Which payment methods should a marketplace offer?” sounds like a checkout question.
It should begin with marketplace mechanics.
Ask:
What is the buyer purchasing?
A physical product?
A professional service?
Accommodation?
Digital content?
A high-value collectible?
A recurring service?
A booking fulfilled months later?
Each changes:
fraud exposure
cancellation likelihood
transaction value
refund timing
dispute risk
fulfillment reversibility
seller risk
Then ask:
Who is legally and commercially selling the product?
The platform's precise role can materially change payment, contractual, tax, consumer-protection, and regulatory responsibilities.
That analysis must be jurisdiction-specific.
The payments consequence is simple:
Do not design the marketplace ledger until you know whose money each balance represents and under what model the platform receives, controls, or directs it.
This is not merely theoretical.
The UK FCA specifically warns that an online marketplace may be providing payment services when it receives customer money before passing it to sellers. Its guidance says receiving buyer money into an account in the platform's name—including some accounts with merchant acquirers—can potentially constitute regulated payment activity depending on the arrangement.
EU guidance similarly makes clear that marketplace exclusions such as the commercial-agent exclusion depend on the actual contractual role and business model, including whether the platform acts for the payer, payee, or both.
The architecture should follow the legal and commercial funds flow—not the other way around.
Buyer payment requirements
Once the marketplace model is clear, buyer acceptance can be designed.
The objective is not maximum method count.
It is sufficient coverage of the customers the marketplace actually wants to serve.
Evaluate buyer methods across:
customer access
market relevance
transaction-value fit
device fit
payment confirmation
authentication
refunds
disputes
fraud exposure
merchant/category eligibility
currency
processing economics
reconciliation
Cards
Cards can provide broad online acceptance and familiar ecommerce mechanics.
For marketplaces, however, their suitability also depends on:
authorization performance
authentication requirements
dispute exposure
delayed fulfillment
cardholder/merchant descriptors
refund behavior
seller-risk allocation
A card payment successfully captured from the buyer does not answer when the seller should be paid.
That is a separate policy decision.
Digital wallets
Wallets may improve payment access or checkout usability where customers already maintain eligible wallet credentials.
Marketplace teams should verify:
country availability
device/browser availability
transaction currency
merchant category
authentication behavior
refund path
underlying funding-method implications
Do not treat every wallet as a universally portable payment layer.
Bank-based payments
Bank-account payments can be useful where buyers:
prefer direct account payment
lack suitable cards
make relatively high-value purchases
expect a domestic bank-payment method
But the marketplace should evaluate:
confirmation model
asynchronous states
refund mechanics
fraud model
reconciliation
recurring suitability where relevant
A bank transfer reaching the platform and a seller payout leaving the platform may both involve banks while being completely different payment operations.
Local payment methods
Local methods deserve priority when they materially reach buyers who cannot otherwise complete the transaction.
The test is not:
Is this method popular in Country X?
It is:
Does this method create meaningful access for our target marketplace buyers, with confirmation, refund, fraud, and operational behavior our transaction lifecycle can support?
That distinction is important.
Pay-in coverage does not prove pay-out coverage.
The platform layer is where marketplace payment complexity accumulates
After the buyer pays, marketplaces need a ledger state that represents what happened economically.
A simplified model might contain:
Gross buyer payment
− platform commission
− payment costs where contractually allocated
± adjustments
− refunds
− dispute exposure where applicable
= seller balance
But even “seller balance” needs several possible states.
For example:
Pending seller balance
Economic amount attributed to a seller but not yet eligible for payout.
Available seller balance
Amount that has satisfied the platform's normal availability conditions.
Reserved amount
Funds subject to a reserve or risk control where contractually applicable.
Payout pending
Amount assigned to an initiated payout.
Paid
Payout reported as completed under the payout provider's authoritative state.
Failed payout
Payout could not reach the seller's destination account.
Negative seller balance
Refunds, disputes, fees, or adjustments exceed available seller funds.
These are ledger concepts, not universal scheme-defined statuses.
A marketplace should map them explicitly to whatever statuses its payment and payout providers actually expose.
Keep platform fee and seller funds separate
A marketplace commission is not simply whatever remains after paying the seller.
It should be represented explicitly.
For each marketplace transaction preserve:
Gross order amount
tax where relevant to the marketplace's accounting model
buyer payment cost
platform commission
seller gross entitlement
seller adjustments
refunds
disputes
reserve changes where applicable
seller net payable amount
payout fee where applicable
The exact accounting treatment depends on the marketplace business and applicable accounting/tax policy.
But the payment system should be capable of reproducing the money flow.
If Finance asks:
“Why did this seller receive €742.18?”
the platform should not need to reconstruct the answer manually from several PSP exports and a spreadsheet of commissions.
Seller onboarding is part of the payment product
Seller onboarding is often treated as a compliance task that happens before “the real payments work.”
For a marketplace, it is part of payments.
A seller who can list products but cannot become payout-eligible is not fully activated.
Depending on the payment model, provider, seller type, and jurisdiction, onboarding can require information concerning:
individual or legal-entity identity
business details
beneficial ownership
payout destination
bank-account ownership
merchant/business category
sanctions/risk screening
additional documentation
ongoing updates
FATF's customer-due-diligence framework requires regulated financial institutions, in applicable circumstances, to identify and verify customers and beneficial owners. Exactly which participant performs those obligations in a marketplace flow depends on the regulated payment model and jurisdiction.
That distinction matters.
Do not write:
“Every marketplace must KYC every seller in exactly the same way.”
Instead ask:
Which regulated participant is onboarding the seller for this payment/payout relationship, and what information does that participant require?
The marketplace UX then needs to collect or facilitate those requirements without letting sellers reach an apparent “ready to sell” state when payout activation is still unresolved.
Seller payout requirements
A seller payout is not simply “send a bank transfer.”
It is the completion of a different payment lifecycle.
A marketplace should determine:
Who can receive payouts?
Individuals?
Companies?
Sole proprietors?
Sellers in every target country?
Where can they receive them?
Domestic bank account?
Cross-border bank account?
Other supported payout destination?
In which currencies?
Buyer currency and seller payout currency may differ.
At what cadence?
on demand
daily
weekly
monthly
after fulfillment
after a hold period
depending on the platform/provider model.
At what minimum amount?
Small seller balances can make fixed payout cost economically significant.
What makes a seller payout-eligible?
Possible conditions include:
onboarding completed
bank details verified
minimum balance reached
order eligibility conditions met
reserve requirements satisfied
no compliance hold
no payout block
What happens when a payout fails?
Possible causes include:
invalid bank information
closed account
unsupported destination
beneficiary-name mismatch
compliance restriction
provider rejection
intermediary-bank issue
account-currency problem
Failure should create a recoverable state, not an orphaned finance exception.
Cross-border payouts remain an infrastructure problem
A marketplace serving buyers globally can create international seller demand faster than its payout infrastructure expands.
That gap deserves strategic weight.
The Financial Stability Board's 2025 assessment of the G20 cross-border-payments programme found that, despite policy progress, improvements had not yet translated into sufficient global end-user gains. It continued to identify cost, speed, access, and transparency as important cross-border payment concerns, with significant variation across regions.
The BIS/CPMI likewise frames faster, cheaper, more accessible, and more transparent cross-border payments as continuing objectives rather than solved infrastructure problems.
For marketplaces, that means:
“Seller bank account available” is not the same as “good seller payout experience available.”
Measure:
availability
payout time
payout cost
currency
failure
transparency
by seller country.
Merchant settlement is not seller payout
This distinction should be visible throughout the marketplace architecture.
Payment settlement
Depending on the provider model, the acquiring/payment provider may settle transaction proceeds to:
the marketplace,
a platform balance,
seller/submerchant balances,
another regulated arrangement.
Seller payout
A separate action moves an amount the seller is entitled to receive toward the seller's external destination.
These events can differ in:
timing
currency
provider
regulatory role
status
fee
reconciliation ID
failure mode
So avoid statements such as:
“The payment settled, so the seller was paid.”
Instead maintain:
buyer payment status
separately from
seller balance status
separately from
seller payout status.
The most useful marketplace payment state machine
A marketplace needs more than:
Paid / Refunded
A simplified transaction lifecycle might be:
Buyer checkout created
↓
Buyer payment pending
↓
Buyer payment confirmed
↓
Order accepted
↓
Seller entitlement calculated
↓
Seller amount pending
↓
Seller amount available
↓
Payout eligible
↓
Payout initiated
↓
Payout completed
But alternative branches matter.
Buyer-payment failure
Payment fails before seller entitlement.
Refund
Seller entitlement may need to be reduced or reversed.
Dispute
Marketplace may need to freeze, debit, reserve, or recover funds depending on the contractual model.
Payout failure
Seller entitlement remains, but the external payout did not complete.
Compliance hold
Seller may have an available commercial balance but be temporarily ineligible for payout.
A platform that compresses those states into one “paid” flag will eventually have reconciliation problems.
Refunds reconnect the buyer and seller systems
Refunds show why pay-in and pay-out cannot actually operate independently.
Suppose:
Buyer pays: $100
Marketplace fee: $15
Seller entitlement: $85
Seller has already received: $85
Buyer receives full refund: $100
Who bears the $100 economic reversal?
Possibilities depend on the marketplace's commercial and provider model:
seller balance is debited;
future seller payouts are offset;
reserve is reduced;
seller owes the marketplace;
platform absorbs part or all of the amount;
platform fee is returned fully, partially, or not at all;
payment/refund fees create additional cost.
None should be assumed.
The contract and provider implementation determine them.
This is why refund design needs both sides:
Buyer side
Can the original payment method be refunded?
Can it support partial refunds?
How long does the refund take?
In which currency?
Seller side
Which seller transaction is adjusted?
Has the seller already been paid?
Is sufficient seller balance available?
Can the account go negative?
How is recovery handled?
A buyer refund is therefore also a seller ledger event.
Partial refunds are especially important for marketplaces
Multi-item orders make partial refunds normal rather than exceptional.
One buyer order may contain:
Product A — Seller 1
Product B — Seller 2
Product C — Seller 2
If Product B is refunded, the platform needs to know:
refund amount
corresponding seller
platform-fee adjustment
seller-balance adjustment
tax/accounting adjustment where applicable
payment-provider refund record
remaining order balance
Do not calculate seller recovery from the total order alone.
Preserve line-item or allocation-level lineage where the business model requires it.
Disputes can arrive after seller payout
A marketplace's risk horizon can extend past payout.
A card dispute, fraud claim, service complaint, or other payment-method dispute may arise after:
the buyer received the product;
the seller fulfilled the transaction;
the seller was paid.
That creates a funding problem.
The marketplace needs a contractual and operational rule for:
Who bears the loss?
and:
How is the amount recovered?
Potential controls may include:
payout delay
seller reserves
risk-based payout limits
negative balances
future-payment offsets
additional seller verification
transaction review
These controls should be matched to the actual marketplace risk model.
Do not treat reserves as a universal marketplace requirement or arbitrary source of working capital.
Marketplace fraud is two-sided too
Ordinary ecommerce fraud analysis often focuses on the buyer.
Marketplaces can face adversarial behavior on both sides.
Buyer-side fraud
Examples include:
stolen credentials
account takeover
fraudulent payment instruments
friendly fraud
refund abuse
Seller-side fraud
Examples can include:
fake sellers
non-delivery
counterfeit or prohibited listings
compromised seller accounts
payout-account takeover
seller collusion
Buyer/seller collusion
A marketplace can also face attempts to use apparently legitimate transactions to manipulate payouts or move funds.
Therefore, asking:
“Is this buyer payment genuine?”
is not enough.
The platform also needs:
“Is the seller genuine, is the transaction commercially plausible, and should this seller be paid now?”
Seller-payout risk and buyer-payment fraud should feed the same risk architecture even if different models score them.
Payout-account takeover deserves separate controls
A high-value seller account can become an attractive target after it has accumulated a balance.
A fraudster may care less about generating fraudulent buyer transactions than about changing:
Seller bank account A
to:
Fraudster account B
shortly before payout.
Useful controls may include, depending on risk and UX:
strong authentication for payout changes
cooling-off periods
change alerts
account-owner verification
payout re-verification
device/risk signals
manual review for unusual changes
The correct controls depend on seller value, payout frequency, jurisdiction, and provider capabilities.
The broader lesson is:
checkout authentication protects buyer payments; payout authentication protects seller funds.
They solve different problems.
Currency creates a second two-sided system
A global marketplace should track at least four currency questions.
Buyer transaction currency
What currency does the buyer actually pay?
Platform ledger currency
In what currency is the seller entitlement represented?
Seller payout currency
What currency reaches the seller?
Marketplace reporting currency
What currency does Finance use for consolidated reporting?
These can differ.
Example:
Buyer pays:
£100 GBP
Seller's contract is denominated:
EUR
Seller payout account:
EUR
Marketplace group reporting:
USD
The marketplace must know:
when GBP became EUR
which FX rate applied
who performed conversion
what fee/spread applied
whether commission was calculated before or after conversion
how a later refund affects the same currencies
Do not create one ambiguous field called:
amount
for a marketplace transaction.
Avoid unnecessary FX loops
Suppose the buyer pays in EUR and the seller wants EUR.
A platform architecture that unnecessarily creates:
EUR → USD → EUR
may introduce:
extra conversion cost
FX exposure
reconciliation complexity
less predictable seller economics
Whether that path can be avoided depends on provider, entity, settlement, account, and regulatory arrangements.
The principle is not “always settle locally.”
It is:
Map every conversion and ask what business or regulatory requirement makes it necessary.
Detailed treasury and cross-border settlement strategy belongs in the Entity, Settlement & Cross-Border Funds cluster.
Marketplace Pay-In / Pay-Out Architecture
PAY-IN
Buyer
↓
Buyer payment method
Cards / wallet / bank payment / locally relevant method
↓
Payment initiation
↓
Authentication where required
↓
Provider / acquiring path
↓
Authoritative payment confirmation
↓
Marketplace order
Define for each stage:
owner
amount
currency
status
payment ID
failure state
refund capability
PLATFORM MONEY STATE
Gross transaction
↓
Platform commission
↓
Seller entitlement
↓
Pending / available state
↓
Reserve or adjustment where applicable
↓
Refund/dispute state
↓
Seller payable balance
Define:
ledger owner
source transaction
seller
currency
availability rule
adjustment history
negative-balance behavior
reconciliation ID
PAY-OUT
Seller payable balance
↓
Seller payout eligibility
↓
Payout instruction
↓
Payout provider / rail
↓
Seller account
↓
Authoritative payout status
Define:
payout owner
destination
currency
payout ID
fee
initiation time
completion time
failure reason
retry/recovery state
compliance status
Marketplace Payment Fit Matrix
Capability
Buyer pay-in
Platform layer
Seller pay-out
Customer/seller access
Can target buyers pay?
Can transaction be correctly attributed?
Can target sellers receive funds?
Geography
Is method live for buyer market?
Does entity/model support market?
Can seller country be onboarded?
Currency
Buyer transaction currency
Seller ledger/reporting currency
Seller payout currency
Identity
Buyer authentication where required
Seller/account linkage
Seller KYC/KYB and payout ownership where required
Confirmation
Payment success
Seller entitlement state
Payout completion
Fraud
Buyer/payment fraud
Buyer-seller collusion, balance manipulation
Seller/payout-account takeover
Refund
Original method refund
Reverse seller/platform economics
Recover from seller balance if applicable
Dispute
Payment-method dispute
Allocate liability
Recover after payout if applicable
Cost
Pay-in processing
platform operations/risk
Payout + FX cost
Failure mode
Buyer cannot pay
incorrect ledger state
seller cannot receive money
This is more useful than ranking payment methods from “best” to “worst.”
How to decide which buyer methods deserve priority
Classify methods by the access mechanism they provide.
Core
Methods necessary to cover a large share of the marketplace's target buyers with acceptable transaction and lifecycle performance.
Cards often belong here in card-heavy markets, but the exact portfolio is market-specific.
Market-access additions
Local wallets, bank methods, or other alternatives that reach meaningful buyer segments who cannot or will not complete through the core portfolio.
Transaction-specific additions
Methods suited to a particular:
ticket size
device
customer segment
vertical
market
Optional substitution methods
Methods that largely move already-successful volume from another method without material access, economics, or risk improvement.
Poor-fit methods
Methods whose:
refund mechanics
delayed confirmation
merchant-category restrictions
fraud exposure
transaction limits
operational burden
do not fit the marketplace transaction.
The same method can move between categories by country.
Seller coverage needs the same classification
For every seller market classify payout readiness.
Launch-ready
onboarding available
payout destination supported
required currency workable
compliance model clear
payout failure handling operational
reconciliation tested
Limited
Only certain:
legal entities
seller types
currencies
banks
payout models
are practical.
High-friction
Payout is technically possible but creates:
high fixed cost
long delays
repeated manual review
frequent bank rejection
unattractive FX
poor seller support experience
Not ready
The marketplace cannot reliably onboard or pay the seller population it wants to recruit.
A market with excellent buyer conversion but not-ready seller payouts is not a fully launch-ready marketplace market.
The two-sided market-entry test
Before entering a country, answer these questions separately.
Buyer readiness
Can target customers use payment methods they actually have?
Are the transaction currency and amounts appropriate?
Is merchant-category support confirmed?
Does authentication work on dominant devices?
Is authoritative confirmation fast enough?
Can the methods support required refunds?
Is fraud/dispute risk operationally acceptable?
Seller readiness
Can the intended seller type be onboarded?
Who conducts required KYC/KYB?
Can beneficial ownership be established where required?
Can sellers provide an acceptable payout destination?
Which currencies are supported?
What is payout cost?
What is expected payout timing?
What happens when payout fails?
Can the platform support negative balances/adjustments?
Are seller support and reconciliation ready?
Platform/regulatory readiness
Who legally receives the buyer funds?
Who is providing the payment service?
Does the platform take possession or control of funds?
Which exclusions or licences are relevant?
Who safeguards funds where required?
Who controls the seller balance?
Who initiates payout?
Who bears disputes?
What happens to funds during insolvency or provider failure?
Is the model approved for this jurisdiction?
The UK is a useful illustration of why this needs legal review: the FCA specifically identifies online marketplaces receiving and transmitting customer funds as businesses that may fall within payment-services regulation.
In the US, the position also cannot safely be reduced to “marketplaces are/aren't money transmitters.” FinCEN's payment-processor analysis is fact-specific, while state money-transmission regulation remains important; the CSBS says that, as of August 2026, 31 states had enacted its Money Transmission Modernization Act in full or in part.
Use legal counsel for the actual model.
Europe is also a moving regulatory target
Do not publish marketplace payment guidance implying that Europe's payment-services framework is static.
PSD2 remains foundational, but the EU has been developing its next payment-services framework.
In November 2025, the Council and European Parliament reached a provisional political agreement on a new Payment Services Regulation and revised directive framework; the Council explicitly said further technical work and final adoption were still required.
Therefore, before a European marketplace launch, verify:
legislation actually in force
national implementation where relevant
payment-provider licence/model
marketplace contractual role
commercial-agent analysis where relevant
safeguarding/funds treatment
seller onboarding obligations
authentication
payout requirements
Do not publish a roadmap proposal as though it were already effective law.
Cross-border payout data requirements are changing too
Global payout architecture is also being affected by efforts to improve cross-border payment transparency.
FATF revised Recommendation 16 in 2025 to improve consistency of payer/payee information in cross-border payments and clarify responsibilities along payment chains. FATF says the changes are intended to take effect by the end of 2030.
For marketplace architects, the immediate lesson is not to implement a 2030 rule prematurely.
It is:
Treat beneficiary identity and payout data as structured payment infrastructure, not free-text seller metadata.
A seller payout record should be designed for durable:
beneficiary identity
account details
payment references
country
currency
provider requirements
regulatory data
rather than whatever fields one bank transfer integration happens to accept today.
Marketplace reconciliation requires one transaction graph
A mature marketplace should be able to start with any one identifier and reconstruct the entire transaction.
From:
buyer order ID
find:
buyer payment
→ payment-provider transaction
→ gross amount/currency
→ platform commission
→ seller allocation
→ seller balance movement
→ refund/dispute adjustment
→ payout
→ seller destination
Similarly, starting from a seller payout should allow Finance to identify every included underlying transaction.
This is especially important when payouts aggregate many sales.
Avoid:
Payout = $18,453.72
with no machine-readable lineage to the orders that created it.
The most useful marketplace metrics are two-sided
Do not place buyer and seller performance in one blended “payments success” KPI.
Buyer side
Eligible payment completion rate
Successfully completed payments
÷ eligible payment attempts
Segment by:
country
payment method
device
transaction value
seller category where relevant
Method coverage
Target buyers with at least one viable method
÷ target buyer population or eligible checkout population
Define how coverage is estimated.
Refund rate
Refunded transactions
÷ completed transactions
Dispute rate
Disputed transactions
÷ relevant completed transactions
Define whether measured by count or value.
Fraud loss
Confirmed fraud loss
÷ relevant payment volume
Seller-side metrics
Seller onboarding completion rate
Sellers completing required payout onboarding
÷ sellers starting onboarding
Payout-eligibility rate
Active sellers currently eligible to receive payout
÷ active sellers requiring payout
Payout success rate
Successfully completed payouts
÷ initiated payouts
Payout latency
Time from:
defined seller payout eligibility event
to:
authoritative payout completion event
Do not measure only the time after the bank instruction was sent.
Failed-payout rate
Failed payouts
÷ initiated payouts
Segment by:
seller country
payout rail
bank/provider
currency
failure reason
Seller payout support rate
Payout-related seller contacts
÷ sellers receiving payouts
Platform-level metrics
Reconciliation exception rate
Transactions/payouts requiring manual reconciliation
÷ relevant payment or payout records
Negative-balance incidence
Seller accounts entering negative balance
÷ active sellers
Use this diagnostically, not automatically as evidence of fraud.
Payment cost per completed marketplace order
Buyer payment costs
allocated fraud/dispute cost
refund operating cost
payout cost
attributable reconciliation/support cost
÷ successfully completed marketplace orders
Seller payout cost per paid seller
Relevant payout and operational costs
÷ sellers successfully paid
Two-sided market readiness
Do not collapse buyer and seller coverage into one vanity percentage.
Report them together:
Buyer pay-in readiness: X
Seller payout readiness: Y
A marketplace market is constrained by whichever side cannot operate reliably.
How to test new payment methods
Suppose a marketplace adds a domestic wallet.
Do not ask only:
“How much wallet volume did we get?”
Measure:
Eligible buyers
→ wallet visible
→ wallet selected
→ payment completed
→ order completed
Then ask:
Would those customers have completed another way?
Measure:
incremental completed orders
card/wallet substitution
fraud
refunds
payment cost
support
And then examine seller economics.
Did the new payment method:
change transaction currency?
lengthen seller availability?
change refund mechanics?
increase reconciliation exceptions?
create a seller-balance currency mismatch?
A method can improve buyer checkout and make the back office worse.
The commercial result is the combination.
How to test a new seller payout market
Seller-market expansion deserves its own pilot.
Start with a controlled seller cohort.
Measure:
onboarding completion
time to payout eligibility
documentation failure
payout initiation
payout completion
payout time
bank rejection
FX
payout cost
seller support
reconciliation
A technically successful API call is not sufficient.
The test succeeds when a normal seller can:
onboard
→ earn
→ become eligible
→ receive funds
→ reconcile them
without disproportionate manual intervention.
What would disprove the market-entry hypothesis?
A marketplace should reconsider a market if:
local buyer methods improve selection but not completed orders;
buyer fraud/dispute cost overwhelms incremental revenue;
seller onboarding completion is poor;
a material seller segment cannot obtain an acceptable payout destination;
payout failure is persistently high;
payout FX makes seller economics unattractive;
manual review is required for a disproportionate share of sellers;
the legal/funds-flow model remains uncertain;
refund/dispute recovery regularly creates unrecoverable seller deficits;
reconciliation requires substantial manual reconstruction.
Strong buyer demand is not enough to override these failures.
When a marketplace needs method breadth
Additional buyer methods deserve integration when they provide at least one meaningful improvement:
Access
Buyers otherwise cannot pay.
Conversion
Eligible customers complete more transactions.
Transaction fit
The method fits the marketplace ticket size, device, or fulfillment model materially better.
Risk economics
The method improves total loss/payment economics.
Market-entry necessity
The marketplace cannot compete effectively in the target buyer segment without it.
Method breadth is harder to justify when the method:
largely substitutes existing successful transactions;
creates meaningful reconciliation cost;
has weak refunds;
increases operational exceptions;
introduces unsupported currency paths;
has uncertain marketplace eligibility.
The goal is not “more payment methods.”
It is more payable buyers at acceptable operating cost.
When a marketplace needs payout breadth
The equivalent seller principle is:
more payout methods are valuable when they create more payable sellers.
Payout expansion can matter when:
sellers lack access to an existing destination;
cross-border transfers are too expensive;
payout currency creates avoidable FX;
current payout speed is commercially unacceptable;
local seller expectations materially affect acquisition or retention.
But payout breadth also creates:
integration
compliance
reconciliation
support
treasury
failure-management
cost.
Do not add payout rails solely because they exist.
The marketplace launch gate
A useful executive launch decision is:
Buyer
Can enough target buyers pay?
Seller
Can enough target sellers become payable?
Platform
Can we correctly hold, attribute, adjust, reconcile, and direct the resulting financial states under the approved model?
If any answer is no, the market is not payments-ready.
That is the central difference between marketplace expansion and ordinary ecommerce expansion.
global card acceptance;
local payment methods;
bank-transfer, wallet, prepaid, cash, and other pay-in options;
fraud/risk services;
reporting;
international payment acceptance.
An experienced global payment provider can help a marketplace broaden buyer payment acceptance, localize the pay-in portfolio, manage payment reporting and risk, and reduce duplicated country integrations. Marketplace-specific seller onboarding, balance management, split-fund treatment, and seller payout capabilities should be verified separately for the marketplace's exact business model and countries.
That supports the argument without implying unverified functionality.
Final recommendation
A marketplace does not have one payments strategy.
It has a buyer-money strategy and a seller-money strategy, connected by a platform ledger and a set of contractual, risk, and regulatory rules.
That means market expansion should never be approved from a checkout-coverage spreadsheet alone.
A buyer can successfully pay while:
the seller is not onboarded;
payout destination is unsupported;
payout currency is impractical;
funds are under review;
a refund remains possible;
dispute exposure survives seller payout;
marketplace funds-flow regulation is unresolved.
Conversely, the ability to send sellers bank transfers is meaningless if local buyers cannot complete purchases.
The marketplace payment question is therefore not:
Which payment methods should we add?
It is:
Can the target buyer pay successfully, can the target seller become eligible and receive funds reliably, and can the marketplace account for every state between those two events?
That is two-sided payment coverage.
And for a marketplace, anything less is incomplete.
Original practical asset: Marketplace Pay-In / Pay-Out Architecture
BUYER
│
▼
PAY-IN METHOD
Card / Wallet / Bank / Local Method
│
▼
PAYMENT PROVIDER / ACQUIRING PATH
│
▼
AUTHORITATIVE BUYER PAYMENT STATUS
│
▼
┌────────────────────────────────────────┐
│ MARKETPLACE MONEY STATE │
│ │
│ Gross payment │
│ ├─ Platform commission │
│ ├─ Payment/refund adjustments │
│ ├─ Reserve where applicable │
│ └─ Seller entitlement │
│ │ │
│ ▼ │
│ Pending → Available → Payout-ready │
└────────────────────────────────────────┘
│
▼
SELLER PAYOUT INSTRUCTION
│
▼
PAYOUT RAIL
│
▼
SELLER ACCOUNT
│
▼
AUTHORITATIVE PAYOUT STATUS
Three identifiers that should never be conflated
Payment ID
Identifies buyer pay-in.
Seller ledger/allocation ID
Identifies the economic attribution.
Payout ID
Identifies movement to the seller.
A marketplace should be able to traverse all three directions.
Market-entry readiness checklist
Buyer acceptance
Target buyer countries defined
Required methods identified
Method eligibility verified
Transaction currencies verified
Device flows tested
Authentication tested
Confirmation states documented
Refunds tested
Partial refunds tested
Fraud model approved
Dispute model documented
Seller onboarding
Intended seller types defined
Country eligibility verified
KYC/KYB ownership assigned
Required documents defined
Beneficial-owner requirements verified
Payout account rules verified
Compliance holds modeled
Seller activation state separated from listing activation
Seller payout
Destination countries supported
Payout rails verified
Currencies verified
Payout cadence defined
Fees verified
Payout status model documented
Failed-payout recovery tested
Account-change controls tested
Seller support playbooks ready
Platform
Funds-flow model legally reviewed
Commission calculation tested
Seller ledger implemented
Reserve/hold logic defined where applicable
Refund allocation tested
Dispute allocation tested
Negative balance policy defined
Currency conversions mapped
Payment-to-payout reconciliation tested
Finance reporting approved
I used the uploaded Editorial Brief 5: Payment Methods for Marketplaces as the controlling brief. Current verification supports making the regulatory/funds-flow boundary unusually explicit: a marketplace that receives buyer funds before passing value to sellers can enter payment-services territory depending on jurisdiction and structure, so “we are only a marketplace” is not itself a regulatory answer.
The biggest editorial safeguard here is the distinction between settlement, seller entitlement, and payout. Many marketplace explanations collapse all three into “the seller gets paid,” but doing so hides the exact refund, dispute, currency, regulatory, and reconciliation problems that make marketplace payments materially different from ordinary ecommerce.
Editorial interpretation
The industry-specific payment problem this article owns: designing marketplace payments as two connected but operationally distinct systems: buyer pay-in and seller pay-out.
The customer who cannot adequately pay: a buyer whose available payment methods do not fit the local market, device, transaction value, authentication flow, or marketplace transaction—and, on the other side, a seller who cannot participate economically because the platform cannot onboard or pay them reliably.
The transaction characteristic driving payment-method fit: one buyer transaction can create several downstream money states: buyer payment, platform fee or commission, seller entitlement, reserve or adjustment where applicable, refund/dispute exposure, and eventual seller payout.
The merchant operating constraint: the marketplace must reconcile customer acceptance, seller balances, refunds, disputes, currencies, onboarding, and payouts without treating any one of those states as interchangeable.
Unique evidence anchor: a marketplace payment is not one money movement. Charging the buyer successfully is only the first half of the system.
Editorial position: a marketplace should not launch a market because buyer acceptance looks strong if seller onboarding, compliant funds flow, reconciliation, and payout remain unresolved.
Common assumption challenged: “Marketplace payments are ordinary ecommerce checkout plus seller bank transfers.”
Most important industry-specific distinction: merchant/acquirer settlement is not automatically seller payout.
Selected format: two-sided marketplace money-flow architecture.
Merchant decision: evaluate every country twice—first as a place where buyers need to pay, and separately as a place where sellers must become eligible, accumulate a valid balance, and receive funds successfully.
Proposed architecture
Charging buyers is only half the marketplace payment system
Why marketplaces create a different funds flow
Buyer payment requirements
The platform money-state layer
Seller onboarding and payout requirements
Merchant settlement versus seller payout
Refunds, disputes, reserves, and negative balances
Currency across the two sides
Marketplace Pay-In / Pay-Out Architecture
Market-entry readiness
Measurement
Which payment methods deserve priority
Final recommendation
Editorial interpretation
The industry-specific payment problem this article owns: designing marketplace payments as two connected but operationally distinct systems: buyer pay-in and seller pay-out.
The customer who cannot adequately pay: a buyer whose available payment methods do not fit the local market, device, transaction value, authentication flow, or marketplace transaction—and, on the other side, a seller who cannot participate economically because the platform cannot onboard or pay them reliably.
The transaction characteristic driving payment-method fit: one buyer transaction can create several downstream money states: buyer payment, platform fee or commission, seller entitlement, reserve or adjustment where applicable, refund/dispute exposure, and eventual seller payout.
The merchant operating constraint: the marketplace must reconcile customer acceptance, seller balances, refunds, disputes, currencies, onboarding, and payouts without treating any one of those states as interchangeable.
Unique evidence anchor: a marketplace payment is not one money movement. Charging the buyer successfully is only the first half of the system.
Editorial position: a marketplace should not launch a market because buyer acceptance looks strong if seller onboarding, compliant funds flow, reconciliation, and payout remain unresolved.
Common assumption challenged: “Marketplace payments are ordinary ecommerce checkout plus seller bank transfers.”
Most important industry-specific distinction: merchant/acquirer settlement is not automatically seller payout.
Selected format: two-sided marketplace money-flow architecture.
Merchant decision: evaluate every country twice—first as a place where buyers need to pay, and separately as a place where sellers must become eligible, accumulate a valid balance, and receive funds successfully.
Proposed architecture
Charging buyers is only half the marketplace payment system
Why marketplaces create a different funds flow
Buyer payment requirements
The platform money-state layer
Seller onboarding and payout requirements
Merchant settlement versus seller payout
Refunds, disputes, reserves, and negative balances
Currency across the two sides
Marketplace Pay-In / Pay-Out Architecture
Market-entry readiness
Measurement
Which payment methods deserve priority
Final recommendation
SEO metadata
Payment Methods for Marketplaces: Pay-Ins & Seller Payouts
H1:
Payment Methods for Marketplaces: Designing Buyer Acceptance and Seller Payouts as Two Separate Systems
Meta description:
Learn how marketplaces should design buyer payment methods, seller payouts, platform commissions, refunds, disputes, currencies, KYC/KYB, and two-sided market payment coverage.
URL slug:
/payment-methods-for-marketplaces/
payment methods for marketplaces
Secondary keywords:
marketplace payment methods
marketplace payments
payment processing marketplaces
marketplace seller payouts
marketplace checkout payments
global marketplace payments
marketplace payment infrastructure
pay sellers marketplace
Related entities:
marketplace payments
seller payouts
platform payments
payment acceptance
KYC
KYB
beneficial ownership
seller balance
payment settlement
merchant settlement
payout
marketplace commission
local payment methods
bank payouts
cross-border payments
payment reconciliation
Article excerpt:
Marketplace payment strategy is two-sided. The platform must give buyers viable ways to pay while ensuring sellers can be onboarded, become payout-eligible, and receive funds reliably. This guide maps the payment, ledger, refund, dispute, currency, compliance, and payout states that connect those systems.
Suggested structured data:
Article
BreadcrumbList
Use FAQPage only if the buyer-versus-seller scenarios below are published as an actual visible FAQ.
Internal-link plan
International Payouts for Marketplaces
Link from seller payout methods, cross-border payout friction, payout cost, and payout latency.
Entity, Settlement & Cross-Border Funds
Link from settlement currency, marketplace entities, treasury, and cross-border funds movement.
Local Payment Methods
Link from buyer-side country payment coverage.
International Payment Architecture
Link from payment states, orchestration, transaction IDs, reconciliation, and multi-provider architecture.
Bank-Based Payments
Link where bank-account methods are evaluated for marketplace buyer acceptance.
Digital Wallets
Link from wallet capability rather than repeating wallet mechanics.
Refunds and Currency Conversion
Useful additional link from cross-currency marketplace refunds.
Authoritative source recommendations
Financial Conduct Authority — marketplace payment-services guidance
Strong source for explaining why an online marketplace receiving customer funds before paying sellers can potentially be providing regulated payment services in the UK.
FCA Payment Services and Electronic Money Approach — May 2026
Use for current UK payment-services interpretation, safeguarding, authorisation, and perimeter analysis. The FCA identifies its May 2026 version as the current Approach Document.
European Banking Authority — commercial-agent marketplace analysis
Useful for demonstrating that marketplace payment exclusions depend on the exact contractual/business arrangement rather than marketplace branding alone.
European Commission / Council — EU payment-services framework
Use for current PSD2/PSD3/PSR status. As of the verified sources, Council and Parliament reached provisional political agreement in November 2025 while technical work/final adoption remained to follow.
FATF Recommendations
Use for customer/beneficial-owner due-diligence principles as they apply to regulated financial institutions participating in seller onboarding.
FATF Recommendation 16 update
Use for the evolving cross-border payment-transparency framework and structured payer/payee information. The revised requirements are intended to take effect by the end of 2030 rather than being described as current marketplace obligations today.
FSB / BIS CPMI cross-border payments programme
Use for current evidence that cross-border payment cost, speed, access, and transparency remain uneven and relevant to international payout strategy.
CSBS / FinCEN
Use for high-level US money-transmission perimeter awareness, while emphasizing that federal exemptions and state requirements are fact-specific.
Supporting visual
Marketplace Pay-In / Pay-Out Architecture
Format: wide three-column infographic.
LEFT: BUYER PAY-IN
Buyer
↓
Card / wallet / bank / local method
↓
Authentication
↓
Payment provider
↓
Payment confirmation
Metrics
payment completion
fraud
refunds
disputes
method coverage
CENTER: PLATFORM MONEY STATE
Gross transaction
↓
Platform commission
↓
Seller entitlement
↓
Pending / available
↓
Reserve or adjustment where applicable
↓
Refund / dispute state
Control questions
Whose funds?
Which currency?
What status?
Who bears loss?
What makes funds available?
RIGHT: SELLER PAY-OUT
Seller balance
↓
Payout eligibility
↓
Payout instruction
↓
Payout rail
↓
Seller account
Metrics
onboarding
payout success
payout latency
payout cost
failed payouts
seller support
Central callout
Buyer paid ≠ seller paid
Footer
Marketplace readiness = viable pay-in + viable platform money state + viable pay-out
Image alt text:
Marketplace payments diagram separating buyer payment acceptance from the platform commission and seller balance layer, followed by seller payout and payout status.
Proposed author and reviewers
Proposed author:
Recommended reviewers:
Marketplace payments specialist
Payouts specialist
Payment architect
Payment operations specialist
Risk/fraud specialist
Merchant finance/reconciliation specialist
Compliance specialist for regulatory funds-flow language
Do not state that review occurred until named individuals actually complete it.
Recommended metadata:
Last fact-reviewed: August 2026, with regulatory, payout-coverage, and provider-capability verification repeated immediately before publication.
Industry fact-check items
Verify:
Actual marketplace transaction model.
Physical/service/digital product categories.
Buyer and seller countries.
Typical transaction values.
Average fulfillment period.
Refund/cancellation profile.
Seller payout frequency.
Seller legal form.
Seller concentration.
Marketplace versus merchant-of-record treatment where relevant.
Dispute allocation.
Payment-method support fact-check items
For each recommended buyer method verify:
buyer country
merchant entity
marketplace eligibility
merchant category
transaction currency
transaction limits
device
authentication
payment confirmation
refunds
partial refunds
dispute model
recurring support where needed
settlement/reconciliation
Do not infer marketplace support from generic ecommerce support.
Merchant-eligibility fact-check items
Verify:
marketplace/platform merchant category
prohibited/restricted seller categories
physical versus digital goods
cross-border seller model
platform entity
buyer country
seller country
provider underwriting
local entity requirement
contractual marketplace approval
Recurring fact-check items
Relevant only where the marketplace sells recurring services or subscriptions.
Verify:
reusable credential
mandate/authorization
seller attribution across renewals
commission logic
customer cancellation
recurring refund
failed-payment handling
seller balance treatment
payout timing
Do not assume a marketplace's one-time buyer methods support recurring charges.
Refund/dispute fact-check items
Verify:
full refund
partial refund
multi-seller order refund
fee reversal
seller-balance adjustment
refund after seller payout
negative seller balance
dispute after payout
recovery model
currency
dispute evidence
provider liability allocation
platform liability
Fraud fact-check items
Verify which participant bears contractual responsibility for:
stolen payment credentials
buyer account takeover
seller account takeover
payout-account change fraud
counterfeit/non-delivery seller fraud
refund abuse
friendly fraud
buyer/seller collusion
prohibited activity
Do not claim a PSP or payment method eliminates marketplace fraud.
Payout fact-check items
Immediately before publication verify:
seller countries
seller entity types
payout methods
bank-account requirements
supported currencies
payout fees
minimums
timing
cutoffs
payout status
rejected payout handling
retry behavior
FX
compliance holds
reserve interaction
payout-account verification
payout reconciliation
Country-level payout coverage should be treated as a live operational dataset.
Regulatory/platform-policy fact-check items
Verify by jurisdiction:
payment-service licensing/perimeter
commercial-agent exclusion where relevant
safeguarding
marketplace funds control
e-money implications
money-transmission rules
KYC/KYB allocation
beneficial-owner requirements
sanctions screening
payment authentication
marketplace consumer-protection obligations
platform-policy restrictions
Current UK guidance explicitly warns online marketplaces to examine whether receiving buyer funds before transferring them to sellers constitutes providing a payment service.
Current US money-transmission regulation should also be checked state-by-state rather than assumed from one federal interpretation.
Disclaimer:
This article provides general information and does not constitute legal, regulatory, tax, financial, accounting, platform-policy, or compliance advice. Merchants should verify applicable requirements with qualified advisers, payment providers, acquirers, banks, payout providers, and relevant authorities.
Conversion and incrementality fact-check items
For buyer-method experiments define:
eligible buyer population
method visibility
selection
initiation
authentication
authoritative confirmation
completed order
fraud
refund
dispute
payment cost
substitution
incremental completed orders
For seller expansion define:
seller target population
onboarding started
onboarding completed
payout eligible
payout attempted
payout completed
payout failed
seller support
payout cost
Do not use gross method volume as proof of incremental marketplace growth.
Amber-flag claims
Do not publish without specific verification:
“This payment method is best for marketplaces.”
“Marketplace sellers can be paid anywhere.”
“Seller payouts are instant.”
“Marketplace settlement equals seller payout.”
“The platform can hold seller money without payment-services regulation.”
“Commercial-agent status exempts marketplaces from PSD2.”
“The PSP handles all KYC.”
“All seller reserves are required by regulation.”
“Bank transfers are cheapest for seller payouts.”
“Local payment methods improve marketplace conversion.”
“Wallets reduce marketplace fraud.”
“Seller payouts are available in every buyer market.”
“A successful buyer payment guarantees seller funds.”
“Marketplace payments are chargeback-free with bank methods.”
Each requires a defined provider, country, merchant model, and date.
Buyer pay-in
Card coverage
local-method coverage
countries
currencies
marketplace merchant eligibility
transaction categories
payment status
refunds
partial refunds
disputes
fraud/risk capabilities
Marketplace platform layer
seller/submerchant accounts
seller onboarding
KYC/KYB
beneficial-owner collection
transaction allocation
split payments
platform commission
seller balances
reserve states
negative seller balances
seller-specific reporting
Do not infer these from ordinary merchant payment acceptance.
Seller payout
Verify:
seller-country coverage
payout rails
payout currencies
seller entity eligibility
payout frequency
payout fees
payout minimums
compliance requirements
failure/retry behavior
seller-level payout APIs
reconciliation
FX
Provider-specific verification requirements
For every marketplace payment or payout provider considered, verify independently:
Pay-in
methods
countries
currencies
marketplace eligibility
merchant category
authentication
confirmation
refunds
disputes
fraud allocation
settlement
Platform
legal funds-flow model
seller/submerchant structure
seller balance model
commission
fee allocation
reserves
negative balances
reconciliation
Pay-out
seller onboarding
countries
entity types
bank/payment destinations
currencies
FX
payout timing
payout failure
fee
compliance review
payout references
support
Never assume that the provider with the strongest buyer acceptance also has the strongest seller payout footprint for the same marketplace.
Cluster sameness-audit fields
Title:
Payment Methods for Marketplaces: Designing Buyer Acceptance and Seller Payouts as Two Separate Systems
First two sentences:
“A marketplace can successfully charge 10,000 buyers. If it cannot reliably pay 2,000 sellers, its payment system is still broken.”
Opening device:
Successful buyer acceptance paired with failed seller payout.
Industry-specific customer problem:
Buyer cannot use an appropriate pay-in method or seller cannot become payout-eligible and receive funds.
Transaction model:
Two-sided buyer payment → platform economic allocation → seller payout.
Primary payment-method categories:
Cards, wallets, bank-based methods, and market-specific local buyer methods; seller payout rails analyzed separately.
Primary format:
Two-sided money-flow architecture.
Unique evidence anchor:
Marketplace payment is multiple money states, not one transfer.
Editorial position:
A market is not payment-ready unless both buyer acceptance and seller payout are operationally viable.
Merchant decision:
Evaluate every market independently for pay-in and pay-out capability before launch.
Original framework:
Marketplace Pay-In / Pay-Out Architecture.
Secondary asset:
Two-sided Market-Entry Readiness Checklist.
Primary buyer metric:
Eligible buyer payment completion.
Primary seller metric:
Payout success among payout-eligible sellers.
Risk profile:
Buyer fraud + seller fraud + disputes after payout + payout-account takeover + negative-balance exposure.
Conclusion:
Buyer payment success does not prove marketplace payment success.
CTA:
Map one real marketplace order from buyer checkout through seller payout—including refund and dispute branches—before approving the next market or payment method.
Closing element:
Buyer-versus-seller architecture and launch checklist rather than a generic “best methods” FAQ.
Buyer-versus-seller scenarios
We can accept local payments in a country. Can we launch sellers there?
Not from that fact alone.
Buyer payment availability establishes only the pay-in side. Seller onboarding, payout destination, currency, compliance, reconciliation, and legal funds-flow model still need verification.
Our PSP settled the transaction. Has the seller been paid?
Not necessarily.
Provider/acquirer settlement and seller payout are distinct states unless the exact marketplace provider model explicitly makes them the same event.
Can we pay every seller by bank transfer?
Do not assume so.
Seller eligibility, bank-account requirements, countries, currencies, provider coverage, compliance restrictions, payout cost, and cross-border banking friction vary.
Should we delay every seller payout because of chargebacks?
Not automatically.
Payout timing and reserves should follow actual fraud/dispute exposure, contractual allocation, fulfillment characteristics, seller risk, provider requirements, and applicable law.
Should buyer and seller payment KPIs be combined?
No.
A marketplace can have excellent buyer payment completion and poor seller payout success—or the reverse.
Measure the systems separately, then evaluate the combined market economics.
Final editorial recommendation
This article should resist the SEO temptation to become:
“The best marketplace payment methods are cards, wallets, bank transfers, and local methods.”
That answer could describe almost any ecommerce business and misses what makes a marketplace different.
The marketplace-specific insight is the second financial constituency.
Every expansion creates two questions:
Can enough buyers pay?
and:
Can enough sellers get paid?
Between them sits the part marketplaces most often underestimate:
the platform money state.
That is where:
commission is calculated;
seller entitlement is created;
refunds reverse transactions;
disputes can arrive after payout;
reserves and negative balances may appear;
currencies diverge;
regulatory questions emerge;
reconciliation either works—or becomes manual.
The strongest line to carry through the final edit is:
A marketplace payment is complete only when the buyer's payment, the platform's economics, and the seller's payout can all be explained from the same transaction record.
That makes this article clearly distinct from Local Payment Methods, which owns buyer method portfolios; International Payouts for Marketplaces, which can own payout mechanics in depth; International Payment Architecture, which owns the general systems layer; and Entity, Settlement & Cross-Border Funds, which owns treasury and settlement strategy.
This article owns the intersection:
the two-sided payment system that determines whether a marketplace market can actually function.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗