Agencies — run commerce as your own platform

An agency, a studio, or a software company whose own customers are merchants can run Galactic Core as its own commerce platform. You bring the merchants and the brand; Galactic Core is the commerce engine underneath and stays out of sight. Your merchants sign in to your product, at your domain, and the API keys they copy carry your name. The chain runs:

Galactic Core  →  your platform  →  your merchants  →  their customers

White-label

Your name, logo, domain, sender addresses, and API key prefix. Merchants never encounter Galactic Core.

Your own plans and prices

Name your tiers and set your prices — a flat fee, a share of what a merchant sells, or both — charge with your own payment processor, and keep the difference between what you charge and what you pay us.

This page is the reference for how it works. The agencies overview covers the proposition and carries the application form.

What your merchants see

A merchant you onboard gets the full Galactic Core admin — catalog, orders, payments, the storefront API, the assistant — under your identity:

Surface	What it shows
The app	Your logo, favicon, browser title, brand name, and product wording
The domain	`studio.youragency.com`, or a subdomain we host for you
Email	Sent from your address, on your verified sending domain
API keys	`youragency_sk_live_…` instead of `tybrite_sk_live_…`
The assistant	Named by you, if you’d rather it wasn’t “Raf”
The look	Your colour palette, spacing and corner treatment, and which sections appear in the menu

Branding is presentational. It changes what a merchant reads, not how commerce behaves: orders, payments, and webhook signatures are issued and verified by Galactic Core exactly as they are for a direct store.

Branding covers identity — name, logo, wording, domain, sender, key prefix. Colour, density and menu composition are set separately, through Appearance. The interface keeps its own layout and component design either way.

Appearance

Describe how your merchants’ admin should look and the result is composed for you: a full colour ramp resolved from your brand colour, a spacing and corner treatment, the small set of wording your merchants read, and which sections appear in their menu. Nothing reaches a merchant until you approve it. A generated look is saved as a draft and shown to you on a working representation of the admin — the sidebar, the cards, a table, the primary button — so you review what your merchants will actually see without signing into their account. Approving it applies it; every earlier version is kept, and you can return to one or remove theming altogether. Two limits shape what a description can produce:

A palette must stay readable. Button labels and link text are checked for contrast against the surfaces they sit on, and a palette that would leave a merchant unable to read their own orders page is rejected rather than applied.
Hiding a section is presentational. It tidies the menu; the page stays reachable by URL and permissions are unchanged. Anything that must genuinely be denied is a matter of roles and permissions instead.

Sections can be hidden and reordered but not renamed, so the assistant’s guidance about where to find things stays correct for everyone.

Generating a look consumes your platform’s own assistant credits. Your merchants are never charged for your branding decisions, and a look that is rejected refunds the credits it cost.

Onboarding merchants

You invite a merchant from your dashboard, choosing the plan tier they start on. They receive a branded invitation, and accepting it provisions a store that belongs to your platform from the first moment — never a Galactic Core store that is later transferred. Each invitation is single-use and expires, and is bound to the address you sent it to. Merchants you onboard get the same free trial as any other, and a store on trial costs you nothing — you begin paying for it when the merchant starts paying you. You can move a merchant between tiers at any time.

Letting merchants sign themselves up

Alongside invitations, merchants can sign up on their own from your marketing site. There are two ways, and both produce the same result — a store that belongs to your platform from the first moment.

Point at the hosted page

Send your signup call-to-action to /register on your own domain. Nothing to build: the page already carries your name, logo and colours, and the verification email comes from you.

Host the form yourself

Build the signup form into your own site and call the three steps below. You control the fields, the layout and the wording; we create the store.

Which platform a merchant joins is decided by the domain they signed up on, never by anything the page sends. A signup from studio.youragency.com belongs to you; the same form served from somewhere else does not. That means you cannot accidentally attribute merchants to the wrong platform, and nobody else can claim yours. Your subdomain works from the day your platform is created — a custom domain changes which address merchants visit, not how they are attributed.

The three steps

Post to https://api.tybritelabs.com/v1/agency/merchant-signup from your own domain. Each step is a JSON body with an action. No API key is needed — the domain you post from is what identifies your platform.

