Specification for the webhook payloads Adyen sends from the classic Adyen for Platforms (MarketPay) integration, covering account holders, accounts, fund management, and other platform-level events. Adyen makes HTTP POST requests to the merchant's configured notification endpoint with a JSON body that the receiver authenticates using HTTP Basic credentials. Subscriptions are created and managed via the separate Notification Configuration API, while this spec describes the payload contract receivers must parse.
0 endpointsConfigure and manage Adyen company and merchant accounts, stores, payment terminals, payment methods, users, API credentials, allowed origins, webhooks, and Android apps and certificates from a single REST surface. Version 1 of the Management API exposes 130 operations against /v1, covering company-level, merchant-level, and store-level configuration without requiring access to the Customer Area UI. New integrations should consider Management API v3, which is the actively evolving version.
130 endpointsConfigure and manage Adyen company and merchant accounts, stores, payment terminals, payment methods, users, API credentials, allowed origins, webhooks, and Android apps and certificates from a single REST surface. Version 3 is the actively evolving Management API with 134 operations against /v3, including additional create-and-upload patterns on Android apps and certificates compared to v1. Recommended for new integrations that need programmatic control over the Adyen platform.
134 endpointsSpecification for the webhook payloads Adyen sends when configuration changes happen across company and merchant accounts, stores, payment terminals, and payment methods that are managed via the Management API. Adyen makes HTTP POST requests to the merchant's configured webhook URL with the event payload as the body, and the merchant's server authenticates the request using HTTP Basic credentials. This spec describes the payload contracts so receivers can validate and parse incoming events.
0 endpointsThe Adyen Test Cards API generates custom test card number ranges for use in development and QA against Adyen's test environment. The single endpoint, POST /createTestCardRanges, returns synthetic PANs that approve, decline, or simulate specific behaviours such as 3D Secure challenges and fraud blocks. It exists so integrators can exercise edge cases that the standard Adyen test cards do not cover, such as a particular issuer country, fundingSource, or risk outcome.
1 endpointsStep 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | shStep 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.