On this page
An order-status page is a convenient place to answer “What happened to my reward?” It is also a place where a careless integration can disclose one person’s information to someone holding the wrong link. The page’s ability to display an order does not give an external reward service permission to reveal every record associated with it.
Imagine a hypothetical furniture purchase made as a gift. The buyer owns the order, while the approved campaign names a different reward recipient. The extension might be allowed to show the buyer that the purchase is being reviewed without exposing the recipient’s private claim destination. That distinction must be part of the access design.
Resolve the order in the extension context
Shopify provides an Order status extension context for revisitable order pages. Use the documented order reference for the selected target, rather than extracting a number from visible text or trusting an arbitrary browser parameter. Shopify Order status customization
The component needs one clearly defined scope: the current order in the current store. It should not accept a replacement order identifier merely because a frontend query requests one. The backend compares the requested reference with the verified extension context and the applicable authorization policy.
Separate three identities in the design. The store identifies the tenant. The purchase identifies the commercial record. The authorized viewer identifies who is asking. A reward recipient may be a fourth identity. These references can be linked, but treating them as interchangeable creates access errors that are difficult to detect in an ordinary happy-path test.
For the furniture example, the proposed adapter returns only an opaque award reference, an approved display stage, a freshness time and an allowed next action. It does not return the complete recipient profile just so the frontend can decide which fields to hide. Data that must not be disclosed should be excluded before the response leaves the server.
Avoid assuming a particular account session always exists. Review the supported authentication and viewer contexts for the chosen extension version. If a context cannot provide the assurance needed for a personal reward lookup, the fallback should explain how to reach the approved authenticated experience. It must not weaken the check simply to avoid an empty component.
Authorize the reward lookup for the current viewer
The server should derive store and viewer scope from validated authentication evidence, then evaluate the requested record within that scope. Shopify’s customer-account extension documentation includes app authentication and security guidance; the exact mechanism should follow the selected version and surface. Customer account extension documentation
An original access matrix for the hypothetical gift order can make the policy concrete:
| Verified context | Proposed response | Information withheld |
|---|---|---|
| Authorized buyer viewing this purchase | Purchase-linked reward stage | Another recipient’s claim secret |
| Authorized recipient in a supported claim experience | Recipient-permitted reward details | Other purchases or customers |
| Viewer from another store | No matching personal record disclosed | All reward data |
| Order reference changed in the request | Denied or safe unavailable result | Whether the other order has a reward |
| Authentication missing or expired | Approved access guidance | Personal stage and destination |
| Staff user in a customer surface | No automatic staff override | Administrative actions |
This matrix is illustrative policy design. The actual program determines who is entitled to each piece of information. Its usefulness lies in separating a visible order relationship from a permission to access a reward.
Apply the policy on every lookup, including refresh requests. A frontend that checks authorization only when the component mounts can accidentally continue using a cached response after its context changes. Likewise, a cache keyed solely by order number can return a record from another shop whose human-readable numbering happens to match.
A safer cache key includes the trusted tenant, resource reference, disclosure class and any relevant authorization version. Even then, the service should ensure that a cached object is appropriate for the current viewer. Caching a restricted projection is preferable to caching a full record and relying on frontend filtering later.
Do not use a claim link as a convenient reward identifier. A link may contain a live bearer secret that grants access to a separate experience. If the component needs navigation, the backend should return only an approved destination under the supported access contract, and only for an authorized viewer. Ordinary logs should record a route category or opaque reference rather than the secret-bearing URL.
A difficult case is a shared household email. The same address can appear on several purchases without proving that every viewer should see every award. The policy needs a stable authorized relationship, not a loose match on a field that may be shared, corrected or absent. Where that relationship cannot be established, route the case through the approved verification journey.
Render fresh status with a safe access fallback
The component should say what the returned stage means and when it was last established. A status such as “approved” can remain true while a later delivery step is incomplete. Avoid combining approval, card availability and spendable balance into one green success label unless the authoritative contract explicitly provides that combined meaning.
For the example, the buyer may see: “Reward reference AW-204 is approved. Recipient instructions are handled through the approved reward journey.” The exact wording depends on the program, but it avoids presenting the buyer with another person’s access material.
Define the following display cases before implementation:
- A fresh authorized response shows its stage and permitted next action.
- A temporarily unavailable lookup shows an approved later-check message.
- A missing association remains distinct from a final no-award decision.
- A denied lookup shows safe guidance without revealing whether another person’s record exists.
- An expired context asks the user to return through the supported access route.
- A stale response cannot overwrite a newer accepted response.
Test those cases with synthetic references. Include a customer with two orders, two stores with similar order names, a gift recipient who differs from the buyer, and a request whose order reference has been altered. The expected result should state both what appears and what must be absent.
Also inspect network responses, not just screenshots. A page that hides a recipient name visually but returns it in JSON has still disclosed it to the browser. The same applies to an unused claim destination or an internal operational note. The acceptance test should examine the actual returned projection.
When status changes during a session, refresh according to a bounded policy that respects the selected extension runtime and backend contract. Avoid presenting continuous polling as a promise of instant updates. If freshness cannot be established, say that the latest status is unavailable rather than leaving an old stage looking current.
The completed access matrix becomes the main review artifact: trusted context, permitted record, allowed fields and fallback. A reward-status component is ready when it answers the current viewer’s question accurately without treating their presence on an order page as unlimited authority over the reward journey.
Keep the distinction visible in the staff review record. For the fictional gift order, write that the buyer may see the award stage, the separate recipient may use the approved claim journey, and neither relationship gives access to other orders. Ask the reviewer to test that exact split rather than only signing off on a generic login requirement. This catches a policy defect before it becomes a query defect: a perfectly authenticated request can still ask for information that the authenticated person is not entitled to receive.
Review the authorized order-status integration available for your Rebate Card X program.
Source references
This guide is general information, not financial, legal, tax or regulatory advice. Eligibility, card availability, permitted use and responsibilities depend on the applicable offer and card terms.