Release identity
SHA-256 of the pack file bytes: 061bd416b8abdf165833b5972a21fa2e69c83bd4b4182ce58edb9887e0fb31b7
Not in the distributable release manifest. The binary carries a digest-bound manifest of the distributable library; a pack whose bytes differ from its manifest entry — endpoint, tier, allowlist, or credential edited, with provider, version, and review block preserved — fails the digest check, loses distributability, and renders MODIFIED rather than as the shipped reviewed artifact. Review state and artifact status are different facts: the first is a documentation-review declaration, the second is the identity of the exact bytes.
Capabilities (4)
paypal.orders.read v1.0.0R0
- Action
- read
- Endpoint
GET https://api-m.paypal.com/v2/checkout/orders/ORDER_ID- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-paypal-oauth-token- Data class
- financial
Read one order's record by ID: status, intent, purchase units and payer. ORDER_ID is a placeholder to replace before enabling.
paypal.orders.create v1.0.0R3
- Action
- pay
- Endpoint
POST https://api-m.paypal.com/v2/checkout/orders- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-paypal-oauth-token- Data class
- financial
Create an order. The caller controls the request body, and creation is not limited to the basic redirect flow: a bare order is created in status CREATED awaiting separate payer approval and capture, but a create call may also supply a payment_source so that creation itself processes payment for the order (the reference notes a PayPal-Request-Id is required when processing payment at creation), and the caller-controlled processing_instruction includes ORDER_COMPLETE_ON_PAYMENT_APPROVAL, under which supported payment sources complete the order — capture included — when the payer approves, with no separate capture call. Unrestricted creation can therefore open — and for some configurations complete — a payment workflow for a declared amount, so the action is pay at the R3 floor, and pay is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). The registered cost ceiling is a budget control on the declared amount: the gateway refuses a declared amount above it and commits the ceiling against the work budget; it does not bound the amount the provider request encodes — the order's value and currency are the deployment's review.
paypal.orders.capture v1.0.0R3
- Action
- pay
- Endpoint
POST https://api-m.paypal.com/v2/checkout/orders/ORDER_ID/capture- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-paypal-oauth-token- Data class
- financial
Capture payment for an approved order: this is the call that moves money when it succeeds. A successful HTTP response does NOT guarantee a completed capture — the response carries a capture whose status the caller must inspect: it can be COMPLETED, but also PENDING (with a status_details reason, for example awaiting manual action under the payee's receiving preference) or DECLINED, and other payment outcomes are possible; only a COMPLETED capture is money moved. The action is pay at the R3 floor, and pay is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). ORDER_ID is a placeholder to replace before enabling. The registered cost ceiling is a budget control on the declared amount: a capture completes for the approved order's amount, which the provider holds, so the ceiling constrains what the caller declares, not necessarily what PayPal moves.
paypal.payments.refunds.read v1.0.0R0
- Action
- read
- Endpoint
GET https://api-m.paypal.com/v2/payments/refunds/REFUND_ID- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-paypal-oauth-token- Data class
- financial
Read one refund's record by ID: status, amount and the capture it refunds. REFUND_ID is a placeholder to replace before enabling.
Credential reference
The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.
- Reference
secret-ref-paypal-oauth-token- Custody
- customer_vault
- Injection
- header (Authorization)
An OAuth2 access token for the PayPal REST API, minted with the client-credentials grant (POST https://api-m.paypal.com/v1/oauth2/token; sandbox: https://api-m.sandbox.paypal.com/v1/oauth2/token, HTTP Basic with the deployment's own client ID and secret, grant_type=client_credentials, per PayPal's authentication documentation). The client ID and secret stay with an external token process that mints tokens and stores ONLY the complete Authorization header value under this reference — 'Bearer <access_token>', scheme included — refreshing ahead of expiry; neither the executor nor the agent ever sees the client credentials, and this reference must never hold them. Access tokens are short-lived: the token response carries expires_in (PayPal's documented sample is roughly nine hours), so the external process mints a replacement rather than letting this reference go stale. Privilege is bounded by the features enabled on the app in the PayPal Developer dashboard — the returned token carries that app's scopes — so the external process uses an app configured with only the access this integration needs; PayPal documents no finer per-token restriction. To retire this reference, rotate or remove the client secret in the Developer dashboard so no further tokens can be minted; PayPal documents expiry and re-minting, not individual access-token revocation, so already-minted tokens remain valid until their expires_in elapses. At execution time the resolved material exists in the executor process's memory for the moment of injection only — the deployment owns the executor's memory, log, trace and crash hygiene; the agent never receives it.
Resources
paypal-account(api, financial):https://api-m.paypal.com
Pack notes and exclusions
Hosts are per environment: PayPal's API reference shows the live host https://api-m.paypal.com and the sandbox host https://api-m.sandbox.paypal.com. This pack registers the live host; a sandbox deployment replaces the host in the endpoint and the egress allowlist in step. This pack does not register order authorization, reauthorization or void, and it does not register refund creation (POST /v2/payments/captures/{capture_id}/refund): the reviewed money-moving surface is the order capture below, and refund creation — money moving back to a payer — is a pay capability the deployment adds under the same wording when it needs it. It does not register PayPal Payouts, Invoicing, Subscriptions or the v1 APIs. AAES has not been certified by PayPal; the endpoints here are a reviewable default, not a vendor guarantee.
Review record
Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)
- https://developer.paypal.com/docs/api/orders/v2/ (retrieved 2026-09-21)
- https://developer.paypal.com/docs/api/payments/v2/ (retrieved 2026-09-21)
- https://developer.paypal.com/api/rest/authentication/ (retrieved 2026-09-21)
A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.