shopify.refund.created: the created contract

Prove that Shopify holds a Refund record for the order. The created level proves that the Refund record exists with the requested amount and a refunds/create webhook. It does not prove that money moved.

Contract identity.
Fact	Value
Contract id	`shopify.refund.created`
Version	`1.0.0`
Hash	`3b0c1707cf0adcf1`
Completion level	`created`
Certification	Community
Skill	Shopify Admin API 0.1.0
Valid for provider API versions	`2025-07`

What is the intent?

Create the refund record on the order.

What is the subject and the action?

Member	Value
Subject type	`shopify.refund`
Subject identity	refund_id = `$action.result.refundCreate.refund.id`
Canonical effect	`money.refund`
Provider operation	`mutation refundCreate`
Idempotency	not stated

How does the evidence correlate with this operation?

Strategy	Assurance	Keys	Required
`resource_id`	strong	refund_id from `$action.result.refundCreate.refund.id`	yes
`fingerprint`	weak	order from `$input.order_id`; amount from `$input.amount`	no

Which evidence does the contract require?

Minimum evidence level E2. An independent channel is required. Minimum channels: 1.

Channel	Level	Independence	Verifier	Description
`refund_readback`	E2	provider readback	`http`	Read the Refund record with its order and its transactions. It proves the record, not the money movement. The http verifier returns the parsed GraphQL response body, so a condition path starts with $observed.<channel>.data. The connection of the shop gives the base URL.
`refund_events`	E3	provider event	`webhook`	The refunds/create webhooks of this refund. The type name is the WebhookSubscriptionTopic value. The resource id is the global id of the refund. The webhook verifier returns {events, count, latest, earliest, types, duplicates_dropped}, so a condition reads the count.
`order_refund_events`	E3	provider event	`webhook`	The refunds/create webhooks for the order since the operation started. A count above one shows a second refund. The webhook verifier returns {events, count, latest, earliest, types, duplicates_dropped}.

Which conditions must all hold for VERIFIED?

Condition	Meaning	Path	Operator	Expected	Evidence
`refund_created_in_window`	The shop created the Refund record after the operation started.	`$observed.refund_readback.data.refund.createdAt`	`time_after`	`$operation.created_at`	`refund_readback`
`refund_present`	The shop holds the refund with the returned global id.	`$observed.refund_readback.data.refund.id`	`eq`	`$action.result.refundCreate.refund.id`	`refund_readback`
`refund_webhook_present`	At least one refunds/create webhook of this refund arrived.	`$observed.refund_events.count`	`gte`	`1`	`refund_events`

Which conditions give CONTRADICTED?

Condition	Class	Reason	Path	Operator	Expected
`refund_on_wrong_order`	wrong subject	The refund belongs to another order.	`$observed.refund_readback.data.refund.order.id`	`ne`	`$input.order_id`
`refund_amount_mismatch`	wrong amount	The provider recorded a different refund amount.	`$observed.refund_readback.data.refund.totalRefundedSet.shopMoney.amount`	`ne`	`$input.amount`
`refund_predates_operation`	pre existing state	The refund is older than the operation. It proves nothing.	`$observed.refund_readback.data.refund.createdAt`	`time_before`	`$operation.created_at`
`duplicate_refund_present`	duplicate side effect	Shopify created more than one refund on the order since the operation started. Do not retry.	`$observed.order_refund_events.count`	`gt`	`1`

Which observed states map to a verdict before completion?

Rule	Match	Verdict	Reason
`transaction_failed`	`$observed.refund_readback.data.refund.transactions[0].status` in `["FAILURE","ERROR"]`	FAILED	The refund record exists, but its transaction failed at the gateway. The refund will not complete.

How long does the runtime observe?

Timing member	Value
Initial delay	1000 ms
Poll interval	5000 ms
Backoff	exponential factor 2, max 60000 ms
Maximum attempts	40
Timeout	604800000 ms
Stale read window	20000 ms
On timeout	UNVERIFIABLE (`evidence_unavailable_before_timeout`), escalated to a person

Where do these rules come from?

shopify.graphql#/mutations/refundCreate: shopify.graphql, retrieved 2026-09-05
shopify.docs.refunds#refunds-in-the-admin-graphql-api/p1: shopify.docs.refunds, retrieved 2026-09-05
shopify.docs.refunds#refunds-in-the-admin-graphql-api/refund-objects-and-money-movement/p1: shopify.docs.refunds, retrieved 2026-09-05
shopify.docs.refunds#refunds-in-the-admin-graphql-api/webhooks/p1: shopify.docs.refunds, retrieved 2026-09-05
shopify.graphql#/types/Refund/fields/createdAt: shopify.graphql, retrieved 2026-09-05
shopify.graphql#/types/Refund/fields/id: shopify.graphql, retrieved 2026-09-05
shopify.graphql#/queries/refund: shopify.graphql, retrieved 2026-09-05
shopify.graphql#/enums/WebhookSubscriptionTopic/values/REFUNDS_CREATE: shopify.graphql, retrieved 2026-09-05

Can shopify.refund.created return VERIFIED from the action response alone?

No. The minimum evidence level is E2. The action response is E1. The completion conditions read refund_readback and refund_events.

What happens after the timeout?

The verdict is UNVERIFIABLE with the reason evidence_unavailable_before_timeout. The operation goes to a person for review.