Send the code

{ "action": "send", "email": "owner@merchant.com", "password": "their-chosen-password" }

Field		Notes
`email`	required	Must be a real, deliverable address; disposable domains are refused
`password`	required	At least 8 characters — this becomes the merchant’s password

Creates the pending account and emails a six-digit code under your brand. The merchant is not a store yet, and nothing is provisioned until they prove they own the address. Returns { ok: true, sent: true }. Sending again replaces the previous code.

Verify the code

{ "action": "verify", "email": "owner@merchant.com", "code": "123456" }

Field		Notes
`email`	required	The address the code was sent to
`code`	required	The six digits from the email

Confirms the address. A code expires after fifteen minutes and locks out after six wrong attempts — request a new one in either case.

Create the store

{
  "action": "provision",
  "email": "owner@merchant.com",
  "password": "their-chosen-password",
  "store_name": "Galactic Agency Store",
  "name": "Store Owner",
  "store_code": "GAS001",
  "business_type": "retail",
  "country": "US",
  "currency": "USD",
  "phone": "+1 555 0142",
  "address": "14 Mill Lane, Portland, OR",
  "store_email": "hello@galacticagencystore.com"
}

Field		Notes
`email`	required	Must already have completed step two
`password`	required	The same password used in step one
`store_name`	required	The merchant’s business name
`name`	optional	The owner’s own name; defaults to the email
`store_code`	optional	Exactly 6 letters or numbers. Supply one and it is used as given — a clash is reported so the merchant keeps the code they chose. Omit it and one is derived from the store name
`business_type`	optional	`retail` by default
`country`	optional	Two-letter country code; sets sensible tax and currency defaults
`currency`	optional	Three-letter currency code; defaults from the country, else USD
`phone`	optional	The business phone
`address`	optional	The trading address
`store_email`	optional	The store’s public contact address; defaults to the owner’s email

Returns the new store and a session, so you can drop the merchant straight into the admin already signed in rather than sending them to a sign-in screen:

Response

{
  "ok": true,
  "store": { "id": "6666a0aa-…", "store_name": "Galactic Agency Store", "store_code": "GAS001" },
  "agency_id": "1111…",
  "session": { "access_token": "eyJ…", "refresh_token": "btcd…", "expires_at": 1786884265 }
}

A store created this way is provisioned exactly like any other — roles, chart of accounts, categories, payment and tax settings, and the free trial — and appears in your dashboard immediately.

Step three refuses an address that has not completed step two, so the endpoint cannot be used to create stores by posting to it. Send the requests from your own domain: that is what identifies the platform the merchant is joining.

Merchants who sell wholesale

A merchant on your platform can sell to business buyers as well as shoppers: quoting per buyer, taking purchase orders, and invoicing on terms. There are two routes in, and both end with a Galactic Core decision.

A merchant already trading

You request the change from the merchant’s page. The review looks at what the store has done — orders, catalogue, customers, how long it has traded — which is why it applies to a store with history rather than a new one.

A business that sells wholesale

They apply through your onboarding as a wholesaler. You collect the required checks, review them, and forward a recommendation; Galactic Core verifies before the store goes live.

What you collect

Galactic Core publishes what is required, per country, and your portal will not forward an application until every item is present — the missing ones are named together rather than one at a time. How you collect them is yours: a form on your own site, an email thread, a call. The required set covers the registered legal name and registration number, country, tax identifier, certificate of incorporation, proof of trading address, beneficial owners at 25% or more with an identity document each, the authorised signatory, what the business sells and to whom, and your own assessment. Your intake may ask for more; it cannot ask for less. An application records which version of the requirements it satisfied, so one reviewed earlier is not made incomplete by a later change to the list.

Decisions

Three outcomes, not two. Alongside approval and decline, an application can be sent back for more detail with a stated reason — the same application is forwarded again once you have what was asked for, rather than the business starting over. You are told the outcome either way. The message to your applicant is prepared for you and not sent: you edit it and send it when you are ready, under your own brand and reply-to address. If you would rather it went out on its own, switch that to automatic. Sent messages are kept as they were sent.

