Microsoft Dynamics 365 F&O and Adyen integration

What moves between them

The flow runs from Adyen into Microsoft Dynamics 365 F&O. ml-connector consumes Adyen settlement and reconciliation reports and posts the resulting journals into the Dynamics general ledger through journal entities: captured payments, refunds, processing fees, and chargebacks, each mapped to the matching main account and financial dimension. Capture, refund, and REPORT_AVAILABLE webhooks trigger the work as soon as activity settles, and a scheduled OData read backfills anything a webhook missed. Adyen is treated as a read-only accounting source, so ml-connector never writes payment instructions or financial entries back into Adyen.

How ml-connector handles it

ml-connector stores both credential sets encrypted, requests an Entra ID token with the environment .default scope for the OData service, and refreshes it when a call returns 401. It sends the Adyen X-API-Key on every request and switches to the merchant-specific live URL prefix when the environment is live, since Adyen has no generic live host. Adyen webhooks arrive signed with HMAC-SHA256, so each notification is verified before processing and the pspReference is used as a dedupe key, because Adyen can deliver the same notification more than once. On REPORT_AVAILABLE, the settlement report is downloaded from the signed URL, parsed, and its lines mapped to Dynamics main accounts and financial dimensions, which are aligned first so every journal line lands on a valid combination. Because posted ledger entries are read-only, postings are created through VendorPaymentJournalLines or CustomerPaymentJournalLines rather than written to GeneralJournalAccountEntries. Financial dimensions must be passed as the formatted display string Dynamics expects, and OData entity keys must be fully specified, including dataAreaId for the legal entity. Dynamics returns HTTP 429 with a Retry-After header under service protection limits and Adyen returns a too-many-requests error, so ml-connector backs off and retries on both sides, and every record carries an audit trail and can be replayed if a Dynamics post fails.

A real-world example

A mid-sized direct-to-consumer manufacturer with roughly 300 staff sells finished goods through its own online store and runs Microsoft Dynamics 365 F&O for production, inventory, and finance, with Adyen as the checkout payment processor. Before the integration, the finance team downloaded Adyen settlement reports each day and keyed the gross sales, refunds, and processing fees into Dynamics by hand, then spent month-end close reconciling each bank deposit against the orders it was supposed to cover. With the two systems connected, each settlement report posts into Dynamics automatically, split across the right main accounts and financial dimensions, so processing fees are recognized and the deposits already tie out. The daily re-keying step is gone and close starts from reconciled numbers.

What you can do

• •Post Adyen settlement and reconciliation reports into the Microsoft Dynamics 365 F&O general ledger after every payout.
• •Record captured payments, refunds, processing fees, and chargebacks against the correct Dynamics main accounts and financial dimensions.
• •Receive Adyen capture, refund, and report-available webhooks, verified by HMAC-SHA256, and act on them as activity settles.
• •Authenticate Adyen with its API key and live URL prefix, and Dynamics with an Entra ID OAuth client credentials token.
• •Honor Dynamics service protection limits and Adyen rate limits with backoff, retries, and an audit trail on every record.

Questions

Which direction does data move between Microsoft Dynamics 365 F&O and Adyen?

The flow is Adyen into Microsoft Dynamics 365 F&O. Settlement reports, captures, refunds, fees, and chargebacks move from Adyen into the Dynamics general ledger. Adyen is treated as a read-only accounting source, so ml-connector does not write payment instructions or financial entries back into Adyen.

Does Adyen post invoices or purchase orders into Dynamics?

No. Adyen is a payments platform and has no native invoice, purchase order, or vendor objects. What it provides is payment, refund, payout, dispute, and reconciliation report data, and ml-connector maps that activity into the Dynamics general ledger as journal lines through journal entities rather than as accounts payable documents.

How does the integration handle Adyen webhooks and posted entries being read-only in Dynamics?

Adyen webhooks are verified by HMAC-SHA256 before processing, and pspReference is used as a dedupe key because Adyen may send the same notification more than once. Posted ledger entries in Dynamics cannot be written directly, so ml-connector creates postings through journal entities such as VendorPaymentJournalLines or CustomerPaymentJournalLines, with the financial dimensions and dataAreaId fully specified.