Marketplace Payments, Without the Workarounds
Food courts, festivals, shared retail spaces, pop-up vendor networks — every marketplace breaks the standard one-merchant-per-terminal model. Surfboard ships shared-fleet payments as a first-class API: one terminal serves many vendors, each with their own settlement, branding, and reporting. The way marketplace payments should have always worked.
Built for Shared Hardware, Independent Settlement
Marketplaces have always been awkward in payments. The hardware is shared. The vendors are independent. The customer experience needs to feel like one place. The reporting needs to feel like many. Surfboard's Multi-Merchant API and Service Providers API are designed exactly around this constraint set.
One terminal serves many merchants. Each merchant keeps their own branding, pricing, settlement, and reporting. The customer sees a coherent experience because the branding flips per transaction. The marketplace operator sees consolidated visibility. Each vendor sees their own books. The reconciliation pipeline stays clean because per-vendor settlement is the default — not a workaround.
One stack for every marketplace pattern
Food courts, ghost kitchens, festival vendor networks, mall concession spaces, pop-up retail collectives, multi-artist galleries, B2B trade shows, transit-hub vendor concourses — all of them are the same payments problem. Shared infrastructure, independent vendors, per-vendor settlement. Surfboard solves it once, applies it to all.
Why marketplaces choose Surfboard
Six reasons marketplace operators select Surfboard over building custom routing or stitching together generic processors.
1. Multi-Merchant Terminals as a First-Class Concept
Most payment platforms force one-merchant-per-terminal — a model that breaks the moment you run a marketplace. Surfboard's Multi-Merchant API is built for shared infrastructure: one terminal serves many vendors, each with independent settlement, branding, and reporting.
- Food halls and shared kitchens
- Festival vendor networks
- Shared retail spaces and consigned-artist galleries
- Pop-up event marketplaces
2. Per-Vendor Settlement, Not Aggregate Payouts
Each vendor in your marketplace gets their own settlement schedule, their own payout, their own reporting. Funds route correctly to each merchant entity at the moment of settlement — no manual reconciliation, no aggregate-to-vendor splits.
Compliance and audit trails stay clean even when the underlying device fleet is shared.
3. Per-Vendor Branding on Shared Hardware
Customer at a food hall taps their card at vendor A. The terminal greets them in vendor A's brand. They walk to vendor B. Same terminal, vendor B's brand. The branding cascade flips per transaction based on the merchant the order belongs to.
Critical for marketplaces where each vendor's brand identity matters for repeat customer experience.
4. Service Providers API for Sub-Aggregation
Marketplaces of marketplaces, festival operators with sub-event organizers, mall managers with concession partners — all need to onboard third-party service providers under a parent entity. The Service Providers API covers the full lifecycle.
- Onboard third-party application providers programmatically
- Track application and approval status
- Per-provider configurations and routing
5. Programmatic Vendor Onboarding
Vendors join your marketplace, paste their URL, and have a fully branded, ready-to-trade payment setup in minutes. AI-generated branding from the URL, automatic terminal assignment, KYB verification, default billing plan — all programmatic.
Pair with the AI API for instant white-label setup at marketplace scale.
6. The Whole Stack, Not Just Routing
Marketplaces typically piece together routing, KYB, branding, settlement, and reporting from separate vendors. Surfboard ships them as one platform — Multi-Merchant for routing, AI + Branding for vendor identity, Reporting for per-vendor settlement, Notifications for vendor statements, and Tokenization for cross-vendor customer recognition.
One integration. Years of marketplace-payments work already done.
The marketplace primitives Surfboard ships
Customer experience that feels like one place
The customer at a food hall doesn't think about which restaurant runs which terminal. They tap, they pay, they get a receipt. Behind the scenes, Surfboard routes the funds to the correct vendor, applies the correct branding to the receipt, and settles to the correct merchant entity.
Marketplace payments should be invisible to the customer. With Surfboard, they are.
Stand up your marketplace
Create a multi-merchant group, tag in vendor merchants, and the same terminal fleet routes correctly. Per-vendor settlement, branding, and reporting all preserved.
// Create a marketplace multi-merchant group
POST /partners/:partnerId/multi-merchant
{
"country": "SE",
"zipCode": "11122",
"name": "Hötorget Food Court",
"email": "ops@hotorget.example"
}
// Onboard a vendor under the group with auto-branded portal
POST /partners/:partnerId/merchants
{
"businessName": "Vendor A",
"country": "SE",
"registrationNumber": "5566778899",
"multiMerchantGroupId": "mmg_hotorget",
"brandingFromUrl": "https://vendor-a.example"
}