Inkress ADRsarchitecture decisions
Overview / Integrations / Shopify
ADR 0043

Inkress-on-Shopify is two compliance-separated apps sharing one account link

AcceptedIntegrations / Shopify

Context

Inkress wants two things inside a merchant's Shopify: to be a payment option in Shopify checkout, and to sync the merchant's Shopify catalog/orders into Inkress. Shopify's app model constrains how: a Payments app is a distinct, regulated app type that cannot legally bundle unrelated functionality (like data sync) in the same app.

Decision

Ship Inkress-on-Shopify as two separate apps that share one Inkress account link, split along Shopify's compliance boundary:

  • App A — commerce-shopify-pay (a Shopify Payments app). An offsite payments provider: Shopify checkout redirects to the Inkress hosted checkout, uses the Payments Apps GraphQL API, applies the 3-D Secure strength gate (ADR 0010), and settles through commerce-payments (ADR 0011).
  • App B — commerce-shopify ("inkress-commerce", a sync app). A one-way Shopify → Inkress ETL: HMAC-verified Shopify webhooks drive writes into Inkress through the official SDK (ADR 0041).

The two apps share a single account link, so a merchant connects Inkress once.

Consequences

  • Positive: each app fits Shopify's app-type rules; payments and sync concerns are cleanly separated; App B reuses the official SDK for its writes rather than a bespoke client.
  • Current state / to revisit: App B (sync) is shipped and maintained; App A (payments) is a code-complete PoC blocked on Shopify Payments Partner approval and an unregistered payments-app extension (its capture/refund/void are still stubs that would call commerce-payments) — so the payments half is not live yet. Sync is one-way (Shopify → Inkress) by design; there is no Inkress → Shopify write-back. The shared single account-link is design intent (App A is not live).
  • Neutral: two apps to build, review and maintain, which is the cost of Shopify's compliance separation.

Alternatives considered

  • One combined Shopify app (payments + sync): rejected — a Shopify Payments-app type cannot bundle non-payments functionality; the compliance rule forces the split.
  • Two-way catalog/order sync: not adopted — App B is a one-way Shopify → Inkress ETL; two-way sync would add conflict-resolution complexity not needed for the current use.
  • Only a payments app (no sync) or only a sync app (no payments): rejected — both capabilities are wanted; separating them into two apps is the way to have both under Shopify's rules.
← 0042 Embedded merchant apps use a two-layer framework: app-bridge (transport) and app-kit (full-stack) 0044 Bookings are a thin vertical over the commerce catalog, not a standalone scheduler →