IFS Cloud and Adyen integration

What moves between them

Payment events flow from Adyen into IFS Cloud. When Adyen processes a payment capture, refund, or cancellation, it sends a webhook notification with the transaction details and settlement amount. ml-connector receives the notification, validates the HMAC-SHA256 signature, then posts a GL voucher and payment proposal into IFS Cloud's general ledger, allocated to the company code and GL account you have configured. Disputes and chargebacks flow the same direction. Reference data such as GL account mappings and company codes are configured once per customer. The integration is one-way (Adyen to IFS Cloud), since IFS Cloud payment proposals cannot update Adyen transactions directly.

How ml-connector handles it

ml-connector stores the Adyen API Key and IFS Cloud OAuth2 client credentials encrypted and rotates the IFS Cloud bearer token when it expires. It listens for incoming Adyen webhook notifications on a configured endpoint, validates each message signature using the Adyen HMAC-SHA256 algorithm with your merchant key, and parses the payment event. For each event, ml-connector queries IFS Cloud with OAuth2 to resolve the company code and GL account from your configuration, then creates a GL voucher (VoucherSet) and payment proposal (PaymentProposalHandling) via OData PATCH with the required ETag header. If IFS Cloud returns a 429 rate-limit response, ml-connector backs off exponentially and retries. Each payment event is logged to an audit trail with the Adyen event ID, so duplicate or out-of-order webhooks can be detected and handled idempotently. If a webhook arrives for an already-recorded transaction, ml-connector skips the duplicate and logs it as such.

A real-world example

A mid-market e-commerce company runs IFS Cloud for inventory, order fulfillment, and finance. Adyen processes customer payments across web, mobile, and point-of-sale channels. Before the integration, after each payment batch settled, the finance team exported Adyen settlement reports, manually matched transactions to IFS sales orders, and re-entered the net settlement amounts into the general ledger by hand. Reconciliation and month-end close involved chasing discrepancies between Adyen statements and the payment accounts in IFS. With IFS Cloud and Adyen connected, each payment capture, refund, and dispute automatically posts into the appropriate GL account and payment proposal in real time. Month-end close begins with the AR and sales accounts already reconciled to Adyen settlement, and the manual re-keying step is gone.

What you can do

• •Post Adyen payment captures, refunds, and cancellations into IFS Cloud GL vouchers and payment proposals, allocated to your company code and GL account.
• •Validate Adyen webhook signatures using HMAC-SHA256 and the merchant notification key to ensure authentic payment events.
• •Handle Adyen rate limits and transient failures with exponential backoff and retry, and detect duplicate events by Adyen transaction ID.
• •Authenticate IFS Cloud with OAuth 2.0 client credentials and rotate bearer tokens automatically when they expire.
• •Maintain a full audit trail of every payment transaction posted to IFS Cloud, including the Adyen event ID, timestamp, and settlement amount.

Questions

Which direction does data move between IFS Cloud and Adyen?

Payment events flow from Adyen into IFS Cloud only. Adyen sends payment captures, refunds, cancellations, and disputes to ml-connector via webhooks. ml-connector posts these transactions as GL vouchers and payment proposals in IFS Cloud. Adyen transactions cannot be updated from IFS Cloud, and IFS Cloud payment proposals do not push back to Adyen.

How does ml-connector validate Adyen webhooks and prevent duplicate payments from posting?

ml-connector uses HMAC-SHA256 with your Adyen merchant notification key to validate every incoming webhook signature and reject unsigned or tampered messages. It tracks the Adyen event ID and transaction reference, so if the same payment event arrives twice (due to Adyen retry), it is logged as a duplicate and skipped rather than posted twice.

How does the integration handle IFS Cloud's OAuth 2.0 token expiry and rate limits?

ml-connector caches the IFS Cloud bearer token and refreshes it when it approaches expiry or when a request returns 401 Unauthorized. If IFS Cloud returns a 429 rate limit response, ml-connector backs off with exponential jitter and retries, up to a maximum number of attempts. Failures are logged to the audit trail and can trigger an alert.