Selling wholesale and being listed as a verified supplier are separate. A converted store can quote, take purchase orders and invoice immediately; the verified badge and directory listing follow the review described above.

Merchants buying from each other

A wholesaler on your platform can sell to the retailers on it. A buyer account can be linked to the buying merchant’s own store, so a retailer you onboarded orders from a wholesaler you onboarded, and sees their own quotes, purchase orders and payables from inside their own admin. This grows with your platform rather than needing anything switched on for it: each additional wholesaler is another source your retailers can buy from, and each additional retailer is another buyer for your wholesalers. Both sides stay separate businesses with their own catalogues, pricing and credit terms — the wholesaler prices per buyer as they would for anyone else.

Your plans, your prices

Your tiers are yours to define. You decide how many you offer, what each is called, what each grants and what each costs. Your account carries a ceiling for every allowance and for the set of capabilities you may sell; beneath it you compose freely.

You define

How many tiers exist, their names and descriptions, the order they appear in, what each grants — request allowance, storage, assistant usage, automation runs, stores, and which capabilities are switched on — and what each costs, monthly and annually, in the currency you charge in.

Your ceiling

The most any of your tiers may grant, set per account. A capability outside it is not shown to you as an option, so you cannot advertise something to a merchant that would then fail for them. A value above it resolves to the ceiling rather than erroring.

You enter a monthly and an annual price and the annual saving is worked out from the two, so the discount you advertise can never drift from the prices you actually charge. Changing what a tier grants reaches merchants asymmetrically, and deliberately: an increase applies immediately, while a reduction applies at that merchant’s next renewal. A merchant who has paid for the period keeps what they bought. A tier that merchants are currently on cannot be removed. Move them to another tier first.

What a merchant pays past their allowance

A merchant who exceeds their plan’s monthly allowance gets a free buffer, and beyond it pays as they go. You set all three figures — the buffer, the block size and the price per block — and they are what your merchants see and are charged. Galactic Core bills you for the same consumption at its own rate. The difference either way is yours: setting a rate below what you pay means absorbing it, which is a choice the portal shows you rather than prevents. A merchant on a free trial never accrues an overage charge, whatever you set. Going over pauses new usage instead. A plan can carry a percentage of what the merchant sells alongside its fee, or instead of one. A plan priced at zero plus a rate charges only on sales; a plan with both charges both.

Plan	What the merchant pays	Suits
`$49 / month`	A flat fee only	A retail merchant with steady volume, or one just starting
`$99 / month + 1.5% of sales`	Both	The common shape — a floor, and upside as they grow
`2.5% of sales`	The share only	A merchant who will not commit to a monthly fee

A retail merchant on the middle plan selling $20,000** in a month pays **$ 99 + $300. The same plan given to a wholesaler counting invoices instead would charge on what those invoices were paid, not on what was raised. You choose what the percentage applies to per plan:

Counted	Taken from
Online orders	Orders that were paid
Sales at the counter	In-store sales, optionally after returns
Wholesale invoices	What an invoice was actually paid, not what was invoiced

Counting invoices at what was paid matters on terms: an invoice raised in January and settled in March produces no charge until the merchant has the money. The charge is worked out per period and appears for the merchant under Settings → Usage → Share of sales, showing the sales counted, the channels they came from, the rate, and the resulting amount. A period stops changing once it has been billed, so a refund arriving later is reflected in the next period rather than restating an amount already paid. An optional floor and cap bound what any single period can come to.

Getting paid

Two ways to run it:

Invoice your merchants yourself. The default. You see what each merchant owes, and you collect it however you already collect money.
Let them subscribe in-app. Connect your own payment processor — Stripe, Paystack, Lemon Squeezy, or Paddle — and merchants pick a plan and pay inside the product. The charge settles directly to you; Galactic Core never holds your revenue and never sits between you and your customer.

If you’d rather bill through a processor we don’t support natively, you can supply your own billing integration and it will be used for subscriptions, credit top-ups, and renewals alike — see Custom Integrations.

What you pay us

Separately from all of that, Galactic Core invoices you at wholesale: a base fee per active merchant store, plus metered usage. Your dashboard shows revenue, wholesale cost, and the margin between them per merchant, so an account costing more than it earns is visible per merchant rather than only in the monthly total. Merchants on a free trial are not billable to you.

Domains

Merchants can reach your platform two ways:

A subdomain we host — youragency.gc.tybritelabs.com. Works immediately, nothing to configure.
Your own domain — studio.youragency.com. Add the domain in your dashboard, create the DNS records it shows you at your registrar, and the certificate is issued automatically once they resolve.

If you build tools of your own — a reporting dashboard, an inventory sync, an onboarding wizard — your merchants can authorize them the same way any application authorizes against Galactic Core, except the consent screen is yours: your name, your domain. Those applications are scoped to your platform. A merchant on your platform can only authorize your applications, and yours can only reach your merchants. See GC Connect for the flow itself.

Assistant credits

The in-app AI assistant runs on credits. Merchants top up through your processor at a rate you set, and Galactic Core meters what they consume onto your wholesale bill — so, as with plans, the spread is yours. You can also cap what any one merchant is able to spend, independently of what their plan would otherwise allow.

Starting merchants with credits

A merchant you onboard on a free trial receives no assistant credits unless you fund them. You can turn that on, choose how many credits each new merchant gets, and prepay a balance the grants draw from — so a merchant’s first session can include the assistant rather than an invitation to buy it. The balance never gates a merchant. If it runs out, their store is still created and their trial starts as normal; they are queued, and receive their credits in the order they joined as soon as you top up. The ledger shows every grant against the merchant it went to. Credits you fund this way are yours, bought at our rate. They are not metered onto your wholesale bill a second time when the merchant spends them.

Connected tools

Marketing, accounting, catalogue sync and advertising are connected with an app registration held by whoever runs the platform. Register your own and every merchant you onboard connects through it: the provider’s approval screen names your platform, and the connection appears in your provider account rather than anyone else’s. Configure these under Integrations in your dashboard. Each one shows the redirect URL — and, where the provider needs one, the webhook URL — to paste into the app you create at that provider. The URLs are derived from your own domain, so there is nothing to compose by hand. A tool you have not configured is not offered to your merchants. It does not fall back to the underlying platform’s registration, because a merchant completing that flow would see a name you never chose, on a screen you cannot change. The same applies while you are still setting one up: an integration stays off until you switch it on, so a merchant never meets a half-configured option. Your merchants’ own logins stay theirs. You supply the app registration; each merchant authorises their own account through it, and the resulting access is stored per store and encrypted. One merchant’s connection is never reachable from another’s.

Advertising

Google Ads and Meta Ads work the same way with one material difference: both providers approve an advertising developer account directly with you, and both review that application. Google issues a developer token against your own manager account; Meta requires app review and business verification. Neither is a setting to switch on, and the wait is theirs rather than ours. Until you hold your own, advertising is not offered to your merchants. That is deliberate — a developer token carries the quota and compliance standing of whoever registered it, and a manager account is visible in the merchant’s own advertising dashboard whatever the approval screen said. There is no arrangement where advertising runs on someone else’s registration and still looks like yours.

Changing a credential

Saving or removing a credential asks for a confirmation code sent to you, the same as a pricing change. A credential decides which third party receives your merchants’ commerce data, and swapping one redirects that flow without anything in a merchant’s experience changing — so it is not a write that should rest on a live session alone. Removing a credential deletes it and stops the integration being offered. Merchants who had already connected reconnect once you configure it again.

Fields for every merchant

Galactic Core models the commerce every merchant has in common. What it cannot model is the thing your particular industry records on every order — a case reference for a legal platform, a practitioner for a clinic platform, a delivery window for a courier-heavy one. You define those once and every store you run receives them, including stores onboarded later. A merchant fills the field in as they would any other, on the record it belongs to, and it travels with their exports and their API — see Custom Fields for how they reach a storefront. Why it belongs to you rather than to each merchant. A merchant can add their own fields too, and most do. But if every merchant invents their own name for the same idea, nothing can be reported across them — “Case ref”, “case_number” and “Matter” are three fields, not one. A field you define is the same field in every store, which is what makes an estate-wide view possible at all. That is also why a merchant can fill one of your fields but cannot rename, retype or delete it; they remain free to add their own alongside. Set them up under Integrations → Fields for every client. Removing one removes it, and everything recorded in it, from every store — so it is a deliberate act rather than a tidy-up.

