Payment Facilitators, Marketplaces and App-Store Settlement. Connect customer collections, acquiring, seller entitlement, app-store proceeds, reserves, payouts, disputes and bank reconciliation.
A small software company sells $20,000 of subscriptions through an app store. Its sales dashboard looks healthy, but its bank account has not increased by $20,000. Meanwhile, a furniture seller on a marketplace sees completed customer orders and a smaller amount available for payout. Both businesses ask the same question: if customers have paid, why have we not received the same amount?
Chapter 46 followed wallets and overlays from customer action to the actual location of value. This chapter follows an intermediary that collects or processes customer payments and calculates proceeds owed to another business. Payment facilitators, marketplaces and app stores can all sit between a purchase and a seller's bank receipt, but they do not share one legal role or settlement model.
Customer payment, network settlement, seller entitlement and seller payout are separate events. A platform can report a successful sale while proceeds are still being calculated, held or scheduled for delivery.
Allow roughly 60 minutes for the chapter, diagrams and worked cases. Businesses, fees, reserve percentages and accounting entries are fictional unless explicitly attributed. The discussion describes common design choices and published provider arrangements, not confidential acquiring contracts. Sources were checked on October 5, 2026.
Chapter navigator
- Start with the commercial and legal model
- Payment facilitators and the acquiring relationship
- Marketplaces, sellers and divided proceeds
- App-store sales and developer proceeds
- Follow the customer payment into the platform
- Clearing, settlement and seller payout
- Calculate proceeds without losing the gross activity
- Funding calendars, thresholds and reserves
- Refunds, disputes and negative seller balances
- Payout failures and safe reissue
- Merchant onboarding, fraud and sanctions
- Network rules, regulation and supervisory guidance
- Reconcile sales, proceeds and bank cash
- Implementing the platform service inside a bank
- Worked cases and implementation decisions
- Role checklist and learning closure
1. Start with the commercial and legal model
A payment facilitator supports merchants' acceptance through an acquiring relationship under the relevant network arrangements. A marketplace connects buyers and sellers and may also arrange payment collection and distribution. An app store distributes digital products and may collect customer payments and remit developer proceeds under its agreements. One company can combine several functions, but the labels are not interchangeable.
For a bank, the first document should map the seller of the goods, the entity contracting with the buyer, the party accepting the payment and the party entitled to the resulting funds. Establish who supplies refunds, handles disputes, determines fees and instructs payouts. A marketing description such as platform payments does not answer these questions.
Merchant of record is a commercial and contractual role, not a separate payment rail. Determine what the applicable agreement means by it, including sales obligations and customer-facing identification. Do not assume every marketplace is the seller of every item, or that every payment facilitator acquires ownership of its merchants' goods and sales revenue.
This chapter focuses on payment and proceeds operations. Revenue recognition and indirect-tax responsibility require their own accounting and legal assessment. The payment record should preserve the facts needed by those teams rather than decide principal-versus-agent treatment solely from which account received cash.
The software company's bank should identify the app-store payout rather than search for thousands of individual consumer subscriptions. The marketplace seller's bank should identify the platform's funding instruction. In both cases, the underlying sales detail is necessary for the business's reconciliation, even though the bank statement may contain only an aggregated credit.
2. Payment facilitators and the acquiring relationship
Visa's published rules distinguish payment facilitators, sponsored merchants and acquirers. The applicable network requirements govern registration, merchant activity and the acquiring relationship. The exact obligations and transaction data depend on the current network and program; a public overview should not be substituted for the acquirer's implementation requirements.
In a simplified operating model, the facilitator supplies merchant onboarding, payment integration, transaction reporting and payout services within its agreed scope. The acquirer connects the activity to the card network and has network-facing responsibilities. A processor may operate technical services for either party. The card issuer serves the cardholder. These roles remain relevant even if the seller interacts only with one facilitator dashboard.
The bank should know how each sponsored merchant is identified in processing and monitoring records. Treating every merchant as an indistinguishable part of the facilitator hides concentrations, prohibited activity and dispute patterns. Underwriting and ongoing review should be proportionate to the actual business and the acquiring arrangement, with access to supporting data.
A facilitator's rapid onboarding experience is a product feature, not an exemption from due diligence. If a seller changes from local services to high-value advance bookings, the exposure can change materially. The bank and facilitator need an agreed process for identifying such changes, reassessing settlement terms and managing existing obligations without losing transaction history.
The practical boundary is clear: a successful API integration does not establish that the acquiring bank has approved every merchant, product or use case. A production acceptance review must include the contractual and risk conditions as well as the technical certification.
3. Marketplaces, sellers and divided proceeds
A marketplace order can contain goods from several sellers, shipping charges, taxes, discounts and a platform fee. The buyer may make one payment while the platform creates several seller entitlements. Those entitlements should be calculated from the contractual order lines and adjustments, not by dividing a bank credit after the fact.
Consider a fictional $300 order: $180 belongs to seller A's goods and $120 to seller B's goods, before any applicable fees or adjustments. One customer payment may support both lines. If B cannot supply its item, the platform must determine whether to reduce capture, refund a completed amount or apply another supported correction. A's entitlement should not disappear merely because the order contains a problem with B.
A split in a platform ledger is not evidence of multiple interbank settlements. The platform may create two liabilities and later make two payouts, or aggregate each seller's activity into periodic payouts. Each payout needs a traceable population of sales and adjustments. The buyer payment and seller payout references serve different purposes and should both be retained.
The platform also needs to identify who bears a refund or dispute after payout. It might recover from future proceeds, a reserve or another contractual arrangement. The existence of a recovery clause does not guarantee the seller has funds. The bank should understand the exposure created when customer disputes outlive seller funding.
Seller support should explain the calculation in business terms: completed sales, deductions, unavailable proceeds and scheduled payout. A single balance named earnings can be misleading if it mixes estimates, settled activity and restricted funds.
4. App-store sales and developer proceeds
App-store proceeds are governed by the developer's applicable agreements, reporting periods and payment requirements. They should not be modeled as immediate card-network settlement directly to the developer. The platform may aggregate transactions, apply commissions, taxes and adjustments, and issue a separate bank payment.
Apple's receiving-payments guidance requires an effective Paid Apps Agreement, bank information and the applicable threshold and invoicing conditions. It describes payment within 45 days after the relevant fiscal month ends when those requirements are met. The fiscal month is not necessarily a calendar month. This is a published proceeds schedule, not a promise that every individual purchase appears in the developer's bank account in 45 days regardless of conditions.
Google's payments-center guidance says Google Play developer payouts start on the 15th for the previous month's sales, with bank receipt taking additional time. The wording describes initiation of payout, not guaranteed bank availability on that date. Product, profile and threshold conditions must be checked against the actual developer arrangement.
For implementation, use the store's financial reports and bank remittance evidence together. Sales analytics can show user activity and estimated revenue, while finalized financial reports reflect the payout calculation. The bank credit should be reconciled to the relevant finalized proceeds and adjustments rather than forced to equal a live sales dashboard.
Do not hardcode one commission percentage or one global tax treatment into the chapter's bank model. Programs, agreements, product types and jurisdictions differ. The developer's finance team should retain the applicable agreement and period-specific calculation, including any currency conversion, without teaching a changing commercial rate as a US settlement rule.
5. Follow the customer payment into the platform
The customer's payment journey starts with a purchase and the supported payment method. With a card, authorization is followed by capture and clearing as appropriate to the transaction model. The issuer's approval does not itself prove that the platform received settled funds. With other supported methods, use their actual processing and exception models rather than applying card terminology universally.
The platform's order service should preserve the relationship between order, payment attempts, completed amount and adjustments. One order may have an abandoned attempt followed by a successful payment. Several webhooks may describe one financial event. Neither should increase sales or seller entitlement twice.
The diagram separates payment acceptance from the platform's proceeds ledger and the later payout. It also shows that adjustments can change entitlement after the initial sale. Its acquiring path is a simplified card example; it is not a claim that every app-store or marketplace transaction uses the same payment method.
A bank implementing platform acquiring needs sufficient transaction identification for its role: merchant or sponsored-merchant identity, payment reference, amount, currency, relevant processing dates and adjustment linkage. Seller payout data additionally needs the seller identity and the population being paid. One generic platform reference cannot reliably replace all of these relationships.
6. Clearing, settlement and seller payout
For card collections, clearing exchanges the financial transaction information used to establish participant obligations. Network settlement addresses those obligations between participating institutions under the relevant arrangement. Merchant or platform funding follows the acquiring contract. The platform's subsequent seller payout is another financial movement and can use a different rail.
For example, card sales can eventually support a seller payout by ACH credit. The card network does not thereby become the ACH operator. The payout bank originates the ACH credit, and interbank settlement and seller-bank posting follow that arrangement. A payment facilitator's dashboard may use settlement for its payout report, but the bank's analysis should state whether it means network settlement, platform funding or seller delivery.
Money can pass through a platform-controlled or appropriately titled account before distribution. Establish the legal ownership, contractual entitlement and ledger structure for that account. A label such as FBO is not sufficient evidence of every customer's rights or of deposit-insurance eligibility. Account agreements and reliable beneficial-owner records matter.
If a platform pays sellers before collecting corresponding customer funds, it creates funding exposure. If it holds proceeds after receipt, it creates an outstanding obligation or restricted balance according to the arrangement. Both require explicit records. Neither should be hidden by treating sales volume as cash already available for every seller.
The seller's bank generally sees the payout, not the entire upstream acquiring lifecycle. It can confirm its own receipt and posting, while the seller uses the platform's detailed report to explain the amount. The two evidence sources complement each other.
7. Calculate proceeds without losing the gross activity
Use a proceeds ledger that preserves sales, refunds, fees, reserves, releases, disputes and payouts as identifiable movements. Do not overwrite the original gross sale with its eventual net amount. That shortcut makes later refunds, tax analysis and dispute allocation difficult because the original commercial event disappears.
A fictional seller begins a period with no payable balance. Completed eligible sales are $10,000, refunds are $400, contractual fees are $300 and a reserve allocation is $500. The illustrative amount available for payout is $8,800, while $500 remains in the separately identified reserve obligation. The $300 is not a reserve, and the $400 is not a processing fee. They explain different reductions.
The example assumes no other taxes, charges, currency effects or opening balances. In a real arrangement, include each applicable component explicitly. The platform should be able to reproduce the calculation from underlying events and the agreed fee and reserve rules for that period.
The diagram distinguishes funds payable now from amounts retained for future treatment. A reserve release can increase payout without representing a new sale. A negative adjustment can reduce a later payout without reducing the original sale count. Reports should make those facts understandable to the seller and finance team.
For a bank control, reconcile the payout batch to the sum of eligible seller amounts and then reconcile the bank movement to the batch. Investigate differences at their source. Do not adjust a seller's balance merely to make an aggregate bank account reconcile.
8. Funding calendars, thresholds and reserves
A platform's payout calendar is a commercial schedule. The underlying payment rail has its own operating calendar, acceptance criteria and settlement timing. The seller's receiving bank has posting and availability behavior. A useful service defines what each date means and which evidence confirms it.
For an app store, the relevant fiscal or reporting period and payment threshold can determine when proceeds enter a payout cycle. For a marketplace, shipment, completion or another contractual condition may affect eligibility. Those conditions must come from the actual agreement; they should not be invented as universal platform practice.
Reserves need a clear basis, scope and release rule. In an illustrative design, a rolling reserve associates retained amounts with source activity and a future eligibility condition. Another arrangement may use a fixed reserve. The bank should understand the actual contract rather than assume every reserve is a percentage retained for the same number of days.
Treasury forecasts should separate expected collections, bank-confirmed cash, seller amounts eligible for payment, restricted balances and scheduled payouts. A sudden increase in refunds can reduce available liquidity without reducing the number of earlier successful purchases. A calendar that ignores adjustment exposure can overcommit cash on a payout day.
Customer-facing dates should be updated when a payout is held or rejected. The seller should see the reason and next action that can be disclosed, not an endlessly moving estimated arrival date that hides an unresolved bank-account problem.
9. Refunds, disputes and negative seller balances
A refund should reference the original customer payment and affected seller or order lines. A card dispute follows the relevant card process and can produce a separate adjustment. If both approach completion, the platform must coordinate the evidence to avoid crediting the buyer twice or charging the seller twice for the same underlying issue.
The seller may already have received its payout. A later refund then creates a recovery or funding need under the agreement. It does not automatically recall the completed payout. The platform can have a negative seller balance even while its bank account remains positive, because aggregate cash and individual entitlements measure different things.
Negative balances should retain their cause and age. Separate refund obligations, dispute debits, fee adjustments and payout errors. A collections team needs to know what evidence supports recovery, and a risk team needs to see whether the seller is continuing to trade while exposure grows.
If the platform uses future proceeds to recover an amount, record the offset explicitly. The next sales report should not quietly reduce transaction amounts. If recovery fails, escalate the contractual and accounting decision rather than delete the balance when the seller closes its account.
A seller's dispute with the platform about fees is also distinct from a cardholder dispute. The bank should not route both to the card chargeback workflow. Clear classification prevents operational teams from applying the wrong deadlines, evidence requirements or financial treatment.
10. Payout failures and safe reissue
An invalid destination, closed account or unsupported payout method can cause a definitive failure. A lost response creates uncertainty. These require different treatment. A definitive failure can support correction and a linked new attempt once the original financial outcome is understood; an uncertain result requires inquiry before replacement.
The platform should keep a stable payout obligation and separate execution attempts. Changing a seller's bank account should affect a new authorized attempt, not rewrite the destination of a previously released instruction. The old destination and release evidence remain necessary for investigation and fraud analysis.
If a payout returns after the platform marked it sent, restore the appropriate seller payable treatment using the returned funds and actual accounting policy. Do not record another sale. Communicate that payout delivery failed and describe the verified correction process. A seller should not have to create a fake new order to receive money still owed.
For uncertain cases, retain the amount as unresolved and prevent simultaneous release through a second bank or rail. A new payout provider is not a safe fallback if the old provider may still complete. The switch requires an established outcome or a controlled risk decision with explicit duplicate handling, not a dashboard timeout alone.
11. Merchant onboarding, fraud and sanctions
Onboarding should identify the business, its activity and the authorized people controlling payment settings. For platform models, changes in sellers and underlying activity can create risk beyond the platform company's own identity. The bank should obtain the information needed for its role and contractual responsibilities.
Pay particular attention to payout-destination changes. An attacker who cannot alter historic sales may still divert accumulated proceeds. A sound design separates routine profile edits from financial destination maintenance, uses appropriate verification and retains who approved the change and which payouts it affects.
Fraud monitoring should distinguish suspicious customer purchases, fictitious seller activity, collusion, refund abuse and account takeover. A high sales total is not proof of a successful merchant relationship if the transactions later become losses. Review disputed and returned activity against the relevant seller and business model rather than only the aggregate facilitator account.
Sanctions and AML responsibilities depend on the participants and activity. A platform's use of an acquiring bank does not exempt it or the bank from applicable obligations. Conversely, the platform label alone does not establish that every entity has identical regulatory status. Legal and compliance teams should assess the actual model and retain the basis for the conclusion.
12. Network rules, regulation and supervisory guidance
Keep three assessments separate. Card-network rules govern the acquiring and merchant arrangements within their scope. FinCEN regulations and interpretations address relevant BSA classifications and obligations. State requirements and other applicable laws require their own analysis. The platform's commercial agreement adds terms but does not replace those assessments.
FinCEN's payment-processor ruling describes a conditional exemption involving goods or services, formal agreements and qualifying clearance and settlement systems. It is not a blanket declaration that every marketplace or business calling itself a payment processor is outside money-transmitter regulation. The funds-disbursement model matters, and state-law treatment is not settled by that federal ruling alone.
Interagency third-party guidance helps a bank manage relationships through planning, due diligence, contract negotiation, monitoring and termination. It is supervisory guidance rather than a new platform settlement rule. A contract assigning a task to a provider does not eliminate the bank's need to understand and oversee the relevant risk.
For the implementation record, retain the approved business model, network program, contractual parties and legal analysis. If the platform later adds stored balances, consumer transfers or another new activity, revisit the assessment. A prior approval for merchant collections should not silently authorize an unrelated money-movement product.
13. Reconcile sales, proceeds and bank cash
Use three reconciliations. The sales population establishes customer transactions and adjustments. The proceeds ledger calculates what is owed to each seller or developer. Bank reconciliation establishes actual cash movements and remaining financial positions. Each answers a different question and should have its own control totals and exception owners.
For a generic platform acting as an intermediary, cash received on behalf of sellers can create a corresponding liability rather than becoming platform revenue in full. Platform fees and other components receive their own accounting treatment under the actual contracts and accounting policy. This is an illustrative distinction, not a universal journal for every marketplace or app-store entity.
Reconcile opening payable plus newly eligible proceeds and adjustments less completed payouts to closing payable. Track reserves separately but maintain their relationship to the seller. Reconcile the resulting balances to bank cash and supported receivables or payables, explaining timing differences and exposures rather than assuming every ledger balance has already settled in cash.
App-store reconciliation should use finalized period reports, payout references, currency amounts and bank receipts. An estimated sales report can differ for legitimate reasons. The task is to identify and evidence those reasons, not to force the bank amount to equal the developer's live analytics total.
An aged unexplained difference needs an owner, value, source population and next action. A small difference repeated over many sellers can be material. Manual adjustments should retain approval and reason and should never become the default substitute for missing transaction lineage.
14. Implementing the platform service inside a bank
Define the data model before building the payout dashboard. Separate buyer payments, order lines, seller entitlements, reserves, payout obligations, attempts and financial events. One-to-many relationships are ordinary here. A flat record containing order, seller and paid flag will fail as soon as an order is divided or partially refunded.
Agree interface semantics: what does accepted mean, when is a payment final for the provider's purpose, what makes proceeds eligible, and what confirms payout delivery? Obtain current specifications for signatures, event identity, inquiry and reporting. The chapter does not invent endpoints or treat generic JSON examples as a production contract.
The pilot should include two sellers in one order, a refund after payout, a reserve release, a negative balance, a bank-account change and a duplicate callback. Finance should reproduce the seller statement from events. Operations should demonstrate a failed payout and an uncertain payout without paying either obligation twice.
Plan provider exit while money remains owed. The bank and platform need accessible records for late disputes, returns, reserves and unclaimed proceeds, with the applicable legal and contractual treatment. Disabling new sales is different from completing financial closure. The seller population should remain reconcilable until the final obligations are resolved.
15. Worked cases and implementation decisions
A marketplace payout is smaller than sales
A seller reports $10,000 of eligible sales. The agreed report contains $400 refunds, $300 fees and a $500 reserve allocation, leaving $8,800 available for payout. Ask the learner to reconcile all four components and explain the remaining $500. The reserve remains a separately tracked obligation subject to its release terms; it is not unexplained missing cash or automatically platform income.
If the bank receives an $8,800 payout instruction and confirms its financial completion, that supports payout of the eligible amount. It does not prove the reserve was released. The seller statement and bank statement should therefore answer different questions without contradicting each other.
One order, two sellers, one cancellation
The $300 order contains $180 for seller A and $120 for seller B. B cancels before its item can be supplied. Establish the actual payment state before deciding whether to reduce capture or issue a refund. Record the affected order line and seller entitlement. Do not issue $120 to the buyer as an unrelated personal transfer.
If A has already been paid, B's cancellation should not reverse A's entitlement without a contractual basis. Reconcile the customer payment, the $120 correction and both seller records. This tests whether the platform preserves allocation rather than treating the whole order as one indivisible payable.
A developer compares sales analytics with bank proceeds
A developer sees $20,000 in a dashboard but receives $16,900 from a platform. The amount alone cannot identify the difference. Obtain the finalized period report and explain fees, taxes, adjustments, currency effects and any amounts outside that payout period as applicable. Do not invent a commission rate simply because the difference resembles one.
For an Apple example, verify the fiscal period and payment requirements. For Google Play, distinguish the published payout start date from bank receipt. The learner should identify the required reports and periods before doing arithmetic, because even perfect subtraction cannot reconcile mismatched populations.
A payout account changes after release
A seller updates its bank account after an $8,800 payout was released to the old destination. The platform should preserve the original instruction and investigate that payment. Updating the profile does not redirect an in-flight bank transfer. A new payout to the new account requires a supported original outcome and authorized replacement decision.
If the original returns, link the return to the payout obligation and verify the new destination through the controlled process. If the original completed, investigate the seller's access to the old account and available recovery options. Do not promise a second payment merely because the current profile displays another destination.
Refund and dispute concern the same purchase
A $120 refund is processing when a cardholder dispute arrives for the same item. Operations should link both cases, establish the refund evidence and follow the relevant dispute process. Automatically debiting the seller for both can create an incorrect $240 reduction. Automatically ignoring the dispute can also miss an obligation.
The correct result depends on the actual payment and case outcomes. The control requirement is to preserve the common original transaction and reconcile both financial events. Describe any temporary exposure explicitly until evidence establishes the final net treatment.
A provider outage interrupts payout confirmation
A batch of 50 payouts is submitted before the provider becomes unavailable. Forty have confirmed outcomes and ten are uncertain. Continue from the known population; do not resend the entire batch after recovery. Reconcile each unresolved attempt using the provider's supported evidence and prevent a parallel bank from releasing replacements prematurely.
Ask the learner to produce a control total containing confirmed, rejected and unresolved amounts. Then introduce a late report confirming six of the ten. The unresolved population should shrink without changing the original batch amount or inventing new seller entitlement.
16. Role checklist and learning closure
Product should explain the seller's proceeds and payout promise. Business analysis should distinguish the platform's legal and commercial roles. Technology should preserve order allocation, financial events and payout attempts. Operations should manage disputes and delivery failures at their correct level. Finance should connect gross sales, proceeds, reserves and bank cash without erasing any component.
Risk teams should assess the actual merchants, account model and funds movement rather than rely on the platform label. A working service can explain why the buyer paid, what the seller is owed, what is retained and what the bank actually delivered.
Chapter 48 turns to BNPL, payroll deduction and government bill collections, where the authority to collect and the underlying obligation create different operating responsibilities.
Authoritative references
Sources checked on October 5, 2026. Published payout conditions remain subject to the relevant agreement and account eligibility. Example fees and reserves are fictional.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.