Custom Integrations — Bring Your Own Compute
The full-control path to a Custom Integration: run your own code, on your own infrastructure, and drive Galactic Core from the outside over the public API and webhooks. Nothing to register.Reach for Extensions first. For the common cases — react to a store event, or become the provider Galactic Core calls for payments / shipping / tax / email / SMS / marketing / a sales channel — an Extension does the plumbing for you (registered, signed, retried, revalidated, run-logged), and your secrets can stay entirely on your side. Use this page only when you need free-form orchestration that an Extension doesn’t cover.
The pattern
Galactic Core is the system of record — orders, inventory, accounting, customers. Your service does the provider-specific work and tells Galactic Core the result over the API. The clearest example is a custom payment provider (any provider beyond the built-in Stripe, PayPal, Paystack, and M-Pesa):- Create the order as
pendingin Galactic Core to get a permanentorder_id. - Charge through your provider from your own function, tagging the transaction with that
order_id. - On your provider’s webhook, verify it and
PATCHthe order topaid.
paid / failed status; it never sees your provider’s keys.
ShippingProvider remote extension instead.)
Order fields you set
Guidelines
- Run it anywhere — any serverless platform (Cloudflare Workers, Supabase Edge Functions, Vercel, Deno Deploy) or your own server.
- Keep provider secrets on your side — they never touch Galactic Core or your storefront.
- Verify your provider’s webhook signature before trusting a payment result.
- Use an
Idempotency-Keyon the update so a retried webhook can’t double-post accounting.
initialize / webhook / verify function skeleton, with templates for common providers.

