Capability library / Application package

PayPal package v1.0.0

Read PayPal orders and refunds, create orders, and capture approved payments. Order creation can initiate automatic authorization or capture on payer approval; capture responses require checking the payment status.

Review state: Reviewed · Distributable: yes, digest matches the release manifest

This page describes AAES Govern’s controls. AAES Operate has private-work permissions, operational reviews and recorded-spend limits; it does not include Govern. About AAES Govern

Before you enable this package

Budgets apply to the amount declared in the task, not to the amount the provider actually sends or moves. The package registers api-m.paypal.com for live requests. Sandbox use requires api-m.sandbox.paypal.com in endpoints and allowlists, with the matching credentials.

Read each action's effects and exclusions below. Before installation, also read the complete package requirements, including credential issuance, scope, expiry, and provider permissions. These are deployment prerequisites, not capabilities this package supplies.

Capabilities (4)

Each capability below is one registered operation. The complete package JSON includes its exact network destination allowlist. The repository stores it at packs/paypal.json and embeds a copy in the release binary.

Risk tiers. R0 is the minimum for reads. R2 is the minimum for write, create, update, execute, and invoke. R3 is the minimum for delete, send, pay, deploy, approve, share, and transfer. Operators can raise these levels. A minimum tier does not measure the operation's business or confidentiality risk.

On supported execution paths routed through AAES Govern, the R3 actions listed below require approval by an authorized person. Bypass paths and observation-only registrations are outside that guarantee. A provider's restoration feature does not remove this approval requirement. A provider-side approval, such as approving a GitLab merge request, is also separate from AAES Govern human approval. The capability matrix shows which execution paths are implemented, restricted to lab use, or refused at startup. Live compatibility must be tested in your environment.

Field guide. Endpoint is the service address and request method. Connector is the adapter that makes the call. Custody describes how the credential is held; the credential reference identifies the value to resolve. Data class sets handling requirements: pii means personal data, financial means financial records, and internal means internal organizational data.

paypal.orders.read v1.0.0R0

Kind
tool
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 orders.

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

Kind
tool
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 orders.

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, and the caller-controlled processing_instruction includes ORDER_COMPLETE_ON_PAYMENT_APPROVAL, under which the order auto-completes — authorize or capture depending on the intent — when the payer approves, with no separate capture call (the reference documents PayPal-Request-Id only as an optional idempotency header on this 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 minimum R3 tier, and pay is one of the designated actions requiring human approval.

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

Kind
tool
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 orders.

Request capture of payment for an approved order. Inspect the returned capture status before reporting money moved: COMPLETED establishes a completed capture; PENDING can require further action, such as manual acceptance under the payee's receiving preference; DECLINED and other outcomes are possible. A successful HTTP response alone does not establish completion.

The capability declares pay at R3, which requires human approval. Bind ORDER_ID before enabling. The registered cost ceiling constrains the caller's declared amount; PayPal captures the approved order's amount, which the provider holds, so the ceiling does not necessarily bound what PayPal moves.

paypal.payments.refunds.read v1.0.0R0

Kind
tool
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 payment refunds.

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 credential field names a reference rather than containing credential material. Packs are designed not to contain secrets; the format checks cover only known credential formats and cannot prove that arbitrary text contains no secrets. Installing a package registers its capabilities. Configure the provider credentials, endpoints, and network access, then test the integration in your environment before enabling it.

Reference
secret-ref-paypal-oauth-token
Custody
customer_vault
Injection
header (Authorization)

Configure the value and injection format specified in the package. Assign responsibility for credential rotation and revocation, restrict provider permissions, and keep credential material out of logs and responses.

Complete credential requirements

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

Technical package and review record

Complete provider requirements 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 above, 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 configuration to review and test; the vendor has not endorsed it.

Download the complete package JSON for exact network allowlists, credential requirements, exclusions, and setup notes. Read these requirements before installation.

The full documentation review record is supplied in the evaluation package. The evaluation package runs in your environment and comes only with the paid design partnership. This page reproduces the source links and review block; the full record is available for evaluation. Discuss a design partnership to inspect it before installation.

Review block

This section reproduces the review block recorded in the pack file. The evidence and approval record is separate: for a reviewed pack, it is in the evaluation materials and in the release binary's embedded assets.

Review completed: 2026-09-22

4 sources, retrieved 2026-09-21

Current documentation links are navigation aids. They do not change the package, its historical sources or its review date. Review dates describe a documentation review, not a live integration test. No package is provider-endorsed or yet tested against a live provider tenant.

Release identity

SHA-256 of the pack file bytes: 2ef91bfa53e0b0a6c18c9dfa31bebf009a630225b042c76d6e8c6a50fa10b9e7

Distributable: yes, digest matches the release manifest. Editing a package changes its release identity. A deployment plan checks its own file digests; it does not restore reviewed status or authenticate approval.