Technical integrations
Why a Shopify Dispute Can Have No Accessible Order Record

A Shopify Payments dispute can be available to your integration while its associated order is not. Preserve the dispute and diagnose the missing context separately. A null order link does not prove that the dispute is invalid, the customer never purchased or the order was deleted.
Start with the source response, the documented field nullability and the installation's granted access. Then investigate historical access and any GraphQL errors. Do not assume age explains every missing order.
Check what the schema permits
The 2026-07 ShopifyPaymentsDispute reference defines the order association as nullable. Your storage and interface must therefore support a dispute without an accessible order object.
The following illustrative query has not been executed against a live store. It shows how to request limited order context while preserving core monitoring information.
query DisputeWithOptionalOrder($id: ID!) {
dispute(id: $id) {
id
status
amount { amount currencyCode }
evidenceDueBy
order { id name createdAt }
}
}
Use the authorized installation's token and the correct dispute identifier. Inspect GraphQL errors as well as the returned data. A null field in an otherwise successful response and a field unavailable because of an error need different diagnostic labels.
Do not make the database require an order foreign key before it can store a dispute. Use an optional association so the case remains visible while context is investigated.
Test the ordinary order-access boundary
Shopify's Order documentation states that ordinary access covers the most recent 60 days of orders. Older access requires the appropriate additional approval and scope combination described in the access-scope guide.
This creates a plausible explanation for some missing context, but it is not a universal diagnosis. First determine whether you actually know the order's age from an authorized source. A missing order object cannot itself supply its creation date.
Compare configured scopes with the scopes the merchant has granted. Adding a scope to an app configuration does not establish that an existing installation now has it.
If older history is genuinely required for the enabled feature, document the purpose and follow the supported access process. Do not request broad history merely to eliminate an unfamiliar null in one test case.
Use a diagnostic decision table
| Observation | Next check | Safe interpretation |
|---|---|---|
| Dispute returned, order null, no relevant error | Confirm source association and permitted access | Order context unavailable |
| Error on order fields | Review scopes and protected-data conditions | Context read failed or denied |
| Whole dispute lookup unavailable | Verify account, ID and dispute access | Core case read unresolved |
| Known older order outside ordinary access | Check approved historical access | Age may explain the gap |
| Order available in another shop | Verify tenant and source mapping | Do not join across merchants |
The table keeps the investigation specific. Avoid using a single “order missing” flag for every branch, because operators need to know whether they can still rely on the core case observation.
Store a safe diagnostic category, last successful check and source reference. Do not expose raw credentials or detailed internal errors to merchant users.
Work through a hypothetical missing link
A hypothetical integration receives a dispute for an order placed several months earlier. The dispute query succeeds, but the app has only ordinary order access. The merchant can still see the disputed amount, status and available deadline in the monitoring view.
The developer checks the granted scopes and confirms that the historical order is outside the app's accessible range. The interface labels order context unavailable and directs the authorized merchant to Shopify for further investigation.
Now change the hypothetical: a recent order should be accessible, but the GraphQL response contains an access error. The correct next step is to inspect the exact permission or field restriction. Asking for historical access would not address that different failure.
In a third case, the dispute reference was associated with the wrong installation in the application's queue. The remedy is to fix account isolation and the source mapping. It would be unsafe to search other merchants' records for a convenient match.
Keep monitoring useful during investigation
Display the dispute reference, amount, currency, status and deadline that were successfully retrieved. Make the missing order context explicit without implying that the case is complete or harmless.
If a source refresh fails entirely, retain the last known case with its observation time and mark it stale. Do not delete it because enrichment is unavailable.
Never guess an order using only an amount, a similar name or a nearby timestamp. An ambiguous match can attach the wrong customer's history to a dispute and mislead later merchant decisions.
Verify the null path as a normal state
Include a null-order fixture in the interface and persistence tests. Check that the case remains visible, sorting still works and links are rendered only when a valid association exists.
Test a denied nested field separately from a valid null association. The integration should preserve these distinct explanations in its diagnostics.
A correct implementation treats order context as useful enrichment with documented access limits. The underlying dispute remains the operational record, and the merchant can continue reviewing its status and timing while the specific context gap is resolved.
Explore monitoring of dispute status, amount and deadline even when order context needs checking.
Related reading in this collection: