Profiles merge customer, email, phone, fingerprint, and order history into a reusable risk memory.
A fraud service that can outgrow the Shopify shell
Fraud operations built asa signed service
Fraud Shield separates scoring, overrides, governance lists, and replay tooling from the embedded Shopify UI. Merchants stay inside Shopify, while the engine becomes reusable for new channels, docs, and a future product site.
Shopify ingressSigned internal APIMulti-shop identity graphOps-ready controls
Overrides, governance lists, threshold updates, and admin reads move through one signed service instead of app-local shortcuts.
You can keep one host and one repo now, then expose selected surfaces to other channels when the product deserves it.
Why split it out
The Shopify app becomes the shell. Fraud Shield becomes the product core.
This is the point of the separation: keep Shopify install, auth, and embedded UX where they belong, while moving fraud logic into a service that can grow on its own timeline.
Service boundary first
The engine has a stable internal contract, so new consumers do not need direct access to app internals or route handlers.
Shopify stays excellent at Shopify work
Embedded pages, webhooks, auth, and checkout-adjacent flows still live in the app where Shopify expects them.
A public site is no longer fake architecture
Once the service exists, a marketing site, docs portal, or gated dashboard can talk to the same product boundary instead of duplicating logic.
Governance survives channel growth
Lists, overrides, rescore tools, and audit-friendly reads stay consistent whether the caller is Shopify, admin ops, or a future external surface.
What it does
Fraud Shield is more than a score endpoint.
The service is designed as an operating layer for COD risk, not a single classifier. That is why the internal API includes both machine decisions and human intervention paths.
Identity resolution
Build pseudonymous profiles from hashes, customer references, and recurring order signals across shops.
Order policy snapshots
Serve the order-policy contract used by Shield UI and extension surfaces without binding callers to app-local code.
Merchant override flow
Capture request and revoke paths through one decision service so business rules and messages stay aligned.
Admin read and write models
Lists, thresholds, pending overrides, profile detail, dashboard summaries, and CSV sourcing can all come from the same service layer.
Replay and rescore tooling
Operational scripts live with the service boundary, making rescoring, event replay, and retention cleanup part of the product runtime.
Future channel integrations
Because the API is signed and typed, the next consumer can be a partner tool, a docs playground, or a public-facing workflow.
Service workflow
A tight path from event to action.
The service design keeps each stage explicit: normalize signals, score or snapshot, expose decisions, and preserve operator control.
Ingest
Webhooks and app actions normalize order events before they cross the signed service boundary.
Score
Identity, profile, Shopify risk, and model logic combine into one decision-ready state.
Act
Merchants and internal admins can request overrides, update thresholds, and govern lists without bypassing the core engine.
Observe
Dashboard reads, profile views, CSV exports, replays, and retention all operate on the same source of truth.
Architecture
One domain, four clean surfaces.
The service does not replace the Shopify app. It gives the app, the operators, and future web surfaces a cleaner boundary to stand on.
Shopify app
Auth, install, webhooks, and embedded merchant UI remain where the platform expects them.
Fraud Shield service
Signed internal endpoints expose ingest, policy, override, list, admin, replay, and retention capabilities.
Internal operations
Review teams use dashboard and profile read models without directly owning database orchestration in the route layer.
Future public web
A marketing site, docs hub, or external control surface can be added later without collapsing the current app boundary.
How the service changes day-two operations
EventsEvery event enters as a normalized contract, making replay, testing, and future non-Shopify ingestion predictable.
DecisionsPolicy snapshots, overrides, and admin actions share one auditable path instead of several route-specific implementations.
ControlOperational scripts now belong to the service, so rescore, retention, and replay evolve with the domain, not around it.
Try it
Use the same repo as a product site now, and as a public property later.
In development, you can still jump straight into the Shopify app from here. In production, this section can become request access, docs, or demo booking without rebuilding the engine.
The public page is live, while merchant access remains controlled through the Shopify app install flow.
That means you can validate the product story publicly without exposing internal control surfaces or loosening authentication.