ProvelyNo. PayPal REST API returns a success response when it accepts the request. The capture then holds one of 6 states. Only COMPLETED is terminal success. Provely proves capture_completed, capture_recorded, refund_completed and refund_recorded 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: 59 of 59 cases passed, 0 critical false VERIFIED |
| Provider API versions | v2 |
| Default provider API version | v2 |
| Compiled | 2026-09-05T12:00:00Z by compiler 0.1.0 |
| Manifest hash | b569478a510412b0 |
| 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 captured payment reached the status COMPLETED. A 201 Created answer with the status PENDING is an object that exists and not money that moved. | paypal.capture.completed | E2 + E3 | proven |
| The captured payment exists with the intended order, amount, and currency. A 201 Created answer with the status PENDING proves that no money moved. | paypal.capture.recorded | E2 + E3 | proven |
| The refund reached the status COMPLETED. A 201 Created answer with the status PENDING is an object that exists and not money that went back. | paypal.refund.completed | E2 + E3 | proven |
| The refund exists with the intended amount and currency, and an event ties it to the intended captured payment. It proves no money went back. | paypal.refund.recorded | E2 + E3 | proven |
| An outcome outside PayPal REST API, such as a bank credit or a person who read a message | not proven | no E5 channel | not proven |
The meaning of the FAILED state of paypal.capture | not proven | no source states it | not proven |
The meaning of the CANCELLED state of paypal.refund | 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 PayPal REST API 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 |
|---|---|---|---|---|
capture_completed | paypal.capture.completed v1.0.0 | The captured payment reached the status COMPLETED. A 201 Created answer with the status PENDING is an object that exists and not money that moved. | E2 + E3 | Provisional |
capture_recorded | paypal.capture.recorded v1.0.0 | The captured payment exists with the intended order, amount, and currency. A 201 Created answer with the status PENDING proves that no money moved. | E2 + E3 | Provisional |
refund_completed | paypal.refund.completed v1.0.0 | The refund reached the status COMPLETED. A 201 Created answer with the status PENDING is an object that exists and not money that went back. | E2 + E3 | Provisional |
refund_recorded | paypal.refund.recorded v1.0.0 | The refund exists with the intended amount and currency, and an event ties it to the intended captured payment. It proves no money went back. | E2 + E3 | Provisional |
What is the PayPal REST API lifecycle?
Which states can a paypal.capture be in?
| State | Class | Verdict | Meaning | Source |
|---|---|---|---|---|
PENDING | transitional | PENDING | The captured payment exists and the money did not move. The member status_details.reason states why. | paypal.payments.openapi |
COMPLETED | terminal success | VERIFIED | The capture completed. The money moved from the payer to the payee. | paypal.payments.openapi |
DECLINED | terminal failure | FAILED | PayPal declined the capture. No money moved. | paypal.payments.openapi |
REFUNDED | terminal neutral | FAILED | The money moved and a refund returned all of it. The capture is not a failure, and it holds no money now. | paypal.payments.openapi |
PARTIALLY_REFUNDED | terminal neutral | FAILED | The money moved and a refund returned a part of it. | paypal.payments.openapi |
FAILED | unknown | UNVERIFIABLE | The published enumeration lists this status. No source of this compile states what it means for the money, and the event table names no event for it. | paypal.payments.openapi |
In paypal.capture under provider API version v2, COMPLETED is the only state that means terminal success. Every other state gives PENDING, FAILED, or UNVERIFIABLE.
Source: paypal.payments.openapi · retrieved 2026-09-08
Which states can a paypal.refund be in?
| State | Class | Verdict | Meaning | Source |
|---|---|---|---|---|
PENDING | transitional | PENDING | The refund exists and the money did not move back. An eCheck refund waits for the bank of the merchant. | paypal.payments.openapi |
COMPLETED | terminal success | VERIFIED | The refund completed. The money went back to the payer. | paypal.payments.openapi |
FAILED | terminal failure | FAILED | The settlement process of the bank did not issue the refund. | paypal.payments.openapi |
CANCELLED | unknown | UNVERIFIABLE | The published enumeration lists this status. No source of this compile states when a refund reaches it, and the event table names no event for it. | paypal.payments.openapi |
In paypal.refund under provider API version v2, COMPLETED is the only state that means terminal success. Every other state gives PENDING, FAILED, or UNVERIFIABLE.
Source: paypal.payments.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 | capture_id from $action.result.purchase_units[0].payments.captures[0].id | yes | none |
fingerprint | weak | order_id from $input.order_id; amount from $input.amount | no | 600000 ms |
resource_id | weak | capture_id from $input.capture_id | no | 600000 ms |
resource_id | strong | refund_id from $action.result.id | no | none |
fingerprint | weak | capture_id from $input.capture_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 PayPal REST API is E1 and never terminal success.
| Channel | Level | Independence | Verifier | Deterministic | Typical latency |
|---|---|---|---|---|---|
capture_completed_events | E3 | provider event | webhook | no | 5000 ms |
capture_readback | E2 | provider readback | http | yes | 400 ms |
capture_refunded_events | E3 | provider event | webhook | no | 5000 ms |
capture_status_events | E3 | provider event | webhook | no | 5000 ms |
refund_readback | E2 | provider readback | http | yes | 400 ms |
Which ways can a PayPal REST API action look done and not be?
| Contract | Case | Rule | Verdict |
|---|---|---|---|
| paypal.capture.completed | wrong subject | The captured payment belongs to a different order than the intent named. | CONTRADICTED |
| paypal.capture.completed | wrong amount | PayPal captured a different amount than the intent stated. | CONTRADICTED |
| paypal.capture.completed | wrong amount | PayPal captured a different currency than the intent stated. | CONTRADICTED |
| paypal.capture.completed | pre existing state | The captured payment is older than the operation. It proves nothing. | CONTRADICTED |
| paypal.capture.completed | duplicate side effect | PayPal completed more than one capture of the order. Do not retry. | CONTRADICTED |
| paypal.capture.completed | observed state | PayPal declined the capture. No money moved. Retry with the first request id. | FAILED |
| paypal.capture.completed | observed state | The capture is pending. The money did not move. The runtime observes again. | PENDING |
| paypal.capture.completed | observed state | A refund reversed the capture before the verification. Ask a person. | CONTRADICTED |
| paypal.capture.recorded | wrong subject | The captured payment belongs to a different order than the intent named. | CONTRADICTED |
| paypal.capture.recorded | wrong amount | PayPal captured a different amount than the intent stated. | CONTRADICTED |
| paypal.capture.recorded | wrong amount | PayPal captured a different currency than the intent stated. | CONTRADICTED |
| paypal.capture.recorded | pre existing state | The captured payment is older than the operation. It proves nothing. | CONTRADICTED |
| paypal.refund.completed | wrong amount | PayPal refunded a different amount than the intent stated. | CONTRADICTED |
| paypal.refund.completed | wrong amount | PayPal refunded a different currency than the intent stated. | CONTRADICTED |
| paypal.refund.completed | pre existing state | The refund is older than the operation. It proves nothing. | CONTRADICTED |
| paypal.refund.completed | duplicate side effect | PayPal refunded the captured payment more than once since the operation started. Do not retry. | CONTRADICTED |
| paypal.refund.completed | observed state | The settlement process of the bank did not issue the refund. Retry with the first request id. | FAILED |
| paypal.refund.completed | observed state | The refund is pending. The money did not move back. The runtime observes again. | PENDING |
| paypal.refund.recorded | wrong amount | PayPal refunded a different amount than the intent stated. | CONTRADICTED |
| paypal.refund.recorded | wrong amount | PayPal refunded a different currency than the intent stated. | CONTRADICTED |
| paypal.refund.recorded | pre existing state | The refund is older than the operation. It proves nothing. | CONTRADICTED |
| paypal.refund.recorded | duplicate side effect | PayPal refunded the captured payment more than once since the operation started. Do not retry. | CONTRADICTED |
What did the last conformance run show?
| Dimension | Score | Maximum |
|---|---|---|
| Documentation | 14 | 20 |
| Schema alignment | 0 | 15 |
| Lifecycle certainty | 16 | 20 |
| Evidence strength | 16 | 20 |
| Causal correlation | 10 | 15 |
| Sandbox conformance | 10 | 10 |
| Raw score | 66 | 100 |
| Score after the caps | 49 | 100 |
The raw score is 66. 4 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 |
| No strong correlation strategy ties the evidence to the operation. | 69 |
| 24 uncertainty records are open. The lowest cap is 49. | 49 |
| 6 mandatory cases are missing. Example: paypal.capture.completed:duplicate_side_effect. | 74 |
| Contract | Raw score | Score after the caps | Certification |
|---|---|---|---|
paypal.capture.completed | 71.67 | 49 | Provisional |
paypal.capture.recorded | 71.67 | 49 | Provisional |
paypal.refund.completed | 65 | 49 | Provisional |
paypal.refund.recorded | 65 | 49 | Provisional |
The weakest contract is paypal.capture.completed. 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 59 of 59 cases with 0 critical false VERIFIED. One critical false VERIFIED rejects a skill.
| Case class | Passed | Total |
|---|---|---|
| duplicate side effect | 2 | 2 |
| error after execution | 4 | 4 |
| error before execution | 4 | 4 |
| evidence unavailable | 4 | 4 |
| idempotent retry | 4 | 4 |
| pre existing state | 4 | 4 |
| stale readback | 4 | 4 |
| still transitional | 4 | 4 |
| terminal failure | 2 | 2 |
| terminal success | 4 | 4 |
| timeout after commit | 4 | 4 |
| version mismatch | 4 | 4 |
| webhook duplicate | 4 | 4 |
| webhook out of order | 4 | 4 |
| wrong amount | 4 | 4 |
| wrong subject | 2 | 2 |
| wrong terminal state | 1 | 1 |
The conformance artifact digest is 7a1ba0842c927b54. 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. 24 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 |
|---|---|---|---|
| paypal.docs.captures | docs | 2026-09-08 | authored |
| paypal.docs.credentials | docs | 2026-09-08 | authored |
| paypal.docs.idempotency | docs | 2026-09-08 | authored |
| paypal.docs.refunds | docs | 2026-09-08 | authored |
| paypal.docs.sandbox | docs | 2026-09-08 | authored |
| paypal.docs.versions | docs | 2026-09-08 | authored |
| paypal.docs.webhooks | docs | 2026-09-08 | authored |
| paypal.events | event sample | 2026-09-08 | authored |
| paypal.orders.openapi | openapi | 2026-09-08 | trimmed |
| paypal.payments.openapi | openapi | 2026-09-08 | trimmed |
How do I verify a PayPal REST API action?
Verify a PayPal REST API action with Provely
- Begin the operation.Call
beginwith the contractpaypal.capture.completedand the input. Keep the operation id and the idempotency key. - Make the PayPal REST API call you make today.Send the
PayPal-Request-Idheader with the key thatbeginreturned. A retry then cannot create a second side effect. - Submit the acknowledgement.Call
action_resultwith the PayPal REST API response. This is evidence level E1. It is not completion. - Verify.Call
verify. The runtime readscapture_completed_events,capture_readback,capture_refunded_events,capture_status_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 capture_completed level prove the refund_recorded level?
No. The captured payment reached the status COMPLETED. A 201 Created answer with the status PENDING is an object that exists and not money that moved. The refund exists with the intended amount and currency, and an event ties it to the intended captured payment. It proves no money went back. Use paypal.refund.recorded to prove refund_recorded.
What does the agent say while PayPal REST API reports PENDING?
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 PayPal REST API API versions does the skill support?
v2. An operation on another version returns UNVERIFIABLE with the reason version_unsupported. The runtime never guesses.
Does Provely need write access to PayPal REST API?
No. The agent keeps its write key. The verifier reads with a separate read-only credential where PayPal REST API permits it, and it never shares that credential with the agent.