Infor CloudSuite and Adyen integration

What moves between them

The flow runs from Adyen into Infor CloudSuite. ml-connector consumes Adyen settlement and reconciliation reports and posts the resulting journals into Infor CloudSuite general ledger: captured payments, refunds, processing fees, and chargebacks, each mapped to the matching Infor accounting string and company. Capture, refund, and REPORT_AVAILABLE webhooks trigger the work as soon as activity settles, and a scheduled poll 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. On the Adyen side it sends the X-API-Key header on every request and adds the merchant live URL prefix for production calls. On the Infor side it accepts the full .ionapi field set per customer, runs the OAuth 2.0 password grant to get a bearer token, and refreshes that token before its one to twenty-four hour lifetime expires rather than reacting to a 401. Adyen webhooks are verified with HMAC-SHA256 before anything is processed, and because Adyen can deliver the same notification more than once, ml-connector dedupes on pspReference. On a REPORT_AVAILABLE event it downloads the settlement report from the signed URL, parses the lines, and maps each to an Infor accounting string and company before posting. Infor has no native idempotency key and M3 Add transactions are not idempotent, so ml-connector queries first and tracks a pspReference to Infor record mapping to avoid duplicate journals. Accounting strings and company codes are mapped first so every posted line references values that already exist in Infor. Infor returns HTTP 429 under gateway throttling, so ml-connector backs off and retries, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized direct-to-consumer retailer runs Infor CloudSuite for finance and distribution and takes online and card payments through Adyen across a web store and several pop-up locations. Before the integration, the finance team downloaded Adyen settlement reports each cycle and hand-entered settled totals, refunds, and processing fees into the Infor general ledger, then spent the first days of month-end close chasing differences between the payment platform and the ledger. With Infor CloudSuite and Adyen connected, each settlement report flows into Infor automatically, allocated to the right accounting string and company, and webhooks post captures and refunds as they settle. Month-end close starts with the payment accounts already reconciled, and the manual re-keying step is gone.

What you can do

• •Post Adyen settlement journals into Infor CloudSuite general ledger after each settlement, mapped to the correct accounting strings.
• •Bring captures, refunds, processing fees, and chargebacks into the ledger from Adyen reconciliation reports.
• •Verify HMAC-SHA256 Adyen webhooks and dedupe on pspReference so a repeated notification never double-posts.
• •Authenticate Adyen with its API key and Infor CloudSuite with the ION OAuth 2.0 password grant, refreshing tokens before expiry.
• •Trigger on capture, refund, and report-available webhooks, with a scheduled poll backfill, retries, and a full audit trail.

Questions

Which direction does data move between Infor CloudSuite and Adyen?

The flow is one way, from Adyen into Infor CloudSuite. Settlement and reconciliation data, captures, refunds, fees, and chargebacks move from Adyen into the Infor general ledger. Adyen is a read-only accounting source here, so ml-connector never writes payment instructions or financial entries back into Adyen.

How does ml-connector get accounting data out of Adyen if there is no batch pull API?

Adyen has no batch API for historical transactions, so reconciliation reports are the canonical accounting source. ml-connector subscribes to the REPORT_AVAILABLE webhook, downloads the settlement report from the signed URL it provides, and parses the lines. A scheduled poll backfills any report a webhook missed.

How does the integration handle Infor's lack of webhooks and idempotency?

Infor CloudSuite has no self-service webhooks, so ml-connector reads and posts on a schedule through the ION API Gateway and refreshes the OAuth bearer token before it expires. Because Infor has no idempotency key and M3 Add transactions are not idempotent, it queries first and keeps a pspReference to Infor record mapping so a journal is never posted twice.