Release identity
SHA-256 of the pack file bytes: cecf243d1d46ba8aeb0fc5ec4c06c54307300ab0127114a11600bf5d6e43a937
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 (6)
adyen.payment_links.read v1.0.0R0
- Action
- read
- Endpoint
GET https://checkout-test.adyen.com/v71/paymentLinks/LINK_ID- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-adyen-api-key- Data class
- financial
Read one payment link's record, including its status. LINK_ID is a placeholder to replace before enabling.
adyen.payment_sessions.result.read v1.0.0R0
- Action
- read
- Endpoint
GET https://checkout-test.adyen.com/v71/sessions/SESSION_ID- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-adyen-api-key- Data class
- financial
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.
adyen.payment_sessions.create v1.0.0R3
- Action
- pay
- Endpoint
POST https://checkout-test.adyen.com/v71/sessions- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-adyen-api-key- Data class
- financial
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 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 — currency and minor units are the deployment's review.
adyen.payments.create v1.0.0R3
- Action
- pay
- Endpoint
POST https://checkout-test.adyen.com/v71/payments- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-adyen-api-key- Data class
- financial
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 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.
adyen.payments.capture v1.0.0R3
- Action
- pay
- Endpoint
POST https://checkout-test.adyen.com/v71/payments/PAYMENT_PSP_REFERENCE/captures- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-adyen-api-key- Data class
- financial
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. The 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 R3 floor, and pay is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). PAYMENT_PSP_REFERENCE is a placeholder to replace before enabling. The registered cost ceiling is a budget control on the declared amount and does not bound the amount the provider request encodes.
adyen.payments.refund v1.0.0R3
- Action
- pay
- Endpoint
POST https://checkout-test.adyen.com/v71/payments/PAYMENT_PSP_REFERENCE/refunds- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-adyen-api-key- Data class
- financial
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. Request 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. The action is pay at the R3 floor, and pay is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). PAYMENT_PSP_REFERENCE is a placeholder to replace before enabling. 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.
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-adyen-api-key- Custody
- customer_vault
- Injection
- header (X-API-Key)
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. The 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 right 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. Executor 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.
Resources
adyen-merchant-account(api, financial):https://checkout-test.adyen.com/v71
Pack notes and exclusions
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. This 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. Exclusions, 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. Webhooks 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 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://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) — manual capture flow; CAPTURE webhook success true is scheme submission, CAPTURE_FAILED can follow even days later
- https://docs.adyen.com/online-payments/refund/ (retrieved 2026-09-21) — asynchronous refund acknowledgement; REFUND, REFUND_FAILED and REFUNDED_REVERSED webhook outcomes
- 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)
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.