Developer guide · Shopify
Connect Shopify to a source-owned loyalty application.
Use the current native path when its order, identity, refund, and storefront model fits the store. The operator still owns configuration, monitoring, and release work.
- Source sale
- Shopify order
- Loyalty write
- Signed store webhook
- Storefront path
- Optional loyalty widget
Short answer
Match the native path to the store lifecycle.
Reward Loyalty has an early-access Shopify integration for a store connected through OAuth. Signed Shopify webhooks report paid orders and refunds to Reward Loyalty, where the processor resolves a customer email, records supported loyalty value, and stores receipt evidence. An optional storefront widget uses a public widget key to show loyalty state and request supported reward redemption. This is a source-owned application integration, not a Shopify marketplace app or a generic hosted API.
Decision criteria
Decide where Shopify stops and loyalty begins.
Payment state, customer identity, refund rules, storefront presentation, and operating ownership determine whether the current path fits.
Order trigger
Use the paid-order event as the current earning trigger. Shopify remains the authority for cart, payment, tax, order state, fulfilment, and refund records.
Identity rule
Confirm that the store supplies a usable customer email. The processor can match or create a loyalty member; an order without an email cannot receive points.
Reward experience
Decide whether the optional widget belongs in the theme, which rewards may create store discounts, and who supports a mismatch between the discount and loyalty ledger.
Connection model
Use the current OAuth and webhook path.
Reward Loyalty supplies the application-side connection, processor, settings, widget service, receipts, and activity records. The operator owns the store setup and deployment.
Systems involved
Shopify owns commerce. Reward Loyalty owns the loyalty member, card, points ledger, reward record, staff and partner interfaces, and integration evidence.
Authentication
The operator enables the feature and starts the documented OAuth connection. Shopify callbacks and incoming webhooks use their own signed contracts; the storefront widget uses its public widget key, which is not an administrator secret.
Developer work
Configure the application URL and Shopify app credentials, complete the store connection, place and test the optional theme snippet, protect server secrets, and maintain any source change.
Branding scope
White-label relevance: Supporting. Installation and business branding can align the loyalty presentation with the store. Theme work, custom behavior, source maintenance, and commercial-license limits remain with the buyer.
Order and identity
Let Shopify own the transaction record.
The integration copies only the facts needed to apply the configured loyalty rule.
Write direction
A valid paid-order webhook can create the supported loyalty transaction. A webhook receipt and the store order reference help suppress a repeated provider event before the same order awards again.
Member identity
The processor reads the customer email, falls back to the order email where supplied, and matches or creates the loyalty member. Missing email causes a skipped order rather than an anonymous award.
Read direction
Partners inspect integration status, receipts, activity, members, cards, and transactions in Reward Loyalty. The widget reads its limited configuration, member balance, and eligible reward data through the widget boundary.
Event notifications
Shopify webhooks drive this native commerce path. Reward Loyalty outbound webhooks are a separate interface for notifying CRM, automation, or reporting systems after supported loyalty events.
Refund and reward path
Test the connection and its customer consequence.
Earning, clawback, and storefront redemption cross separate records and can fail at different points.
Paid order
The processor calculates points from the linked card rule, writes a store-referenced transaction, links the member to the card when needed, and records activity.
Full refund
When refund deduction is enabled and the original order transaction exists, a full refund can create the supported points deduction and matching evidence.
Partial refund
The current processor identifies a partial refund and does not deduct points for it. The operator needs a documented review or correction policy for that limit.
Widget redemption
The optional widget can expose eligible rewards and request a store discount for an identified member. Server-side checks still enforce integration status, reward ownership, and available points; the public widget key does not grant broad API access.
Production controls
Monitor the handoff on both sides.
A successful OAuth callback does not prove that later orders, refunds, theme code, or queue work will stay healthy.
-
1
Prove the setup
Use a safe store and member to test OAuth, signature rejection, a paid order, a repeated delivery, missing email, a full refund, a partial refund, widget loading, and an eligible redemption.
-
2
Choose execution mode
Incoming processing can run in the request or on the configured queue. If queued processing is enabled, monitor workers, queued receipts, failed jobs, and integration error state.
-
3
Reconcile evidence
Compare Shopify order and refund IDs with webhook receipts, loyalty transactions, member records, card totals, and activity logs. Do not retry a manual correction without checking the ledger.
-
4
Plan change ownership
Re-test after Shopify configuration, theme, checkout, reward, queue, domain, or source changes. The buyer owns custom code and its update work.
Product and operating limits
Keep the early-access boundary visible.
- The Shopify integration is early access. Confirm its current feature setting, configuration, store fit, and maintained documentation before committing an architecture.
- Reward Loyalty is not presented as a Shopify marketplace app, drop-in SDK, managed connector service, or universal storefront extension.
- Partial refunds do not trigger the full-refund deduction path. Theme compatibility, historical-order migration, and custom checkout behavior are not implied.
Implementation guides
Use current documentation for changing details.
Requirements, interfaces, settings, limits, and release behavior belong in the maintained product documentation.