Standing rules for every merchant

A storefront that never changes after launch stops matching the business behind it. Galactic Core’s standing rules keep a store current on a schedule — rotating a collection to what is actually selling, watching for stock that has stopped moving, keeping product pages findable — and ordinarily a merchant asks the assistant for each one. Most never will. That is the same gap you close by choosing a plan, a catalogue and a set of fields on their behalf: you know what the merchants you serve need running, and they should not have to discover it. So you define a default set, and every store you onboard starts with it already working. Set it up under Standing Rules, where you can also see what each of your merchants is running today and change or remove any of it. Inherited, not operated. A rule a store receives belongs to that merchant from the moment the store exists. They can pause it, retune it, or remove it, exactly as if they had asked for it themselves, and what they change stays changed — including against you. That boundary is deliberate: a merchant who finds their own deliberate pause reversed has learned their settings do not hold, and the rational response is to stop using the feature. Changes reach new stores. Editing your default set changes what stores you onboard from then on. It does not reach back into stores that already have a rule, because a merchant may have tuned it, and a rule they deliberately removed must not reappear. Your limits are still theirs. A rule you hand out runs under the same constraints as one a merchant asks for: anything that costs money is prepared as a draft and waits for them, per-run ceilings hold, and the failure breaker applies. You can give a merchant a rule; you cannot give one more authority than the merchant themselves has. Rules that target something specific to one catalogue — a particular collection to rotate — cannot be shared, because the thing they point at does not exist in another merchant’s store. The rules available to hand out are the ones that make sense anywhere.

Your API, on your own domain

Every platform is given an API host of its own — api.yourplatform.gc.tybritelabs.com by default, or your own api.yourbrand.com added through Domains. It is provisioned when your platform is created, so there is nothing to enable. This matters most for the URLs your merchants hand to somebody else. A merchant publishing a catalogue feed pastes that URL into Google Merchant Center or a partner’s importer; a merchant connecting a payment provider pastes a callback URL into that provider’s dashboard. Those outlive any screen, so they carry your host rather than ours. Nothing else about them changes — the same token guards the same feed, and the request is authenticated identically. Your host serves the whole API, not only those URLs, which makes it a foundation rather than a cosmetic detail:

Publish the API specification as your own. Turn it on under Integrations → Your API specification and your platform serves its own OpenAPI document at /openapi.yaml on your host, generated from the live API so it never describes something we do not serve. We email you the URL and a ready-made GitHub Actions workflow when you enable it.
Write what it says. The document’s title, its opening description, the support address and page, the terms page, and the sentence telling developers where to get their API keys are all yours. You set them once under the same section and they are applied to every copy served, so there is no file to download and edit each time the API changes. Every field is optional and starts from a default built from your brand name, so the document reads coherently before you touch any of them.
Ship your own client library. Generate one from that specification with the workflow above, or take the existing SDK and set its base URL — it is a single value, not a hardcoded host. You publish it, from your own repository with your own npm token: we never hold a credential that could release code under your name.
Keep it current on a schedule. The workflow we email you fetches your specification, regenerates the client from it and publishes the result — weekly, and on demand whenever you trigger it. It runs in your repository, on your runners, with your own npm token in NPM_TOKEN; the only thing it takes from us is the specification URL. Change the schedule, or drop the trigger and keep the manual run, if you would rather decide when a release happens.
Document it as your API, because it behaves identically. It is the same endpoint.

What stays as it is. Request signature headers, key prefixes and the environment header keep their names. Renaming them would break every integration already written against them, and a developer reading a header name is inside the integration rather than choosing a platform. Your merchants’ keys, tokens and quotas are unchanged — the host is where the request arrives, not what authorises it.

Your own apps

Your market needs something Galactic Core does not ship — a local payment method, a regional courier, your own CRM sync. Build it once as a Custom Integration, register it against your platform rather than a single store, and every merchant you onboard can use it. You own the logic; the merchant owns the credentials. The handler is yours, written once. The merchant supplies their own account details, which are stored per store and encrypted, so one merchant’s keys are never reachable by another and your handler sees only the invocation it is executing. Where the merchant finds it follows what the integration is:

