square.payment.approved: the approved contract

Prove that Square holds an authorisation of the card for this amount. The card issuer authorised the amount, and Square holds the authorisation. This level does not prove a capture. The money did not move.

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

Get an authorisation of 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_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
`payment_present`	The provider holds the payment with the returned identifier.	`$observed.payment_readback.payment.id`	`eq`	`$action.result.payment.id`	`payment_readback`
`payment_authorised`	The payment holds an authorisation. A captured payment was authorised first, so both values satisfy this level.	`$observed.payment_readback.payment.status`	`in`	`["APPROVED","COMPLETED"]`	`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_created_event`	At least one payment.created event names the reference of this payment. The duplicate guard reads the same channel, so a workspace with no event endpoint cannot verify and cannot miss a second charge either.	`$observed.payment_created_events.count`	`gte`	`1`	`payment_created_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.
`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	900000 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~1payments/post: square.openapi, retrieved 2026-09-08
square.openapi#/paths/~1v2~1payments/post/responses/200: square.openapi, retrieved 2026-09-08
square.docs.payments#payments/autocomplete-and-the-approved-state/p3: square.docs.payments, retrieved 2026-09-08
square.docs.payments#payments/the-status-of-a-payment/p2: square.docs.payments, retrieved 2026-09-08
square.openapi#/components/schemas/Payment/properties/id: square.openapi, retrieved 2026-09-08
square.openapi#/paths/~1v2~1payments~1{payment_id}/get/responses/200: square.openapi, retrieved 2026-09-08
square.openapi#/components/schemas/Payment/properties/status: square.openapi, retrieved 2026-09-08
square.docs.payments#payments/the-status-of-a-payment/p3: 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.created: square.events, retrieved 2026-09-08
square.docs.webhooks#webhooks/the-event-types/p2: square.docs.webhooks, retrieved 2026-09-08
square.docs.webhooks#webhooks/the-event-types/p7: square.docs.webhooks, retrieved 2026-09-08

Can square.payment.approved 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_created_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.