One Fleet. Many Merchants. Clean Settlement.
Multi-merchant groups let one shared terminal fleet serve many independent merchants — with each merchant keeping their own branding, pricing, settlement, and reporting. Built for food courts, festivals, pop-ups, and shared retail. Paired with the Service Providers API for onboarding third-party application providers at scale.
Shared Hardware, Independent Settlement
Most payment platforms force a one-merchant-per-terminal model. That breaks the moment you have a food court, a festival, a shared kitchen, or a pop-up marketplace. Surfboard's multi-merchant groups invert the assumption — the terminal is shared infrastructure; the merchants behind it stay fully independent.
Each merchant tagged into a group keeps everything that makes a merchant a merchant: their own branding, their own pricing, their own settlement schedule, their own reporting. The group is a routing layer, not a financial entity. Clean for operators, clean for merchants, clean for compliance.
Built for marketplace partners
ISVs running food halls, festival operators, mall management companies, and service-provider platforms all need this primitive. Surfboard ships it as a first-class API, not as a special-case workaround. One POST creates the group; merchants get tagged in; the same terminals start routing.
How Multi-Merchant Works
Create a multi-merchant group
POST /partners/:partnerId/multi-merchant
{
"country": "SE",
"zipCode": "11122",
"name": "Hötorget Food Court"
}
// Response
{
"status": "SUCCESS",
"data": {
"applicationId": "81376ad8ebedf80310",
"merchantId": "81660b596c7fd0000e",
"storeId": "81660b59434440030f"
}
}
Tag merchants into the group
One terminal serves every merchant in the group
What you can build
Multi-merchant groups and service providers cover a class of partner workflows that single-merchant platforms simply can't model. Here's where this matters.
1. Food Courts & Shared Kitchens
Ten restaurants in one hall. One queue. One terminal at the order point. Each transaction settles to the right kitchen — without ten separate hardware fleets, ten cabling jobs, or ten reconciliation reports.
- One terminal, multiple settling merchants
- Independent branding and pricing per merchant
- Per-merchant settlement and reporting preserved
Perfect for:
- Food halls and ghost-kitchen operators
- Pop-up markets and food truck rallies
- Mall-based queueing concepts
2. Festival & Event Marketplaces
Festivals run dozens of independent vendors. The festival operator owns the terminals and the customer experience; each vendor settles independently. Multi-merchant groups model this exactly — one fleet, many beneficiaries.
Pair with the Notifications API for real-time settlement breakdowns to vendors after each event day.
3. Service Provider Applications
The Service Providers API lets partners onboard third-party application providers — POS systems, kiosk operators, vending vendors — under their own partner umbrella. Track application status, fetch service provider configs, and manage the full provider lifecycle.
- Onboard service providers programmatically
- Track application and approval status
- Fetch provider configurations per merchant or partner
4. Coworking & Shared Retail
A retail space that hosts multiple independent brands — pop-up stores, makers' markets, art galleries with consigned artists. Multi-merchant groups give the host one terminal fleet while preserving each brand's identity, settlement, and reporting.
5. Mobile & Pop-Up Networks
A partner running a network of pop-up vendors at sports events, summer markets, or seasonal locations. Issue terminals to the network operator, tag participating merchants in, and let the same hardware travel between events without any per-event reconfiguration.
6. Clean Settlement Per Merchant
The shared terminal is just hardware. Settlement is always merchant-by-merchant. Each merchant in a group sees their own Reporting API output, their own Billing plan applied, their own payouts, their own statements. The group is a routing concept, not a financial one.
Compliance and audit trails stay clean even when the underlying device fleet is shared.
Two APIs, one orchestration story
Two endpoints — create a group and fetch all groups under a partner. Tag in any number of merchants. The terminals registered to the group serve every member.
Settlement, reporting, and branding stay independent per merchant.
Five endpoints to onboard service providers — POS systems, kiosk operators, vending vendors — under your partner umbrella. Track application status, fetch configs, manage the lifecycle.
For partners building their own ecosystem of integrators.
Composes with the rest of the platform
Each merchant in a multi-merchant group still pulls its own settlement reports through the Reporting API, gets its own branding through the Branding API, and runs against its own Billing plan. The group is a thin coordination layer — the underlying primitives don't change.
Marketplace and shared-fleet workflows shouldn't require a different platform. With Surfboard they don't.
Create your first multi-merchant group
Two endpoints in the Multi-Merchant API. Five in the Service Providers API. Together they cover marketplace operators, festival ecosystems, food courts, and partner-of-partner integrations.
// Create a multi-merchant group for a food court
POST /partners/:partnerId/multi-merchant
{
"country": "SE",
"zipCode": "11122",
"name": "Hötorget Food Court",
"email": "ops@hotorget.example"
}
// Onboard a third-party Service Provider
POST /partners/:partnerId/service-providers
{
"name": "Acme Kiosks",
"type": "KIOSK_OPERATOR",
"country": "SE"
}