canonical: https://jentic.com/apis/adyen.com/adyen-marketpay-notification-service # Adyen Classic Platforms Notifications 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. ## For AI agents Reference for the webhook payloads Adyen sends from the classic for-platforms integration, covering account holders, accounts, fund management, and platform events. ## Scope Does not handle outbound API calls or modern Balance Platform events - use for receiving and parsing classic for-platforms webhook events only. ## Capabilities - Describe payload schemas for account holder events such as creation, updates, and verification status changes - Describe payload schemas for account-level events covering balance changes and account closures - Describe payload schemas for fund management events such as transfers, payouts, and refunds - Authenticate inbound webhook calls using HTTP Basic credentials configured on the receiver - Provide the contract a receiver needs to parse and idempotently process classic platform events ## Use cases ### Marketplace Settlement Reconciliation Reconcile internal marketplace ledgers against Adyen's view of fund movements by listening for transfer, payout, and refund webhooks delivered from the classic for-platforms integration. The receiver parses the event payload using this spec and updates its ledger to match. Suitable for marketplaces that need an authoritative view of which transfers have actually settled and which are still pending. Example prompt: Configure the receiver to parse PAYOUT_SENT and TRANSFER_FUNDS events and reconcile each against the corresponding entry in the marketplace_ledger table ### Account Holder Status Sync Keep the marketplace platform's source-of-truth in sync with Adyen account holder verification status by listening for account holder webhook events. The classic platforms notifications spec documents the payload format so the receiver can identify the affected account holder and update its KYC state accordingly. Useful for marketplaces with automated rules that block trading when verification regresses. Example prompt: Listen for ACCOUNT_HOLDER_STATUS_CHANGE events, look up the affected accountHolderCode, and update its KYC state in the platform database ### AI Agent Settlement Awareness AI agents that trigger payouts or transfers via the Adyen Fund API through Jentic can subscribe to Classic Platforms Notifications to confirm that fund movements settled. The agent uses Jentic to call the Notification Configuration API to subscribe, parses inbound events using the receiver schema, and updates its internal state when payouts complete. Outbound API credentials remain isolated in your Jentic One instance while the receiver authenticates inbound webhooks with HTTP Basic credentials. Example prompt: After triggering a payout via the Fund API through Jentic, listen for the PAYOUT_SENT event and update the agent's internal state when the matching pspReference appears ## Key resources - **Account Holder Events** — Payloads for account holder creation, updates, and verification status changes - **Account Events** — Payloads for account creation, balance changes, and closure - **Fund Management Events** — Payloads for transfers, payouts, refunds, and direct debits on platform accounts - **Other Events** — Auxiliary platform events not covered by the primary categories ## Why Jentic - **Setup:** Wiring Adyen Classic Platforms notifications by hand means managing subscriptions on the classic CAL host and validating inbound calls with a separate HTTP Basic credential. Through Jentic you install once, import the Classic Platforms notifications from the API Directory, store both credentials once, and your agent handles subscriptions and payloads. - **Permission scoping:** These are inbound classic platform event schemas rather than outbound calls with a resource id in the URL, so you limit the agent to the operations it needs, such as parsing a payout-sent event. Because you pick the operations, the agent only handles the event types you include. - **Credential handling:** Your Adyen subscription credentials and the HTTP Basic credential for inbound receivers are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'subscribe to adyen classic platforms notifications' or 'parse a payout sent event', and Jentic returns the matching Notification operation with its receiver payload schema so the agent handles the right type without browsing the reference docs. ## Related APIs - **Adyen Fund API** — Triggers the fund movements that this notification spec describes the events for - **Adyen Account API** — Manages the account holders whose lifecycle events appear in these notifications - **Adyen Management Webhooks** — Webhook payload spec for the modern Management API surface instead of classic platforms ## FAQ ### What authentication does Adyen use for Classic Platforms Notifications? Adyen authenticates inbound calls to your notification endpoint with HTTP Basic credentials configured when you create the subscription via the Notification Configuration API or in the Customer Area. Your receiver should reject requests that do not present the configured username and password. Through Jentic, the credentials used to manage subscriptions via the Notification Configuration API are stored encrypted in your Jentic One instance. ### How do I create or change a notification subscription? Subscriptions are managed by Adyen's Notification Configuration API, not by this notifications spec. Use that API (or the Customer Area UI) to create, update, or remove subscriptions pointing at your receiver URL. This spec only describes the payloads delivered to a configured subscription. Through Jentic, search for 'create Adyen classic platforms notification subscription' to find the matching operation. ### What is the difference between this spec and Management Webhooks? Classic Platforms Notifications cover the legacy Adyen for Platforms (MarketPay) integration, with events on account holders, accounts, and fund movements. Management Webhooks cover configuration changes (merchant accounts, payment methods, terminals) on the modern Management API. Use Classic Platforms Notifications for MarketPay integrations and Management Webhooks for modern platform configuration events. ### How do I subscribe to these notifications through Jentic? Search Jentic for 'create Adyen notification subscription' to find the matching operation on the Notification Configuration API. Required fields include the notification URL, event types, and HTTP Basic credentials. Jentic loads the schema and executes the call with vaulted credentials. Run it through Jentic One, the self-hosted execution layer. ### Are Classic Platforms Notification payloads signed? Adyen supports HMAC signature validation on classic platforms notifications when you configure an HMAC key on the subscription. The signature is delivered in a request header and the receiver must recompute it from the raw payload to verify authenticity. Always verify HMAC where configured rather than relying solely on HTTP Basic credentials. ### Can I limit what my agent is allowed to do with the Adyen Classic Platforms Notifications? Yes. Because Jentic One runs self-hosted, you set the rules that decide which operations and credentials your agent may use, and you can grant it only the notification operations it needs, such as parsing a payout-sent event or an account holder status change. These are inbound classic platform event schemas rather than outbound calls with a resource id in the URL, so scoping to a narrow set of operations means the agent only handles the event types you include. Your Notification Configuration and HTTP Basic credentials stay encrypted in your own Jentic One instance and are injected at execution time, never entering the agent's prompt or logs.