PingPong

Service Overview

PingPong positions itself as next-generation payment infrastructure for global growth, and its official site states that 750,000+ businesses already run on it. The wording matters: it no longer describes itself as a tool that collects marketplace proceeds for sellers, but as an infrastructure layer that can be embedded inside someone else's product.

The product splits into three layers, and each layer serves a different customer.

The first is Business Account, carrying global accounts, global payouts, FX, checkout and card issuing, aimed at companies collecting their own money: marketplace sellers, trading companies and teams paying overseas suppliers.

The second is Platform API, exposing global accounts, global payouts, managed accounts, embedded FX, card issuing and a Checkout API. Here the customer is a platform business that needs to give its own merchants payment capabilities rather than only collecting its own revenue.

The third is Solutions, which packages the first two layers by scenario across e-commerce sellers, travel, marketplace, digital services, logistics, offline retail, wholesale and trades, cross-border services and AI enterprise. A separate API Documentation site and Help Center signal that the stack is designed for self-service integration.

So the right way to read PingPong is to answer one question first: are you collecting your own money, or giving your customers a way to collect? The former runs on Business Account, the latter on Platform API. The two paths differ entirely in product form, compliance responsibility and contracting entity. Managed accounts mean holding funds for others, embedded FX means quoting conversions for others, and card issuing means carrying credit and chargeback management. Buying the bundle usually delivers neither path properly.

Key Strengths

• The two product paths are cleanly separated: Business Account and Platform API are distinct stacks, covering both merchant self-collection and platform collection-for-others. A company moving from selling to running a platform does not need to change providers mid-transition.
• Managed accounts are the prerequisite for platform business: marketplaces, travel distribution and logistics collection are all about receiving money for merchants and settling it back to them. Managed Accounts provides exactly that account structure; without it, the only option is running a self-funded pool, which carries severe fund-compliance risk.
• Embedded FX solves multi-currency settlement: a platform collects in many currencies and must settle to merchants in the currency they chose. Embedded FX pushes conversion into the settlement flow so the platform does not have to build its own FX desk.
• Card issuing completes the payout side: card issuing covers ad spend, subscriptions, and staff or supplier expenses. Collection and payout then live in one stack and statements reconcile without adding a separate issuer.
• 9 vertical solutions cut design work from zero: e-commerce, travel, logistics, digital services and offline retail differ mainly in settlement cycles, chargeback structures and compliance documents. Prebuilt solutions shorten the path, though they still need adapting to your business.
• Documentation is comparatively complete: API Documentation is a separate site with interfaces grouped by accounts, payouts, FX, issuing and checkout, so a technical review can run its own proof of concept before sales involvement.

Product Ecosystem

Business Account

For entities that collect and pay on their own behalf. Global Accounts provide multi-currency receiving accounts for marketplace proceeds and buyer remittances; Global Payouts handles suppliers, logistics providers, ad platforms and overseas staff; FX covers conversion; Checkout provides an online payment page; Get a Card issues physical or virtual cards. The 5 capabilities can be combined selectively or enabled together.

Platform API

For platform businesses. Global Accounts and Global Payouts are the base rails; Managed Accounts provides the account structure for collecting and settling on behalf of merchants; Embedded FX inserts conversion into platform settlement; Card Issuing serves merchants, staff or end users; Checkout API lets the platform call payment capabilities directly from its own checkout. You can adopt only some of the 6 families, but the fund flow must be designed once and properly, because retrofitting is expensive.

Solutions

Capabilities packaged by industry across E-commerce Sellers, Travel, Marketplace, Digital Services, Logistics, Offline Retail, Wholesale and Trades, Cross-border Services and AI Enterprise. On the same underlying stack, industries differ mainly in settlement cycle, chargeback tolerance, trade document requirements and compliance pricing.

Checkout and Payment Methods

Checkout and Checkout API let merchants collect on a DTC site or platform checkout. This layer determines authorisation rate and chargeback rate, so supported payment methods, 3DS strategy and chargeback handling need review before integration rather than fee comparison alone.

Developer Support

Dedicated API Documentation and a Help Center cover interface descriptions, onboarding flows and common questions. For technical teams this decides whether proof of concept can happen internally; for non-technical teams, interface and document readability drives time to first transaction.

Limitations

