{ "schema": "aaes/capability-pack/1", "provider": "adyen", "version": "1.0.0", "description": "Adyen Checkout: read payment links and session results, create payment sessions and payments, and capture or refund payments.", "notes": "The Adyen Checkout API is write-first: it documents no list or get endpoint for payments themselves — payment outcomes are delivered on webhooks and read in the Customer Area — so this pack's reads are the record reads the API actually documents (a payment link, a session result). Hosts are per environment and, for live, per merchant: Adyen documents the test host https://checkout-test.adyen.com and the live pattern https://{PREFIX}-checkout-live.adyenpayments.com/checkout/{version}/{method}, where {PREFIX} — a hex random part plus the company name — comes from the live Customer Area under Developers > API URLs.\n\nThis pack registers the test host and version v71; going live means BOTH substituting the deployment's prefixed live authority and changing the path — /v71/... becomes /checkout/v71/... — in every endpoint and in the resource locator, with the egress allowlist updated in step, and pointing the credential reference at a live API key (host-only substitution produces wrong URLs); test and live keys are different credentials from different Customer Areas.\n\nExclusions, scoped to this pack and version: this pack does not register Adyen's Balance Platform, Management or payout APIs, which use different base hosts and credential roles, nor the Classic Payments API. Stored-payment-method (recurring token) operations also exist within this same Checkout API and version on these same hosts, and the registered /payments and /sessions requests document storePaymentMethod/recurring fields — so the exclusion of stored-payment-method operations is a scoping choice of this pack, not a property of the API surface or of the host, and a deployment that must keep tokenisation out of scope has to constrain those request fields at the wiring layer.\n\nWebhooks are inbound and are not capabilities — but the capture and refund capabilities' outcomes arrive only on webhooks (CAPTURE/CAPTURE_FAILED, REFUND/REFUND_FAILED/REFUNDED_REVERSED), so the deployment must consume them to learn what actually happened. AAES has not been certified by Adyen; the endpoints here are configuration to review and test; the vendor has not endorsed it.\nSource annotation for https://docs.adyen.com/online-payments/capture/ (retrieved 2026-09-21): — manual capture flow; CAPTURE webhook success true is scheme submission, CAPTURE_FAILED can follow even days later\nSource annotation for https://docs.adyen.com/online-payments/refund/ (retrieved 2026-09-21): — asynchronous refund acknowledgement; REFUND, REFUND_FAILED and REFUNDED_REVERSED webhook outcomes", "credential": { "secret_ref_id": "secret-ref-adyen-api-key", "custody": "customer_vault", "inject": "header", "inject_name": "X-API-Key", "note": "An Adyen API key generated in the Customer Area under Developers > API credentials, held in the client's own secret manager. The stored material must be the complete X-API-Key header value — the raw key, with no scheme prefix. Provisioning and rotation are external: keys are created, and can be revoked and regenerated, in the Customer Area, and Adyen does not document automatic expiry for API keys — a key remains valid until revoked or regenerated there, so rotation cadence and revocation-on-suspicion are the deployment's process, and a revoked key fails closed.\n\nThe credential's roles are chosen in the Customer Area, and the minimum that makes these capabilities work — the Checkout webservice role for the merchant account in question — is the required set. Test and live keys are different credentials from different Customer Areas: point this reference at a live key only when the deployment has also substituted its prefixed live host and the /checkout/v71 path form (see the pack notes) and is meant to move real money.\n\nExecutor hygiene: the resolved material must exist only in the executor process's memory for the moment of injection, must never be written to logs, traces or diagnostics, and must never appear in crash reports; the executor's memory, log and crash handling are otherwise the deployment's review." }, "capabilities": [ { "capability_id": "adyen.payment_links.read", "version": "1.0.0", "kind": "tool", "risk_tier": "R0", "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN", "data_class": "financial", "egress_allowlist": [ "checkout-test.adyen.com" ], "endpoint": "https://checkout-test.adyen.com/v71/paymentLinks/LINK_ID", "method": "GET", "connector": "http", "custody": "customer_vault", "secret_ref_id": "secret-ref-adyen-api-key", "inject": "header", "inject_name": "X-API-Key", "actions": [ "read" ], "resource_id": "adyen-merchant-account", "description": "Read one payment link's record, including its status. LINK_ID is a placeholder to replace before enabling.", "requires_review": true }, { "capability_id": "adyen.payment_sessions.result.read", "version": "1.0.0", "kind": "tool", "risk_tier": "R0", "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN", "data_class": "financial", "egress_allowlist": [ "checkout-test.adyen.com" ], "endpoint": "https://checkout-test.adyen.com/v71/sessions/SESSION_ID", "method": "GET", "connector": "http", "custody": "customer_vault", "secret_ref_id": "secret-ref-adyen-api-key", "inject": "header", "inject_name": "X-API-Key", "actions": [ "read" ], "resource_id": "adyen-merchant-account", "description": "Read the status of one payment session by session id; Adyen's docs require the sessionResult value from the Drop-in/Component as a query parameter. SESSION_ID is a placeholder to replace before enabling.", "requires_review": true }, { "capability_id": "adyen.payment_sessions.create", "version": "1.0.0", "kind": "tool", "risk_tier": "R3", "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN", "data_class": "financial", "egress_allowlist": [ "checkout-test.adyen.com" ], "endpoint": "https://checkout-test.adyen.com/v71/sessions", "method": "POST", "connector": "http", "custody": "customer_vault", "secret_ref_id": "secret-ref-adyen-api-key", "inject": "header", "inject_name": "X-API-Key", "actions": [ "pay" ], "resource_id": "adyen-merchant-account", "cost_ceiling_usd": 500, "description": "Create a payment session for Drop-in/Components or Hosted Checkout. The call creates a session object — money moves only later, when the shopper completes the session — but the session carries the amount and currency and is the documented first call of a payment workflow, so the action is pay at the minimum R3 tier, and pay is one of the designated actions requiring human approval.\n\nThe 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 task budget; it does not bound the amount the provider request encodes — currency and minor units are the deployment's review.\n\nOn supported AAES-mediated execution paths, the declared irreversible actions require an authorized person’s approval. Observation-only and bypass calls cannot be stopped by this control.", "requires_review": true }, { "capability_id": "adyen.payments.create", "version": "1.0.0", "kind": "tool", "risk_tier": "R3", "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN", "data_class": "financial", "egress_allowlist": [ "checkout-test.adyen.com" ], "endpoint": "https://checkout-test.adyen.com/v71/payments", "method": "POST", "connector": "http", "custody": "customer_vault", "secret_ref_id": "secret-ref-adyen-api-key", "inject": "header", "inject_name": "X-API-Key", "actions": [ "pay" ], "resource_id": "adyen-merchant-account", "cost_ceiling_usd": 500, "description": "Make a payment. A single call can result in an authorised payment, and where the account or payment method captures automatically, authorisation is followed by capture without a further call — so one call can move money, not merely create an object; the resultCode distinguishes Authorised (funds reserved) from RedirectShopper or an action object (request accepted, shopper step pending) from Refused. The action is pay at the minimum R3 tier, and pay is one of the designated actions requiring human approval.\n\nThe 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 task budget; it does not bound the amount the provider request encodes.\n\nOn supported AAES-mediated execution paths, the declared irreversible actions require an authorized person’s approval. Observation-only and bypass calls cannot be stopped by this control.", "requires_review": true }, { "capability_id": "adyen.payments.capture", "version": "1.0.0", "kind": "tool", "risk_tier": "R3", "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN", "data_class": "financial", "egress_allowlist": [ "checkout-test.adyen.com" ], "endpoint": "https://checkout-test.adyen.com/v71/payments/PAYMENT_PSP_REFERENCE/captures", "method": "POST", "connector": "http", "custody": "customer_vault", "secret_ref_id": "secret-ref-adyen-api-key", "inject": "header", "inject_name": "X-API-Key", "actions": [ "pay" ], "resource_id": "adyen-merchant-account", "cost_ceiling_usd": 500, "description": "Capture an authorised payment: capture is the step that requests transfer of the reserved funds. Adyen processes captures asynchronously and answers with status received — request accepted for processing, not money moved. The subsequent CAPTURE webhook distinguishes acceptance/processing from settlement: success true means the capture request was validated and submitted to the card scheme/processor — in rare cases the scheme can still reject the capture afterwards, even days later, which arrives as a CAPTURE_FAILED webhook, so success true is not the money-moved confirmation and must not be reported as one. A failed validation arrives as CAPTURE with success false and a reason.\n\nThe deployment must consume the CAPTURE and CAPTURE_FAILED webhooks (inbound webhooks are not capabilities of this pack) and handle failed captures per Adyen's failure guidance before treating funds as captured. The action is pay at the minimum R3 tier, and pay is one of the designated actions requiring human approval. PAYMENT_PSP_REFERENCE is a placeholder to replace before enabling.\n\nThe registered cost ceiling is a budget control on the declared amount and does not bound the amount the provider request encodes.\n\nOn supported AAES-mediated execution paths, the declared irreversible actions require an authorized person’s approval. Observation-only and bypass calls cannot be stopped by this control.", "requires_review": true }, { "capability_id": "adyen.payments.refund", "version": "1.0.0", "kind": "tool", "risk_tier": "R3", "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN", "data_class": "financial", "egress_allowlist": [ "checkout-test.adyen.com" ], "endpoint": "https://checkout-test.adyen.com/v71/payments/PAYMENT_PSP_REFERENCE/refunds", "method": "POST", "connector": "http", "custody": "customer_vault", "secret_ref_id": "secret-ref-adyen-api-key", "inject": "header", "inject_name": "X-API-Key", "actions": [ "pay" ], "resource_id": "adyen-merchant-account", "cost_ceiling_usd": 500, "description": "Refund a captured payment: requests that money move back to the shopper. The API acknowledges the request asynchronously — the response status is received (request accepted for processing), not completed shopper receipt. The subsequent REFUND webhook with success true means Adyen's validations passed and the refund was sent to the card scheme — in rare cases the scheme can still reject it afterwards (REFUND_FAILED, possibly days later), and for some payment methods a refund already marked Refunded can later be reversed (REFUNDED_REVERSED: the funds return to the merchant's account); funds can take up to 40 business days to reach the shopper depending on the payment method.\n\nRequest success must not be presented as completed shopper receipt: the deployment must consume the REFUND, REFUND_FAILED and REFUNDED_REVERSED webhooks (inbound webhooks are not capabilities of this pack) and handle failure and reversal per Adyen's guidance. The request names the amount in minor units — the currency must match the authorisation and the value may not exceed the captured amount — so full and partial refunds ride on the same call.\n\nThe action is pay at the minimum R3 tier, and pay is one of the designated actions requiring human approval. PAYMENT_PSP_REFERENCE is a placeholder to replace before enabling.\n\nThe 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 task budget; it does not bound the amount the provider request encodes.\n\nOn supported AAES-mediated execution paths, the declared irreversible actions require an authorized person’s approval. Observation-only and bypass calls cannot be stopped by this control.", "requires_review": true } ], "resources": [ { "resource_id": "adyen-merchant-account", "kind": "api", "locator": "https://checkout-test.adyen.com/v71", "data_class": "financial", "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN" } ], "review": { "state": "library", "date": "2026-09-22", "sources": [ "https://docs.adyen.com/api-explorer/Checkout/71/overview (retrieved 2026-09-21)", "https://docs.adyen.com/api-explorer/Checkout/71/post/payments (retrieved 2026-09-21)", "https://docs.adyen.com/api-explorer/Checkout/71/post/sessions (retrieved 2026-09-21)", "https://docs.adyen.com/api-explorer/Checkout/71/get/sessions/(sessionId) (retrieved 2026-09-21)", "https://docs.adyen.com/api-explorer/Checkout/71/get/paymentLinks/(linkId) (retrieved 2026-09-21)", "https://docs.adyen.com/api-explorer/Checkout/71/post/payments/(paymentPspReference)/captures (retrieved 2026-09-21)", "https://docs.adyen.com/api-explorer/Checkout/71/post/payments/(paymentPspReference)/refunds (retrieved 2026-09-21)", "https://docs.adyen.com/online-payments/capture/ (retrieved 2026-09-21)", "https://docs.adyen.com/online-payments/refund/ (retrieved 2026-09-21)", "https://docs.adyen.com/online-payments/adjust-authorisation/adjust-with-preauth (retrieved 2026-09-21)", "https://docs.adyen.com/development-resources/live-endpoints (retrieved 2026-09-21)" ], "reviewer_id": "aaes-eng" } }