square.refund.completed: the refunded contract

Prove that the money returned to the payment card of the buyer. A PaymentRefund object does not prove that money moved. This level proves the COMPLETED state on the refund and an event that carries it.

Contract identity.
Fact	Value
Contract id	`square.refund.completed`
Version	`1.0.0`
Hash	`996beade3905b671`
Completion level	`refunded`
Publisher	Built and signed by Provely.
Certification	Provisional
Skill	Square 0.1.0
Valid for provider API versions	`2026-08-19`

What is the intent?

Return the amount of the payment to the buyer.

What is the subject and the action?

Member	Value
Subject type	`square.payment_refund`
Subject identity	refund_id = `$action.result.refund.id`
Canonical effect	`payments.card_refund`
Provider operation	`POST /v2/refunds`
Idempotency	idempotency_key, retry is safe

How does the evidence correlate with this operation?

Strategy	Assurance	Keys	Required
`resource_id`	strong	refund_id from `$action.result.refund.id`	yes
`idempotency_key`	strong	idempotency_key from `$operation.id`	no
`fingerprint`	weak	payment_id from `$input.payment_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 from the provider. A condition path is $observed.refund_readback.refund.status.
`refund_completed_events`	E3	provider event	`webhook`	The refund events of this refund that carry the status COMPLETED. The webhook verifier returns {events, count, latest, earliest, types, duplicates_dropped}.
`refund_created_events`	E3	provider event	`webhook`	The refund.created events for the payment since the operation started. The webhook verifier returns {events, count, latest, earliest, types, duplicates_dropped}. A count above one shows a second refund of the payment.

Which conditions must all hold for VERIFIED?

Condition	Meaning	Path	Operator	Expected	Evidence
`refund_status_completed`	The refund states the completed state. The money reached the payment card of the buyer.	`$observed.refund_readback.refund.status`	`eq`	`COMPLETED`	`refund_readback`
`refund_amount_matches`	The amount of the refund equals the requested amount.	`$observed.refund_readback.refund.amount_money.amount`	`eq`	`$input.amount`	`refund_readback`
`refund_payment_matches`	The refund names the payment that the intent named.	`$observed.refund_readback.refund.payment_id`	`eq`	`$input.payment_id`	`refund_readback`
`refund_created_in_window`	The provider created the refund after the operation started.	`$observed.refund_readback.refund.created_at`	`time_after`	`$operation.created_at`	`refund_readback`
`refund_completed_event`	At least one refund event of this refund carries the status COMPLETED.	`$observed.refund_completed_events.count`	`gte`	`1`	`refund_completed_events`

Which conditions give CONTRADICTED?

Condition	Class	Reason	Path	Operator	Expected
`refund_on_wrong_payment`	wrong subject	The refund belongs to a different payment than the intent named.	`$observed.refund_readback.refund.payment_id`	`ne`	`$input.payment_id`
`refund_amount_mismatch`	wrong amount	The provider refunded a different amount than the intent stated.	`$observed.refund_readback.refund.amount_money.amount`	`ne`	`$input.amount`
`refund_predates_operation`	pre existing state	The refund is older than the operation. It proves nothing.	`$observed.refund_readback.refund.created_at`	`time_before`	`$operation.created_at`
`duplicate_refund_present`	duplicate side effect	Square created more than one refund for the payment since the operation started. Do not retry.	`$observed.refund_created_events.count`	`gt`	`1`

Which observed states map to a verdict before completion?

Rule	Match	Verdict	Reason
`terminal_failure`	`$observed.refund_readback.refund.status` eq `"FAILED"`	FAILED	An error stopped the refund. Square reports the failed state.
`rejected`	`$observed.refund_readback.refund.status` eq `"REJECTED"`	CONTRADICTED	Square rejected the refund. No money moved back to the buyer.
`still_transitional`	`$observed.refund_readback.refund.status` eq `"PENDING"`	PENDING	The refund awaits approval. The runtime observes again later.

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?

square.openapi#/paths/~1v2~1refunds/post: square.openapi, retrieved 2026-09-08
square.openapi#/components/schemas/PaymentRefund/properties/status: square.openapi, retrieved 2026-09-08
square.docs.refunds#refunds/p1: square.docs.refunds, retrieved 2026-09-08
square.docs.refunds#refunds/the-status-of-a-refund/p2: square.docs.refunds, retrieved 2026-09-08
square.docs.refunds#refunds/the-status-of-a-refund/p5: square.docs.refunds, retrieved 2026-09-08
square.openapi#/components/schemas/PaymentRefund/properties/amount_money: square.openapi, retrieved 2026-09-08
square.openapi#/components/schemas/Money/properties/amount: square.openapi, retrieved 2026-09-08
square.openapi#/components/schemas/PaymentRefund/properties/payment_id: square.openapi, retrieved 2026-09-08
square.docs.refunds#refunds/identifiers-and-times/p1: square.docs.refunds, retrieved 2026-09-08
square.openapi#/components/schemas/PaymentRefund/properties/created_at: square.openapi, retrieved 2026-09-08
square.events#/events/refund.updated: square.events, retrieved 2026-09-08
square.docs.webhooks#webhooks/the-event-types/p5: square.docs.webhooks, retrieved 2026-09-08

Can square.refund.completed 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_completed_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.