Skip to main content

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):
  1. Create the order as pending in Galactic Core to get a permanent order_id.
  2. Charge through your provider from your own function, tagging the transaction with that order_id.
  3. On your provider’s webhook, verify it and PATCH the order to paid.
Galactic Core then runs the commerce side-effects automatically — inventory, double-entry accounting, and order-confirmation emails. It only needs a verified paid / failed status; it never sees your provider’s keys.
The same shape works for custom shipping: run a function that fetches a live rate from any carrier, and include the resulting fee when you create the order. (To have Galactic Core call your rate logic during checkout so custom rates appear in its own rate list, use a 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-Key on the update so a retried webhook can’t double-post accounting.
Anvil can scaffold this for you — describe a custom payment integration and it generates the initialize / webhook / verify function skeleton, with templates for common providers.

Should you use this or an Extension?