PingPong Guide: Marketplace Payout Aggregation and Settlement

PingPong Guide: Marketplace Payout Aggregation and Settlement

Cross-border sellers usually get stuck at two different points: how customers pay you, and how marketplace payouts are aggregated and settled back compliantly. Founded in Hangzhou in 2015, PingPong addresses the second. It is a collection-account provider, not an acquirer. Confusing the two roles leads to meaningless fee comparisons against platforms such as Stripe.

The more interesting shift is in role: providers of this kind have moved from being a collection account for sellers to being embedded payment capability for platform businesses. In practice that means two access paths. You either collect your own money through an account product, working in a dashboard with file-based reconciliation, or you collect on behalf of clients through an API integration, which raises sub-merchant and compliance questions. The first selection question is which path you are on, because eligibility, engineering effort and compliance responsibility differ completely.

1. Core capabilities

1.1 Marketplace payout aggregation

When selling on marketplaces, sales proceeds settle from the platform to a collection account, which then handles settlement or transfer. This is the most-used function and the base of the business.

What it solves is gathering payouts from several marketplaces into one account, instead of opening a separate tool per platform. Where it adds nothing: you sell only through a DTC site and have no marketplace payouts, or the marketplace already settles into your own offshore company account, so aggregation has no subject.

Metrics: whether the target marketplace is supported, whether several stores under one platform can hang off the same account, whether payout timing meshes with the platform settlement cycle, and whether funds can settle as soon as they arrive. The last matters most in peak season.

1.2 DTC collection

For direct-to-consumer stores it can serve as the landing account for acquiring funds or as part of the settlement chain alongside an acquirer. Supported acquirers and currencies change, so confirm against the current dashboard.

The boundary needs stating: what you get is a collection account and funds aggregation, not a substitute for acquiring. Which card the buyer uses, whether 3DS applies and who carries the chargeback still depend on the acquirer you connect. DTC collection answers where the money lands, not how it comes in.

Where it adds nothing: if your goal is a higher authorisation rate on the site, the thing to change is the acquirer or the routing across payment methods, not the collection account.

Metrics: which acquirers can be linked, whether settlement currency matches account currency, and how refunds and chargebacks are funded back.

1.3 B2B trade collection

Collects payment for traditional export trade, letting buyers pay through local or cross-border routes. Suitable for sample orders and batch orders that need clean reconciliation.

It does not replace T/T or letters of credit. What it improves is the buyer payment path and visibility of arrival, so a buyer does not queue at a bank counter to wire a small invoice. It changes nothing about trade terms, document responsibility or negotiation rules. FOB or CIF, who issues the documents, how discrepancies are handled, all still follow the contract. Large or document-heavy orders should stay with the bank, as covered in B2B Large Payment Methods.

Metrics: which local methods the buyer's country supports, whether arrivals can be matched by order number, and whether the provider issues proof of receipt usable for tax refunds. Export refunds have requirements on receipts and documents, worth confirming at selection time, as covered in the Export Tax Refund Guide for Cross-Border E-Commerce.

1.4 Settlement and value-added services

The core is settling into a domestic account; VAT filing, FX tools, logistics and compliance support are typically available as optional services.

Value-added services save you from sourcing separate vendors, at the cost of binding more steps to one provider. Decide with three questions: does VAT filing cover the countries you actually file in, does FX locking cover your funding cycle, and is there an independent fallback when these services break. Bundle everything into one provider and both your negotiating room and your exit cost get worse.

2. Account structure and compliance boundaries

It supports mainland China business entities, which is its biggest practical advantage over international acquirers, since no Hong Kong or US company is required first. Business licence, legal representative identity, store or business evidence and similar documents are needed, and review checks business authenticity and model. Sole trader and company entities require different documents, so prepare according to the current dashboard guidance.

2.1 Account types and KYB documents

Personal and business entity accounts carry different feature sets, so business use should run on a company or sole-trader entity. The point of KYB documents is not completeness but agreement: entity name matches the store backend, declared scope matches actual categories, collection volume matches sales records. Any one of the three drifting apart triggers requests for more paperwork.

2.2 Trade authenticity

Marketplace payouts prove themselves through the platform settlement report, which is comparatively simple. B2B collection has to be proven with contracts, invoices and shipping documents, which is why B2B stalls more often: on any single payment the provider has to reconstruct who bought what and how it shipped. Putting order, contract and tracking numbers in the payment reference saves far more effort than assembling documents later.

2.3 Sub-merchants and collecting on behalf of clients

On the API path, where you collect for clients, the first question is whether the money passes through your account.

• If it does, you are part of the money chain, which brings collection-and-disbursement, float and split settlement into scope, and the boundary question becomes licensing and filing.
• If it does not, the provider settles directly to sub-merchants and you are mainly the technical and commercial front end, but sub-merchant onboarding, transaction authenticity and risk responsibility may still land on you.

The two models differ completely in eligibility, engineering and liability, and neither can be waved through with a connect-now-explain-later approach. The licensing framework is in the Payment Compliance and Licensing Guide, float accounting is in the Platform Treasury Architecture Guide, and split designs are in the Aggregate Payment and Split Settlement Guide.

2.4 Three questions platform businesses must answer first

First, ownership: who legally owns each payment, and whether the platform may use it. Second, split rules: how commission, refunds and disputed amounts are deducted, and at which point in time. Third, traceability: whether statements can be traced line by line back to an order and a sub-merchant. Scale before answering these and every dispute becomes manual detective work.

