square.payment.completed: the completed contract

Prove that Square captured the card payment and the money moved. An approved payment is an authorisation hold, not a captured payment. This level reads the payment status and the card timeline together.

Contract identity.
Fact	Value
Contract id	`square.payment.completed`
Version	`1.0.0`
Hash	`8614830aaeb73986`
Completion level	`completed`
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?

Charge the card for the amount.

What is the subject and the action?

Member	Value
Subject type	`square.payment`
Subject identity	payment_id = `$action.result.payment.id`
Canonical effect	`payments.card_charge`
Provider operation	`POST /v2/payments`
Idempotency	idempotency_key, retry is safe

How does the evidence correlate with this operation?

Strategy	Assurance	Keys	Required
`resource_id`	strong	payment_id from `$action.result.payment.id`	yes
`idempotency_key`	strong	idempotency_key from `$operation.id`	no
`fingerprint`	weak	reference_id from `$input.reference_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
`payment_readback`	E2	provider readback	`http`	Read the payment from the provider. The http verifier returns the parsed object, so a condition path is $observed.payment_readback.payment.status. The card state sits at $observed.payment_readback.payment.card_details.status.
`payment_completed_events`	E3	provider event	`webhook`	The payment events of this payment that carry the status COMPLETED. The webhook verifier returns {events, count, latest, earliest, types, duplicates_dropped}. A condition reads $observed.payment_completed_events.count.
`payment_created_events`	E3	provider event	`webhook`	The payment.created events for the reference since the operation started. The webhook verifier returns {events, count, latest, earliest, types, duplicates_dropped}. A count above one shows a second charge of the card.

Which conditions must all hold for VERIFIED?

Condition	Meaning	Path	Operator	Expected	Evidence
`card_money_captured`	Square wrote the capture into two systems. The payment object and the card timeline must both state it, and the payment must be a card payment.	—	`all_of`	The rows below state the members.	`payment_readback`
`payment_status_completed`	The Payment object of Square states the captured state.	`$observed.payment_readback.payment.status`	`eq`	`COMPLETED`	`payment_readback`
`payment_source_is_card`	The source of funds is a card. Square populates card_details only there.	`$observed.payment_readback.payment.source_type`	`eq`	`CARD`	`payment_readback`
`card_captured_in_window`	The card rail captured the money after the operation started. The timeline dates the capture.	`$observed.payment_readback.payment.card_details.card_payment_timeline.captured_at`	`time_after`	`$operation.created_at`	`payment_readback`
`payment_amount_matches`	The amount of the payment equals the requested amount. The member holds the amount without the tip.	`$observed.payment_readback.payment.amount_money.amount`	`eq`	`$input.amount`	`payment_readback`
`payment_currency_matches`	The currency of the payment equals the requested currency.	`$observed.payment_readback.payment.amount_money.currency`	`eq`	`$input.currency`	`payment_readback`
`payment_created_in_window`	The provider created the payment after the operation started.	`$observed.payment_readback.payment.created_at`	`time_after`	`$operation.created_at`	`payment_readback`
`payment_completed_event`	At least one payment event of this payment carries the status COMPLETED. No event type of Square names a completion, so the filter reads the status of the payload.	`$observed.payment_completed_events.count`	`gte`	`1`	`payment_completed_events`

Which conditions give CONTRADICTED?

Condition	Class	Reason	Path	Operator	Expected
`payment_on_wrong_reference`	wrong subject	The payment carries a different reference than the intent named.	`$observed.payment_readback.payment.reference_id`	`ne`	`$input.reference_id`
`payment_amount_mismatch`	wrong amount	The provider charged a different amount than the intent stated.	`$observed.payment_readback.payment.amount_money.amount`	`ne`	`$input.amount`
`payment_predates_operation`	pre existing state	The payment is older than the operation. It proves nothing.	`$observed.payment_readback.payment.created_at`	`time_before`	`$operation.created_at`
`duplicate_payment_present`	duplicate side effect	Square created more than one payment for the reference since the operation started. Do not retry.	`$observed.payment_created_events.count`	`gt`	`1`

Which observed states map to a verdict before completion?

Rule	Match	Verdict	Reason
`terminal_failure`	`$observed.payment_readback.payment.status` eq `"FAILED"`	FAILED	Square reports a failed payment. The response carries an error code.
`canceled`	`$observed.payment_readback.payment.status` eq `"CANCELED"`	CONTRADICTED	Square voided the payment. No money moved, and no retry can change that.
`source_not_card`	`$observed.payment_readback.payment.source_type` ne `"CARD"`	UNVERIFIABLE	The payment is not a card payment, so Square writes no card timeline. This level cannot decide.
`approved_not_captured`	`$observed.payment_readback.payment.status` eq `"APPROVED"`	PENDING	Square holds an authorisation. Nobody captured the payment, so the money did not move.
`state_not_published`	`$observed.payment_readback.payment.status` eq `"PENDING"`	UNVERIFIABLE	Square states no meaning for this state. The runtime cannot decide. Ask a person.

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#/components/schemas/Payment/properties/status: square.openapi, retrieved 2026-09-08
square.openapi#/components/schemas/CardPaymentDetails/properties/status: square.openapi, retrieved 2026-09-08
square.docs.payments#payments/complete-a-payment/p1: square.docs.payments, retrieved 2026-09-08
square.docs.payments#payments/autocomplete-and-the-approved-state/p4: square.docs.payments, retrieved 2026-09-08
square.openapi#/components/schemas/Payment/properties/amount_money: square.openapi, retrieved 2026-09-08
square.openapi#/components/schemas/Money/properties/amount: square.openapi, retrieved 2026-09-08
square.docs.payments#payments/amounts/p1: square.docs.payments, retrieved 2026-09-08
square.openapi#/components/schemas/Money/properties/currency: square.openapi, retrieved 2026-09-08
square.docs.payments#payments/amounts/p2: square.docs.payments, retrieved 2026-09-08
square.openapi#/components/schemas/Payment/properties/created_at: square.openapi, retrieved 2026-09-08
square.docs.payments#payments/identifiers/p2: square.docs.payments, retrieved 2026-09-08
square.events#/events/payment.updated: square.events, retrieved 2026-09-08
square.docs.webhooks#webhooks/the-event-types/p3: square.docs.webhooks, retrieved 2026-09-08
square.docs.webhooks#webhooks/the-event-types/p6: square.docs.webhooks, retrieved 2026-09-08

Can square.payment.completed return VERIFIED from the action response alone?

No. The minimum evidence level is E2. The action response is E1. The completion conditions read payment_readback and payment_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.