Skip to main content
Galactic Core connects to the services a commerce business already runs on. Each integration below is built into the platform: a merchant supplies their own credentials and the capability works, with no code to write and nothing to host. Integrations are grouped by capability rather than by vendor, because that is how the decision is made — a merchant picks a way to take payments, then picks which processor. Where a service is not listed, the same capability is open to any provider through an extension, and each section names the interface that applies.

Payments

Taking money from a shopper at checkout, across the storefront API and the in-store point of sale. Availability is filtered by the store’s country, so a merchant is only offered processors that operate where they trade. A processor still configured with test credentials is withheld from live shoppers entirely rather than offered as a checkout that cannot charge.

Stripe

Cards and wallets in most markets. Stripe is also the processor behind marketplace split payments: an operator’s merchants are onboarded as connected accounts, and a single shopper payment is divided between them at capture, so the platform never holds or forwards their money.

PayPal

Wallet and express checkout, for shoppers who prefer to pay without entering card details.

Paystack

Cards, bank transfer and mobile money across Nigeria, Ghana, South Africa, Kenya and Côte d’Ivoire — the payment methods those markets actually use, which card-only processors do not reach.

M-Pesa

Mobile money in Kenya, both as a prompt sent to the shopper’s phone at checkout and as a customer-initiated payment to a merchant’s paybill, with a validation step before the payment is accepted.

Cash

In-store and cash on delivery, recorded against the order and settled outside any processor. Bring your own: any processor can be added through the PaymentProvider extension interface — it appears at checkout alongside the built-in options and settles through your own integration. Reference: PaymentsService · Storefront checkout · Custom Extensions

Subscription billing

Charging merchants for their own plan and usage. This is the platform’s own billing rail, configured by whoever operates the deployment, and it is separate from the payments a merchant takes from shoppers.

Stripe and Paystack

Subscriptions and metered overage, billed on the same processor accounts described above.

Lemon Squeezy and Paddle

Merchant of record. Both differ from the first two in kind rather than degree: they take on sales-tax liability and invoicing on the seller’s behalf, which suits selling into many jurisdictions without registering in each. An operator enables one or several; where more than one is live, the payer chooses. Bring your own: the SubscriptionBillingProvider interface, used by agencies billing their own merchants through rails the platform does not carry natively. Reference: Agencies

Advertising

Creating and managing paid campaigns from inside the platform, with performance measured against real margin rather than ad-platform revenue figures alone. Both providers run through the same rule engine, goals and experiments, so a campaign behaves the same way whichever platform serves it. Search, Shopping and Performance Max campaigns, with conversions uploaded back so bidding optimises against orders that actually completed.

Meta Ads

Facebook and Instagram campaigns, with conversions reported server-side rather than from the browser, so they survive tracking restrictions that drop client-side events. Bring your own: the AdsProvider interface. Conversion reporting is a separate seam, so a provider can supply campaign management, conversion reporting, or both. Reference: Advertising

Catalog channels

Publishing a merchant’s catalog to places shoppers already are, and pulling an existing catalog in.

Shopify

Bidirectional. An existing Shopify catalog imports into Galactic Core, and inventory stays in step afterwards in both directions — a sale in either system adjusts the other, with echo suppression so an update does not bounce back and forth between them.

Google

Products published to Google Shopping, kept current as the catalog changes.

Meta

Products published to Facebook and Instagram catalogs, which is what campaigns run through Meta Ads draw their product data from. A catalog can also be pushed in directly or pulled from a feed on a schedule without a named channel, and a store can publish its own feed for any system to read — see Ingestion. Bring your own: the SalesChannelProvider interface. Reference: Catalog sync

Shipping

Shippo

Live rates, label purchase and tracking across many carriers through one connection, so adding a carrier does not mean adding an integration. Carrier rates sit alongside the platform’s own delivery zones, which price by distance or by drawn area. Where both apply, the merchant’s own zone takes precedence — their pricing for their own neighbourhood is deliberate, and a carrier quote should not override it. Bring your own: the ShippingProvider interface, for a carrier account or rate engine the platform does not carry. Reference: ShippingService

Accounting

QuickBooks

Journal entries for sales, refunds and expenses, posted against a mapped chart of accounts so a merchant’s books stay current without re-keying. The platform keeps double-entry books of its own regardless of whether an external system is connected, so accounting is never dependent on an integration being present. Bring your own: the AccountingProvider interface. Reference: Accounting

Marketing and messaging

These carry the merchant’s own credentials rather than the platform’s, so messages send from their domain and sending reputation, and their subscriber data stays in an account they control.

Klaviyo

Customer profiles, order events and abandoned-cart flows, synchronised as they happen rather than on a nightly export.

Twilio

Transactional SMS — order confirmations, shipping updates, delivery notifications.

Resend

Transactional email from the merchant’s own verified domain. Bring your own: MarketingProvider, EmailProvider and SmsProvider are separate interfaces, so one can be replaced without disturbing the others.

Tax

Avalara

Jurisdiction-accurate calculation, address validation, and adjustment on refund. Tax resolves at checkout for the online path and at the register for in-store sales, using the same calculation either way. If the service cannot be reached, checkout falls back to the store’s own configured rates rather than failing — a sale completes at an approximate rate rather than not completing at all. Bring your own: the TaxProvider interface. Reference: Tax

Identity

Shoppers can authenticate against the platform directly, or a storefront can bring its own identity provider and assert a shopper’s identity with a signed token, so no shopper record has to be duplicated between systems. Bring your own: the AuthProvider interface. Reference: Authentication

Connecting something that is not listed

Every capability above is an interface, not a fixed list. An integration the platform does not carry natively is added as an extension: it registers against the same interface the built-in providers use, receives the same events, and appears in the same places in the merchant’s settings. That applies to all eleven interfaces — payments, subscription billing, advertising, catalog channels, shipping, accounting, marketing, email, SMS, tax and identity. An extension runs as a hosted function or points at an endpoint you already operate.

Custom Extensions

How to build against a provider interface, what each one receives, and how an extension is tested before it goes live.