What it is	Where it appears
An implementation of a provider interface (`PaymentProvider`, `ShippingProvider`, `TaxProvider`, …)	With that capability, beside the built-in options — a custom payment adapter is another processor in Payment settings
Anything else, with a surface declared in its manifest	Its own tab under Integrations, its form rendered from the manifest’s `config_schema`
Anything else, with no surface declared	Listed under Integrations → Extensions, marked as provided by you

A merchant installs it, configures it and can switch it off for their store. They cannot edit or delete what you built, because the definition runs for every merchant you have — the same asymmetry that governs a plan you assign. You can mark an app to install automatically for merchants you onboard from then on. Turning that on does not reach back into stores already trading; an existing merchant installs it themselves, or you do it for them.

Hosted or on your own infrastructure

The contract is identical either way — same input, same expected return, same logging, timeout, fail-mode and circuit breaker, all documented under execution modes. What differs is where the code runs, and one consequence decides it:

Hosted runs in Galactic Core’s sandbox. Your merchant’s credentials are read from the vault and injected at call time. A hosted handler is invoke-only, so it suits a provider you query — initiating a charge and polling its status.
On your own infrastructure, Galactic Core sends the same input as a signed HTTPS request to your endpoint and expects the same reply. Your own keys stay with you. This is what suits a provider that needs to receive an asynchronous callback, since your endpoint has an address and a hosted handler does not.

Hosted execution uses Galactic Core’s compute and is billed to you as a line on your wholesale invoice. Running it yourself is one outbound signed call and is not billed as execution — the trade is availability, which the timeout and circuit breaker absorb.

Charging for an app

An app is free unless you price it. You can set a monthly fee per merchant who has it installed, a fee per execution, or both. Whatever you charge appears on the bill your merchant already receives from you, itemised per app alongside their subscription — one bill, not one per app. They can see the monthly component, how many executions ran, and the rate applied.

Your price to your merchant and Galactic Core’s price to you are independent. Charging nothing per execution does not reduce what hosted execution costs you; charging more than it costs is your margin. A failed execution is never charged to the merchant — it still used compute if it ran hosted, so it appears on your invoice, not theirs.

A period already billed does not reopen. An execution arriving after a month has been invoiced is not added to it retrospectively.

Growing the platform

Your merchants are ordinary stores that carry your label. They keep their own catalogues, stock, storefronts and caches, so a platform with three hundred merchants is three hundred stores’ worth of load rather than a new class of problem — and one busy merchant does not contend with another for the same rows. Sellers on a marketplace share a single storefront, which is a different shape of load; if you run a marketplace as well, see Marketplaces at Scale for what changes for the merchants taking part in it. Three things do behave differently once your book is large. Your own reporting spans everything you own. A merchant’s screens read their own store. Your client list, your usage figures and your monthly bill read every merchant at once, so those are the queries that grow with your platform rather than with any one client’s trading. They are indexed for that shape deliberately, and the monthly close is the one to know about because it touches every merchant’s usage for the period. One merchant can move to dedicated infrastructure and stay yours. If a single client outgrows shared capacity, that store moves to its own database and API layer while remaining on your platform: your plan, your billing, your brand, your relationship. Nothing changes for your other merchants, and you do not move the whole book to accommodate one client. The mechanics are in Scaling & Reliability. A connected tool you supply is shared by everyone who uses it. When your merchants connect through your own marketing or catalogue account, the provider counts the traffic against that account — so an unusually busy period at one merchant can reach the provider’s limit for all of them. Where that happens the work is retried rather than dropped: hitting a provider’s rate limit delays a sync, it does not discard it. If you expect sustained volume across many merchants, ask the provider about your account’s limits before you rely on it.

Running a marketplace as well

If you want a single storefront where your merchants sell alongside each other — one catalogue, one checkout, commission on each sale — that is a marketplace, and it runs on the same platform you are already on. Your existing merchants become its sellers; their catalogues, orders and customers stay where they are. What it takes is setting your commission and payout terms, not moving any data. A marketplace of yours sits alongside the platform you already run rather than replacing it. Your merchants keep their own storefronts, and the same merchants appear in your marketplace — one relationship, one bill, one dashboard. A merchant who sells under their own brand on Monday and through your marketplace on Tuesday is doing both from the same store.

