ProvelyNo. Square returns a success response when it accepts the request. The payment then holds one of 5 states. Only COMPLETED is terminal success. Provely proves approved, completed and refunded as separate promises.
| Fact | Value |
|---|---|
| Skill version | 0.1.0 |
| Publisher | Built and signed by Provely. |
| Certification | Provisional (score 49 of 100) |
| Last conformance run | 2026-09-05T12:00:00Z: 52 of 52 cases passed, 0 critical false VERIFIED |
| Provider API versions | 2026-08-19 |
| Default provider API version | 2026-08-19 |
| Compiled | 2026-09-05T12:00:00Z by compiler 0.1.0 |
| Manifest hash | 5b92b4a15b5a20ca |
| Manifest hash check | the document hashes to the value the manifest states |
| Signature | valid, key provely-skill-2026-09, trusted by this build |
What does this page prove?
| Claim | Proven by | Evidence | Status |
|---|---|---|---|
| The card issuer authorised the amount, and Square holds the authorisation. This level does not prove a capture. The money did not move. | square.payment.approved | E2 + E3 | proven |
| An approved payment is an authorisation hold, not a captured payment. This level reads the payment status and the card timeline together. | square.payment.completed | E2 + E3 | proven |
| A PaymentRefund object does not prove that money moved. This level proves the COMPLETED state on the refund and an event that carries it. | square.refund.completed | E2 + E3 | proven |
| An outcome outside Square, such as a bank credit or a person who read a message | not proven | no E5 channel | not proven |
The meaning of the PENDING state of square.payment | not proven | no source states it | not proven |
| The agent report that the action worked | never counts | E0 | not proven |
Which completion levels does the Square skill expose?
Each level is one promise with one contract. An agent picks the level that matches the promise it makes. It cannot upgrade a level. Read the completion level definition.
| Level | Contract | Promise | Evidence | Certification |
|---|---|---|---|---|
approved | square.payment.approved v1.0.0 | The card issuer authorised the amount, and Square holds the authorisation. This level does not prove a capture. The money did not move. | E2 + E3 | Provisional |
completed | square.payment.completed v1.0.0 | An approved payment is an authorisation hold, not a captured payment. This level reads the payment status and the card timeline together. | E2 + E3 | Provisional |
refunded | square.refund.completed v1.0.0 | A PaymentRefund object does not prove that money moved. This level proves the COMPLETED state on the refund and an event that carries it. | E2 + E3 | Provisional |
What is the Square lifecycle?
Which states can a square.payment be in?
| State | Class | Verdict | Meaning | Source |
|---|---|---|---|---|
APPROVED | transitional | PENDING | The card issuer authorised the amount. Square holds the authorisation. The money did not move. | square.openapi |
COMPLETED | terminal success | VERIFIED | Square captured the payment. The money moved. The card_details status member holds CAPTURED. | square.openapi |
CANCELED | terminal neutral | FAILED | Square voided the payment. No money moved. | square.openapi |
FAILED | terminal failure | FAILED | The payment did not succeed. The response carries an error code. | square.openapi |
PENDING | unknown | UNVERIFIABLE | The published description lists this value. No source states what it means for the money of the payment. | square.openapi |
In square.payment under provider API version 2026-08-19, COMPLETED is the only state that means terminal success. Every other state gives PENDING, FAILED, or UNVERIFIABLE.
Source: square.openapi · retrieved 2026-09-08
Which states can a square.payment_refund be in?
| State | Class | Verdict | Meaning | Source |
|---|---|---|---|---|
PENDING | transitional | PENDING | The refund awaits approval. Square still processes it. | square.openapi |
COMPLETED | terminal success | VERIFIED | The refund is successfully completed. The money reached the payment card of the buyer. | square.openapi |
REJECTED | terminal neutral | FAILED | Square rejected the refund. No money moved. | square.openapi |
FAILED | terminal failure | FAILED | An error occurred. The refund did not complete. | square.openapi |
In square.payment_refund under provider API version 2026-08-19, COMPLETED is the only state that means terminal success. Every other state gives PENDING, FAILED, or UNVERIFIABLE.
Source: square.openapi · retrieved 2026-09-08
How does Provely tie the evidence to this exact operation?
A matching state that already existed must not verify. Every contract names the correlation keys that bind the evidence to the operation, and the idempotency key that stops a duplicate side effect.
| Strategy | Assurance | Keys | Required | Window |
|---|---|---|---|---|
resource_id | strong | payment_id from $action.result.payment.id | yes | none |
idempotency_key | strong | idempotency_key from $operation.id | no | none |
fingerprint | weak | reference_id from $input.reference_id; amount from $input.amount | no | 600000 ms |
resource_id | strong | refund_id from $action.result.refund.id | yes | none |
idempotency_key | strong | idempotency_key from $operation.id | no | none |
fingerprint | weak | payment_id from $input.payment_id; amount from $input.amount | no | 600000 ms |
In words
- E0 agent assertion: never sufficient.
- E1 action response: the provider acknowledged the request.
- E2 provider readback: the runtime read the resource back.
- E3 provider event: the provider reported the change.
- E4 independent system: a system outside the action path agrees.
- E5 external outcome: the result is observable in the world.
Which evidence channels does the skill read?
The runtime prefers the channel that is more independent from the action path. Read the evidence level definition. An acknowledgement from Square is E1 and never terminal success.
| Channel | Level | Independence | Verifier | Deterministic | Typical latency |
|---|---|---|---|---|---|
payment_action_response | E1 | same response | action_result | yes | not stated |
payment_completed_events | E3 | provider event | webhook | no | 3000 ms |
payment_created_events | E3 | provider event | webhook | no | 3000 ms |
payment_readback | E2 | provider readback | http | yes | 300 ms |
refund_completed_events | E3 | provider event | webhook | no | 4000 ms |
refund_created_events | E3 | provider event | webhook | no | 4000 ms |
refund_readback | E2 | provider readback | http | yes | 300 ms |
Which ways can a Square action look done and not be?
| Contract | Case | Rule | Verdict |
|---|---|---|---|
| square.payment.approved | wrong subject | The payment carries a different reference than the intent named. | CONTRADICTED |
| square.payment.approved | wrong amount | The provider charged a different amount than the intent stated. | CONTRADICTED |
| square.payment.approved | pre existing state | The payment is older than the operation. It proves nothing. | CONTRADICTED |
| square.payment.approved | duplicate side effect | Square created more than one payment for the reference since the operation started. Do not retry. | CONTRADICTED |
| square.payment.approved | observed state | Square reports a failed payment. The response carries an error code. | FAILED |
| square.payment.approved | observed state | Square voided the payment. No money moved, and no retry can change that. | CONTRADICTED |
| square.payment.approved | observed state | Square states no meaning for this state. The runtime cannot decide. Ask a person. | UNVERIFIABLE |
| square.payment.completed | wrong subject | The payment carries a different reference than the intent named. | CONTRADICTED |
| square.payment.completed | wrong amount | The provider charged a different amount than the intent stated. | CONTRADICTED |
| square.payment.completed | pre existing state | The payment is older than the operation. It proves nothing. | CONTRADICTED |
| square.payment.completed | duplicate side effect | Square created more than one payment for the reference since the operation started. Do not retry. | CONTRADICTED |
| square.payment.completed | observed state | Square reports a failed payment. The response carries an error code. | FAILED |
| square.payment.completed | observed state | Square voided the payment. No money moved, and no retry can change that. | CONTRADICTED |
| square.payment.completed | observed state | The payment is not a card payment, so Square writes no card timeline. This level cannot decide. | UNVERIFIABLE |
| square.payment.completed | observed state | Square holds an authorisation. Nobody captured the payment, so the money did not move. | PENDING |
| square.payment.completed | observed state | Square states no meaning for this state. The runtime cannot decide. Ask a person. | UNVERIFIABLE |
| square.refund.completed | wrong subject | The refund belongs to a different payment than the intent named. | CONTRADICTED |
| square.refund.completed | wrong amount | The provider refunded a different amount than the intent stated. | CONTRADICTED |
| square.refund.completed | pre existing state | The refund is older than the operation. It proves nothing. | CONTRADICTED |
| square.refund.completed | duplicate side effect | Square created more than one refund for the payment since the operation started. Do not retry. | CONTRADICTED |
| square.refund.completed | observed state | An error stopped the refund. Square reports the failed state. | FAILED |
| square.refund.completed | observed state | Square rejected the refund. No money moved back to the buyer. | CONTRADICTED |
| square.refund.completed | observed state | The refund awaits approval. The runtime observes again later. | PENDING |
What did the last conformance run show?
| Dimension | Score | Maximum |
|---|---|---|
| Documentation | 14 | 20 |
| Schema alignment | 0 | 15 |
| Lifecycle certainty | 17.78 | 20 |
| Evidence strength | 16 | 20 |
| Causal correlation | 15 | 15 |
| Sandbox conformance | 10 | 10 |
| Raw score | 72.78 | 100 |
| Score after the caps | 49 | 100 |
The raw score is 72.78. 2 hard caps apply, so the score is 49 and the level is Provisional.
| Reason | Highest score it allows |
|---|---|
| A lifecycle state has unknown semantics. The compiler cannot prove the end state. | 49 |
| 10 uncertainty records are open. The lowest cap is 49. | 49 |
| Contract | Raw score | Score after the caps | Certification |
|---|---|---|---|
square.payment.approved | 71 | 49 | Provisional |
square.payment.completed | 71 | 49 | Provisional |
square.refund.completed | 75 | 49 | Provisional |
The weakest contract is square.payment.approved. It scores 49 and reaches Provisional. The package level is Provisional, because a package level never rises above its weakest contract. Read the level of the contract you use.
The last conformance run on 2026-09-05T12:00:00Z passed 52 of 52 cases with 0 critical false VERIFIED. One critical false VERIFIED rejects a skill.
| Case class | Passed | Total |
|---|---|---|
| duplicate side effect | 3 | 3 |
| error after execution | 3 | 3 |
| error before execution | 3 | 3 |
| evidence unavailable | 3 | 3 |
| idempotent retry | 3 | 3 |
| pre existing state | 3 | 3 |
| stale readback | 3 | 3 |
| still transitional | 3 | 3 |
| terminal failure | 3 | 3 |
| terminal success | 3 | 3 |
| timeout after commit | 3 | 3 |
| version mismatch | 3 | 3 |
| webhook duplicate | 3 | 3 |
| webhook out of order | 3 | 3 |
| wrong amount | 3 | 3 |
| wrong resource | 1 | 1 |
| wrong subject | 3 | 3 |
| wrong terminal state | 3 | 3 |
The conformance artifact digest is d375359d3d20fb3f. The harness signs the run, so a reader can check that these numbers come from that run.
What remains uncertain?
The level is Provisional because of it. A lifecycle state has unknown semantics. The compiler cannot prove the end state. 10 uncertainty records are open. The lowest cap is 49. Provely does not guess a rule that a source does not state.
Where do these facts come from?
Every claim above cites a source assertion in the skill provenance. The compiler records the source, its hash, and the retrieval date. A page never states a provider rule without one.
| Source | Kind | Retrieved | Excerpt |
|---|---|---|---|
| square.docs.idempotency | docs | 2026-09-08 | authored |
| square.docs.payments | docs | 2026-09-08 | authored |
| square.docs.refunds | docs | 2026-09-08 | authored |
| square.docs.versions | docs | 2026-09-08 | authored |
| square.docs.webhooks | docs | 2026-09-08 | authored |
| square.events | event sample | 2026-09-08 | authored |
| square.openapi | openapi | 2026-09-08 | trimmed |
How do I verify a Square action?
Verify a Square action with Provely
- Begin the operation.Call
beginwith the contractsquare.payment.approvedand the input. Keep the operation id. - Make the Square call you make today.Send the request with the correlation metadata that
beginreturned. - Submit the acknowledgement.Call
action_resultwith the Square response. This is evidence level E1. It is not completion. - Verify.Call
verify. The runtime readspayment_action_response,payment_completed_events,payment_created_events,payment_readback,refund_completed_events,refund_created_eventsandrefund_readbackand evaluates the contract. - Report the verdict exactly as returned.VERIFIED comes with a signed receipt. PENDING comes with the operation id. CONTRADICTED and UNVERIFIABLE are not success.
Questions developers ask
Does the approved level prove the refunded level?
No. The card issuer authorised the amount, and Square holds the authorisation. This level does not prove a capture. The money did not move. A PaymentRefund object does not prove that money moved. This level proves the COMPLETED state on the refund and an event that carries it. Use square.refund.completed to prove refunded.
What does the agent say while Square reports APPROVED?
It says: "The action is accepted but not yet verified. Operation: <id>." The verdict is PENDING. The runtime observes again on the contract timing policy.
Which Square API versions does the skill support?
2026-08-19. An operation on another version returns UNVERIFIABLE with the reason version_unsupported. The runtime never guesses.
Does Provely need write access to Square?
No. The agent keeps its write key. The verifier reads with a separate read-only credential where Square permits it, and it never shares that credential with the agent.