• Three layers mean three contracts and three compliance profiles: Business Account collects your own money, managed accounts collect other people's money, and card issuing carries credit and chargeback exposure. Entity requirements, licence coverage and risk rules differ, so a single bundled purchase typically falls short on one layer.
• The platform route needs a longer due diligence cycle: managed accounts and embedded FX involve fund ownership and licence scope, so compliance discussion and contract negotiation take time. Treating it as a plug-in API badly underestimates time to launch.
• Engineering effort is not trivial: 6 interface families require you to define fund flows, reconciliation bases, refunds and settlement rules. Complexity rises, and ongoing operations plus exception handling need an owner.
• Trade background and KYC remain hard requirements: onboarding, crediting and withdrawal all need registration documents, store or platform authorisation and real transaction evidence. With an incomplete document chain, every licensed provider stalls at the same step and product layering does not change that.
• FX spread is a real cost: low-loss messaging refers to fewer correspondent deductions and no forced conversion, but the spread in the FX quote remains and is wider on minor currencies. Compare final credited amounts rather than headline rates.
• Checkout and issuing move chargeback risk onto you: once you collect card payments yourself, chargeback rate, reserve ratio and scheme monitoring thresholds become yours to manage. The risk of losing an acquiring channel does not disappear because the infrastructure is well built.
• Chinese-language service dominates with limits abroad: Chinese documentation and support respond fast, but country-specific tax, labour and local payment rules lack the depth of local institutions, and cross-time-zone issues need buffer.

Use Cases

• Cross-border sellers on multiple marketplaces (★★★★★): teams needing multi-marketplace proceeds in one multi-currency account with unified payouts and conversion. Business Account is enough; the API layer is not required.
• Platform businesses embedding payments (★★★★★): marketplaces, travel distributors, logistics collectors and AI enterprises that must give merchants or users payment capability. Managed accounts and embedded FX inside Platform API are the core value.
• DTC stores needing a checkout (★★★★☆): custom builds or SaaS handing checkout to the same provider through Checkout API, provided you accept owning chargeback management.
• Managing overseas ad and subscription spend (★★★★☆): card issuing pulls ad spend, software subscriptions and supplier payments into one set of books that reconciles against actual usage.
• Mainland China operations (★★★☆☆): these providers exist to serve Chinese businesses selling abroad, so offshore collection, conversion and outbound payout are home ground. Onshore RMB collection needs a separately licensed domestic channel, and the cross-border side requires trade-authenticity review, dependence on settlement and rebate policy, and FX administration rules, so one infrastructure layer will not solve onshore compliance.
• Least suitable: small sellers wanting a zero-friction free account (★☆☆☆☆): no appetite for compliance documents, no willingness to own chargebacks and reconciliation, single marketplace proceeds only. Layered infrastructure is over-purchase here and a simple collection account is cheaper.

Pricing

The tables list billing bases only, without specific rates: PingPong publishes no standard rate card, and pricing follows entity profile, monthly volume, currency routes, integration scope and contract terms. Use the current official quote and your commercial proposal as the source of truth. Figures quoted here are limited to officially published structure, such as 3 product layers, 6 API families, 9 vertical solutions and 750,000+ businesses.

FAQ

• Is PingPong only for Amazon seller collection?
  No. Seller collection belongs to the Business Account layer, while Platform API serves platform businesses embedding payment capability in their own products. The 750,000+ business figure spans both customer types, not a single seller segment.

• Should I take Business Account or Platform API?
  It depends on whose money you collect. Collecting your own proceeds and paying your own suppliers points to Business Account. Collecting for merchants on your platform, settling back to them, issuing cards to users or calling payment capability inside your own checkout points to Platform API. The test is simply who owns the funds.

• I already have an acquirer. Do I still need Checkout?
  If your acquirer's authorisation rate, chargeback rate and settlement cycle fit the business, there is no need to switch. Checkout's value is putting acquiring, multi-currency settlement and issuing into one account structure to reduce reconciliation friction, at the cost of you retaining chargeback management. Run a small parallel test of authorisation rates before any full cutover.

• What are the fees?
  PingPong publishes no standard rate card; pricing is negotiated against entity profile, monthly volume, currency routes and integration scope. Break the quote into collection fee, withdrawal fee, payout fee, FX spread and reserve ratio during negotiation, because a single blended rate hides the real cost.

• Can a mainland China entity use it, and does onshore collection run through it?
  The customer base is Chinese businesses selling abroad, so offshore collection, conversion and outbound payout are home ground. Onshore RMB collection requires a domestic licensed channel and falls outside this stack. The cross-border side needs trade background documents, and settlement plus tax rebates follow FX and tax policy, so policy shifts change fund timing.

Source: original 16IDC content. Product capabilities, supported countries and fee definitions follow the official documentation and your contract.