Only your merchants

Your marketplace is closed. Its sellers are the merchants you onboarded and nobody else — there is no public application form and no route by which an outside business joins. Every seller is already your client, already billed by you.

Included unless they decline

A merchant you onboard is part of it from the start, and can leave it from their own settings at any time. Opting out removes their products from your storefront and changes nothing else — their own storefront, orders and customers carry on. They can rejoin the same way.

Your commission, your terms

You set what you take on each sale: one rate across the marketplace, tiers by value, or a rate per category or per merchant. You can preview what a given order would settle before you commit to a rule.

Paid on your own account

Shoppers pay into your own payment account, each seller is paid their portion automatically, and your commission stays with you. Galactic Core never sits between you and the money.

What it costs

A marketplace is a subscription on top of what you already pay: $1,000 a month including a hundred participating merchants, then$ 20 a month for each merchant beyond that. Nothing else changes — your per-store fee, your usage, and your existing invoice lines all stay as they are, and the subscription appears as its own line. Serving shoppers and business buyers are different storefronts, so an agency doing both runs one of each rather than mixing them.

This is a commercial decision rather than a setting to switch on: commission and payout terms shape what your sellers earn, and the subscription is a commitment. Talk to us before you commit to a shape.

Isolation

Every merchant store carries the identity of the platform that owns it, and that ownership is the data boundary. Your dashboard reaches your merchants and no others; a direct Galactic Core store is never visible to you, and yours are never visible to another platform. Your team members have roles of their own — owner, admin, and member — which control who can invite merchants, change pricing, and manage domains.

Where things live

Agency configuration is administrative, so it lives in your dashboard rather than the public API — there are no /v1/agency/* endpoints to call. Your merchants’ stores use the same API, SDK, and webhooks documented throughout the rest of this site; nothing about the commerce surface changes because a store belongs to a platform. Two pieces are developer-facing: the merchant signup steps above, for a signup form you host yourself, and the billing integration described earlier, documented with the other Custom Integrations. Both are deliberately separate from the storefront API — they are administrative, so they are not called with a storefront key.

Apply to run your own platform

An overview of what running a platform looks like, and the application form.

Talk to us first

Agency access is enabled per platform. Tell us what you’re building and we’ll set you up.

​Agencies — run commerce as your own platform

White-label

Your own plans and prices

​What your merchants see

​Appearance

​Onboarding merchants

​Letting merchants sign themselves up

Point at the hosted page

Host the form yourself

​The three steps

​Merchants who sell wholesale

A merchant already trading

A business that sells wholesale

​What you collect

​Decisions

​Merchants buying from each other

​Your plans, your prices

You define

Your ceiling

​What a merchant pays past their allowance

​Charging a share of sales

​Getting paid

​What you pay us

​Domains

​Sign in with your platform

​Assistant credits

​Starting merchants with credits

​Connected tools

​Advertising

​Changing a credential

​Fields for every merchant

​Standing rules for every merchant

​Your API, on your own domain

​Your own apps

​Hosted or on your own infrastructure

​Charging for an app

​Growing the platform

​Running a marketplace as well

Only your merchants

Included unless they decline

Your commission, your terms

Paid on your own account

​What it costs

​Isolation

​Where things live

Apply to run your own platform

Talk to us first

Agencies — run commerce as your own platform

What your merchants see

Appearance

Onboarding merchants

Letting merchants sign themselves up

The three steps

Merchants who sell wholesale

What you collect

Decisions

Merchants buying from each other

Your plans, your prices

What a merchant pays past their allowance

Charging a share of sales

Getting paid

What you pay us

Domains

Sign in with your platform

Assistant credits

Starting merchants with credits

Connected tools

Advertising

Changing a credential

Fields for every merchant

Standing rules for every merchant

Your API, on your own domain

Your own apps

Hosted or on your own infrastructure

Charging for an app

Growing the platform

Running a marketplace as well

What it costs

Isolation

Where things live