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 endpoint host 'your-mssd.api.checkout.com.invalid' is a reserved .invalid placeholder that fails closed until you substitute the real host in both the endpoint URLs and the egress allowlist.
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/checkout.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.
checkout.payments.read v1.0.0R0
- Kind
- tool
- Action
- read
- Endpoint
GET https://your-mssd.api.checkout.com.invalid/payments/PAYMENT_ID- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-checkout-com-secret-key- Data class
- financial
Read payments.
Read one payment's record by ID: status, approval, source and the balances block (total authorised, captured, refunded and the available remainders). PAYMENT_ID is a placeholder to replace before enabling, and the host placeholder must be replaced with the deployment's MSSD host — see the pack notes.
checkout.payments.create v1.0.0R3
- Kind
- tool
- Action
- pay
- Endpoint
POST https://your-mssd.api.checkout.com.invalid/payments- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-checkout-com-secret-key- Data class
- financial
Create payments.
Request a payment or authorisation. The response distinguishes an authorization from a confirmed capture: even with the request's capture flag asking for automatic capture on authorisation, the response can come back Authorised (funds reserved, capture scheduled, not yet captured) — a successful HTTP response with approved=true does not by itself confirm capture — as well as Captured, a redirect-pending or otherwise Pending state (for example a 3DS challenge or an asynchronous payment method), or Declined.
Requesting automatic capture schedules capture; it does not guarantee a captured response, and settlement follows capture on acquirer timelines. The caller must inspect the response's status field — and, for final confirmation, the subsequent capture outcome — rather than assume one call completed the payment. 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 task budget; it does not bound the amount the provider request encodes — currency and minor units are the deployment's review.
On supported execution paths mediated by AAES Govern, the declared irreversible actions require an authorized person’s approval. Observation-only and bypass calls cannot be stopped by this control.
checkout.payments.refund v1.0.0R3
- Kind
- tool
- Action
- pay
- Endpoint
POST https://your-mssd.api.checkout.com.invalid/payments/PAYMENT_ID/refunds- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-checkout-com-secret-key- Data class
- financial
Refund payments.
Refund a captured payment: money moves back to the customer. Refunds are asynchronous — a successful request is Checkout.com accepting the refund for processing, not a completed refund: the refund begins Pending and its subsequent outcome (success or failure) arrives via webhook and on the refund and payment records, so the caller must check the final status rather than treat acceptance as completion. A refund may be partial, and omitting the amount requests a refund of the remaining refundable balance of the payment — an amount the caller did not declare — so the registered cost ceiling does not bound an amount-omitted refund.
The ceiling is a budget control on the declared amount only: 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. The action is pay at the minimum R3 tier, and pay is one of the designated actions requiring human approval. PAYMENT_ID is a placeholder to replace before enabling.
On supported execution paths mediated by AAES Govern, the declared irreversible actions require an authorized person’s approval. Observation-only and bypass calls cannot be stopped by this control.
checkout.disputes.read v1.0.0R0
- Kind
- tool
- Action
- read
- Endpoint
GET https://your-mssd.api.checkout.com.invalid/disputes- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-checkout-com-disputes-secret-key- Data class
- financial
Read disputes.
Read the collection of disputes (chargebacks) against the business, returned in reverse chronological order and filterable by status, payment id, entity and date range via query parameters. Collection read.
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-checkout-com-secret-key- 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
A Checkout.com secret API key created in the Dashboard under Developers > Keys, held in the client's own secret manager. The stored material must be the complete Authorization header value — Bearer followed by the secret key, scheme included: Checkout.com's API keys documentation explicitly instructs providing the secret API key in the Authorization header with the Bearer prefix (its example is 'Authorization: Bearer sk_sbox_...'), and that documented format is what this pack registers.
Checkout.com's other scheme — OAuth 2.0 client-credentials access keys, whose JWT access tokens are likewise sent with the Bearer prefix and expire after four hours — is a different credential this pack does not register; do not conflate the two. Provisioning and rotation are external: keys are created, viewed and deleted in the Dashboard (any Developer or Admin role can view or create; only the Account owner role can edit or delete existing keys), rotation means creating a replacement key, repointing this reference, then deleting the old key, and secret keys carry no automatic expiry — deleting the key in the Dashboard is the revocation act, so an un-rotated key remains valid until deleted. A key can be scoped to a specific set of APIs, and Checkout.com's own guidance for separate payments and disputes systems is one secret key for the Payments API and a second key exclusively for the Disputes API: this pack declares that separation — the payments capabilities use this reference, and checkout.disputes.read overrides it with secret-ref-checkout-com-disputes-secret-key, which must likewise hold only 'Bearer <disputes-scoped secret key>'.
Sandbox keys (prefix sk_sbox_) and production keys are different credentials: point these references at production keys only when the deployment is meant to move real money. 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
checkout-merchant-account(api, financial):https://your-mssd.api.checkout.com.invalid
Technical package and review record
Complete provider requirements and exclusions
Checkout.com requires a Merchant Specific Sub-Domain (MSSD) base URL — https://{prefix}.api.checkout.com for production and https://{prefix}.api.sandbox.checkout.com for sandbox, where {prefix} is the first eight characters of the deployment's client_id, excluding the cli_ prefix, visible in the Dashboard — and documents that a request to a non-MSSD base URL is refused with a 403 and error_type base_url_invalid. The host therefore varies per merchant, so this pack registers the reserved .invalid authority your-mssd.api.checkout.com.invalid, which cannot resolve: replace it with the deployment's MSSD host in the endpoints, the resource locator and the egress allowlist in step before enabling — the pack fails closed until that substitution is made.
This pack does not register payment captures or voids, the dispute evidence and acceptance endpoints, payment instruments, or the Flow and Sessions APIs. It registers the secret-key bearer credential; Checkout.com also offers OAuth 2.0 client-credentials access keys (tokens expire after four hours per the docs), which this pack does not register. AAES has not been certified by Checkout.com; 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
8 sources, retrieved 2026-09-21
- https://api-reference.checkout.com/tag/Payments/ (retrieved 2026-09-21)
- https://api-reference.checkout.com/tag/Disputes/ (retrieved 2026-09-21)
- https://www.checkout.com/docs/developer-resources/api/api-endpoints (retrieved 2026-09-21)
- https://www.checkout.com/docs/developer-resources/api/manage-api-keys/api-keys (retrieved 2026-09-21)
- https://www.checkout.com/docs/developer-resources/api/manage-api-keys/oauth-2-0-client-credentials (retrieved 2026-09-21)
- https://www.checkout.com/docs/payments/manage-payments/get-payment-details (retrieved 2026-09-21)
- https://www.checkout.com/docs/payments/accept-payments/request-a-payment (retrieved 2026-09-21)
- https://www.checkout.com/docs/payments/manage-payments/refund-a-payment/refund-a-payment-with-a-reference (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: f075b3b413e8bca6de7a3c2faa36a0964a3ad2fb2a95c6869600a316fde6219f
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.