3. Reconciliation and cash planning

The real pain in multi-marketplace operations is not collection but knowing which payment arrived for which batch of goods.

3.1 The three statements to reconcile daily

The order report (marketplace sales and refunds), the settlement report (platform payout batches and deductions), and the account statement (credits, conversions, withdrawals). Line them up by marketplace, currency and batch, and a variance becomes explainable. Reconciling totals without batches is the root cause of statements that never close later. Field design and cadence are covered in the Payment Reconciliation and Bill Operations Guide.

3.2 The four timestamps in a cash plan

Marketplace payout, credit to account, availability for withdrawal and arrival at the bank are four separate moments, with the platform settlement cycle, provider processing time and bank transit in between. Plan cash by stacking those four, not by adding a fixed number of days to the order date. Keep at least one month of cash buffer before peak season, so a review or an FX window does not cost you the restocking window.

3.3 Why book balance is not withdrawable balance

Book balance includes funds in transit, pending settlement, reserved amounts and items under review. After a promotion, the headline number looks healthy while withdrawable funds stay limited; disputes and chargebacks can put a temporary reserve on top. Plan against the withdrawable balance, not the book balance. Modelling for reserves and float is covered in Payment Reserve and Float Modelling.

4. Fee structure

Costs usually have three parts: collection or inbound fees (a percentage of volume), settlement and FX spread (the largest long-term factor), and withdrawal or transfer fees (per item or percentage). Value-added services are priced separately. Exact values follow the official site and your contract.

Judge on total landed cost, not the headline collection rate. A 0.2 percent difference in collection rate can be wiped out by a 0.5 percent difference in FX spread. Comparing the actual settled amount against the bank's rate on the day is the most direct verification.

4.1 Visible fees

What the quote sheet shows: collection fees, withdrawal fees, transfer fees and value-added service fees. Easy to compare, and easy to mistake for the whole cost.

4.2 Hidden costs

Spread, the fixed portion of per-item fees, the cost of returned or amended payments, and the people needed to satisfy compliance requests. Spread rarely appears on a rate card, yet annualised across your volume it is often the largest line. The method is in the Payment Fee Audit Guide.

4.3 When cost runs past expectations

Many currencies at small value, dense payout batches, high refund rates and peak-season withdrawal clusters all make fixed fees fire repeatedly. One more pattern is often missed: concentrating a large settlement to chase a better spread locks cash flow inside the settlement window and throws off restocking.

5. Advantages and limitations

5.1 Advantages

• China entity support: a low onboarding barrier, with no offshore structure required first.
• Mainstream marketplace payout coverage: major channels such as Amazon need no separate route.
• Mature settlement chain: predictable arrival timing, which makes weekly cash planning realistic.
• Covers both B2B and DTC: one account handles several income types with a single reconciliation standard.
• Value-added services reduce vendor sprawl: VAT and logistics do not need separate suppliers, which matters most to small teams.

5.2 Limitations

• No buyer-side checkout: site conversion still depends on the acquirer.
• FX spread is yours to calculate: it varies by currency, and skipping the maths leads to wrong conclusions.
• Strict compliance requirements: questionable business authenticity draws document requests that stall payout timing.
• Centred on China-based sellers: purely overseas entities may find better fits.
• The boundary is easy to misread: used as if it were an acquirer, it disappoints on conversion.

6. Who it fits

Good fit: China-based sellers whose main channel is marketplaces such as Amazon; teams aggregating payouts from several platforms into one account before settlement; companies that also run B2B export trade and want one reconciliation system; teams preparing a platform business who want the money and compliance boundaries settled before integration.

Weaker fit: DTC-only merchants whose priority is payment conversion; purely overseas entities with mature banking and collection arrangements; developers who only need API acquiring and have no aggregation problem.

7. Go-live checklist

• Run one small payout from one marketplace through settlement, credit, conversion and arrival, recording the real days for each leg
• Reconcile the credited amount by backing the spread out from the day's rate and put the total cost in a sheet
• Confirm statement fields can be matched by batch and order number, and fix gaps before scaling
• Verify the entity name matches the store backend, and align it before volume ramps
• Clarify which countries VAT filing covers and where its responsibility ends, rather than treating it as full tax compliance
• On the API path, confirm first whether money passes through your account, then decide the compliance scope
• Set an observation basis for withdrawable balance and keep it separate from book balance
• Prepare a backup collection route and decide how in-flight funds are handled during a switch

8. How it divides work with acquirers and PayPal

The typical setup has three layers: the acquiring layer (Stripe, Adyen and similar) makes buyer payments succeed and owns authorisation rates, 3DS and chargebacks; the aggregation layer (PingPong, Payoneer, WorldFirst and similar) gathers funds from each channel and settles them, owning the money path and reconciliation; the wallet layer (PayPal) sits alongside as a familiar buyer option. Each layer does its own job, so a problem in one does not stop the business.

A concrete combination: an acquirer on the DTC site with PayPal shown alongside, marketplace payouts aggregated into one account provider, a second provider taking a share by currency or region, payment requests for small B2B invoices and the bank for large ones. With that split, an acquiring problem shows up as conversion movement, an aggregation problem as delayed arrival, and a wallet problem as some buyers unable to check out, so diagnosis gets immediate. Peer account providers are compared in the Payoneer Guide, and role mapping follows the framework in a cross-border payment selection matrix. More payment options are listed under Payment.

Source: 16IDC original. Capabilities, eligibility and pricing follow pingpongx.com official documentation and contract terms.