Check out a multi-merchant cart
Create a single order for a cart that contains items from multiple merchants in the marketplace, and start a payment for the whole basket. Each item names the merchant it belongs to; items are validated against the marketplace catalog, commission is resolved per merchant, and one payment covers the entire order.
The response includes a client_secret to complete the payment on the
storefront and a per-merchant breakdown of gross, discount, commission, and net
amounts. Once payment succeeds, the order finalizes automatically β no further
call is required.
Discounts. Pass the optional discounts array to apply a merchantβs own
promotion or gift card to that merchantβs portion of the basket β each entry
names the merchant_store_id and an optional promotion_id and/or
gift_card_code, and the discount reduces only that merchantβs subtotal.
Marketplace-wide promotions run by the operator apply automatically; you do not
pass them. The response reports discount_total, the
operator_funded_discount (the share the operator funded), a per-merchant
discount_breakdown, and discount_amount plus merchant_gross on each
merchant_breakdown entry.
π‘οΈ The server is the price authority (anti-tampering). You never send money
amounts on this call β only identifiers. Each itemβs price is recomputed from the
marketplace catalog, and a discounts entry only names a promotion_id /
gift_card_code; the server independently resolves the actual discount that
merchantβs promotion or gift card grants (and the operator-funded share),
computes every gross, discount_amount, merchant_gross, commission, and the
payment total from those resolved values, and charges exactly that. A named
discount that doesnβt validate (expired, ineligible, wrong store) is rejected with
400 discount_invalid rather than silently applied. There is no client-supplied
discount_amount or per-item price to tamper with β a manipulated basket cannot
lower what is charged. The resolved breakdown is then held server-side and used
verbatim to finalize the order after payment succeeds; nothing the client sends
after checkout can change what each merchant is paid.
Stock is reserved at checkout: the items are held against each merchantβs
inventory immediately so concurrent shoppers cannot oversell the last units,
and the hold becomes a real stock reduction when payment succeeds. If an item
cannot be held, the call returns 400 insufficient_stock and no order or
payment is created. Holds expire automatically if payment is never completed,
returning the stock to availability.
Requires the marketplace operator key.
Authorizations
API Key Authentication
Use your API key in the Authorization header:
Key Types:
Secret Keys (Server-Side Only):
- Format:
tybrite_sk_live_*(production) ortybrite_sk_test_*(sandbox) - Full read/write access to all endpoints
- β οΈ NEVER expose in client-side code or public repositories
- Required for: write operations, authentication, payment verification, AI recommendations
Publishable Keys (Client-Safe):
- Format:
tybrite_pk_live_*(production) ortybrite_pk_test_*(sandbox) - Read-only access (GET requests only, plus POST semantic search)
- β Safe for client-side JavaScript, mobile apps, and public code
- Allowed for: browsing products, search, CMS content, pricing queries
Endpoint-Specific Requirements:
- Authentication endpoints (
/v1/auth/*): Secret key required - Payment verification (
POST /v1/payments/verify): Secret key required - AI Recommendations (
POST /v1/recommendations): Secret key required - Semantic Search (
POST /v1/search): Both key types allowed (read-only operation) - All write operations: Secret key required
- All read operations: Both key types allowed
Using a publishable key for restricted operations returns 403 Forbidden.
Headers
Session token of a shopper signed in through Galactic Core, tying the checkout to their account rather than treating it as a guest checkout. Optional. Also accepted as x-auth-token.
Alias of x-customer-token.
Body
The cart line items to check out.
1ISO currency code for the order. Defaults to USD.
"USD"
Optional per-merchant discounts. Each entry applies a merchant's own promotion and/or gift card to that merchant's portion of the basket, reducing only that merchant's subtotal. Marketplace-wide promotions run by the operator apply automatically and are not passed here.
Where the shopper came from, recorded so the sale is credited to the right traffic source in the merchant's reports. The same fields are also accepted at the top level of this request body if you already send them that way.
Response
The multi-merchant order was created and is awaiting payment.
A created multi-merchant order awaiting payment. Use client_secret to
complete the payment on the storefront; the order finalizes automatically
once payment succeeds.
Identifier for the multi-merchant order.
Human-readable reference for the order.
"MKT-100042"
Identifier of the payment to complete on the storefront.
Secret used by the storefront payment form to complete the charge.
"USD"
245
245
Total discount applied across the whole basket β the sum of every merchant's own promotion and gift card discounts plus any marketplace-wide promotion run by the operator.
10
The portion of discount_total funded by the marketplace operator (for example a marketplace-wide promotion). The remainder is funded by individual merchants.
5
Per-merchant breakdown of how discounts were applied.
Per-merchant gross, discount, commission, and net amounts for this order.

