ProvelyNo. PayPal REST API returns a success response when it accepts the request. 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 |
| 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-05 |
| 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 a PayPal REST API state that no source states | 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 |
Which ways can a PayPal REST API action look done and not be?
| Contract | Case | Verdict |
|---|---|---|
| paypal.capture.completed | duplicate side effect | CONTRADICTED |
| paypal.capture.completed | pre existing state | CONTRADICTED |
| paypal.capture.completed | wrong amount | CONTRADICTED |
| paypal.capture.completed | wrong subject | CONTRADICTED |
| paypal.capture.recorded | pre existing state | CONTRADICTED |
| paypal.capture.recorded | wrong amount | CONTRADICTED |
| paypal.capture.recorded | wrong subject | CONTRADICTED |
| paypal.refund.completed | duplicate side effect | CONTRADICTED |
| paypal.refund.completed | pre existing state | CONTRADICTED |
| paypal.refund.completed | wrong amount | CONTRADICTED |
| paypal.refund.recorded | duplicate side effect | CONTRADICTED |
| paypal.refund.recorded | pre existing state | CONTRADICTED |
| paypal.refund.recorded | wrong amount | CONTRADICTED |
What did the last conformance run show?
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.
| Contract | Certification |
|---|---|
paypal.capture.completed | Provisional |
paypal.capture.recorded | Provisional |
paypal.refund.completed | Provisional |
paypal.refund.recorded | Provisional |
The weakest contract is paypal.capture.completed. It 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.
| 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. 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 reads the evidence that the contract names, from PayPal REST API and not from the agent, and 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 the PayPal REST API action is still in progress?
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.