ProvelyThe verdict is PENDING. The runtime keeps observing. A provider callback wakes the operation, the verifier reads the provider again, and the verdict waits for evidence. Your agent reports the operation id and exits.
A side effect completes in the provider, not in your process. Stripe accepts a refund in milliseconds. The bank moves the money later. Provely never collapses the two moments into one word.
Why is PENDING not a failure?
PENDING states one fact: the evidence does not decide yet. An operation moves CREATED to ACTION_STARTED to ACTION_ACCEPTED to OBSERVING to PENDING. A terminal verdict is VERIFIED, CONTRADICTED, FAILED, UNVERIFIABLE, EXPIRED, or HUMAN_REVIEW.
Safety rule 3 is frozen. When an operation can still make progress, the runtime returns PENDING, not FAILED. Read the PENDING definition.
The verdict map of stripe.refund.succeeded names the transitional states: pending and requires_action. Each one gives PENDING with the reason still_transitional.
Which promise does each contract prove?
The Stripe skill 0.1.0 ships two completion levels, and each level is one contract. A completion level is a promise, not a stage.
| Level | Contract | What the contract proves |
|---|---|---|
created | stripe.refund.created | The created level proves that the Refund object exists at the provider with the requested amount and charge. It does not prove that money moved. |
succeeded | stripe.refund.succeeded | A Refund object does not prove that money moved. This contract proves the succeeded state on the refund resource and a refund.updated event that carries it. |
A created Refund object is not moved money. A page, a receipt, and an agent must never present the lower level as terminal success.
Which evidence proves that the money moved?
The contract stripe.refund.succeeded reads three channels. The readback asks the provider for the refund. One event channel counts the events that carry the terminal state. The other event channel counts the refunds of the charge, because a second refund is a duplicate side effect. The minimum evidence level is E2, and an independent channel is required.
| Channel | Level | Independence | Typical latency | Worst case | Freshness |
|---|---|---|---|---|---|
refund_readback | E2 | provider readback | 250 ms | not stated | 10000 ms (10 seconds) |
refund_succeeded_events | E3 | provider event | 4000 ms (4 seconds) | 259200000 ms (3 days) | not stated |
refund_created_events | E3 | provider event | 4000 ms (4 seconds) | 259200000 ms (3 days) | not stated |
The skill records 259200000 ms (3 days) as the worst-case delivery of the refund_succeeded_events channel, under provider API version 2026-08-26. A contract that treated a silent hour as a failure would be wrong.
Source: stripe.docs.webhooks · retrieved 2026-09-05
The two channels answer at different speeds, so the runtime does not depend on one of them. A readback that is fresh decides without a callback. A callback decides when a readback is stale.
How long does the runtime observe?
The contract states the timing policy. The runtime reads it. No code holds a Stripe number.
| Setting | Value | What it does |
|---|---|---|
| Initial delay | 1000 ms (1 second) | The runtime waits this long before the first observation. |
| Poll interval | 5000 ms (5 seconds) | The wait before the second observation. The backoff grows it. |
| Backoff | exponential, factor 2, maximum 60000 ms (1 minute) | Each wait grows by the factor. It never passes the maximum. |
| Maximum attempts | 40 | The runtime stops after this many observations. |
| Timeout | 604800000 ms (7 days) | The deadline of the operation. The runtime stops here. |
| Stale read window | 20000 ms (20 seconds) | A reading older than this window does not decide. The verdict stays PENDING. |
The runtime stops at the first limit that it reaches: the attempt count, or the deadline. A callback that arrives while the operation is open wakes it, so a late event does not wait for the next poll.
What happens when a callback arrives?
Every delivery passes the same rules. None of them trusts the agent.
| Rule | What the runtime does |
|---|---|
| One endpoint | A provider posts to POST /v1/events/{provider}/{workspace}. The route takes no API key. |
| Signature first | The connection states the signature scheme. A delivery that fails the check is refused. |
| Duplicate delivery | The store deduplicates on the provider event id. A repeat answers 200 and writes nothing. |
| Late and out of order | The runtime orders events by provider_timestamp. The arrival order decides nothing. |
| Correlation | The event must name this operation. The strategy is resource_id, assurance strong, from $action.result.id. |
| Wake | An event that correlates with an open operation moves its next attempt to now. The verifier reads the provider again at once. |
Safety rule 6 says that evidence must correlate with the exact operation. A refund that existed before the operation started proves nothing, and the negative condition refund_predates_operation contradicts it. Read the correlation definition.
What happens when a callback never arrives?
The operation reaches its timeout. The contract states the result: UNVERIFIABLE, with the reason evidence_unavailable_before_timeout, and the operation moves to HUMAN_REVIEW. The verdict is never FAILED. Provely does not know that the refund failed. It knows that no evidence arrived.
Before the deadline, a channel that cannot answer gives UNVERIFIABLE with the reason evidence_unavailable. The frozen retry table then permits one action: retry the verification. Never the refund. Read the verdicts and the retry rules.
Never retry a side-effecting action on PENDING. The action can still succeed, and a second call refunds the customer twice.
What must the agent do while it waits?
Nothing. An ephemeral agent must not hold a process open for 604800000 ms (7 days).
- Report the action result to the operation.
- Read the verdict. PENDING is a normal answer.
- Report the operation id, and exit.
- Ask again later with
GET /v1/operations/{id}. - Never repeat the action while the verdict is PENDING.
The verifier keeps observing without the agent. The receipt is ready when the evidence decides. Read what a receipt proves.
Does PENDING mean the refund failed?
No. PENDING means that the evidence does not decide yet. A refund in a transitional state can still succeed. A retry would refund the customer twice.
Does a late webhook break the verdict?
No. The runtime orders events by provider_timestamp, and it deduplicates on the provider event id. The arrival order decides nothing.
What does Provely return when no evidence ever arrives?
UNVERIFIABLE with the reason evidence_unavailable_before_timeout. The verdict states that the evidence stayed insufficient. It never states that the provider failed.