Which direction does data move between Sage 100 and Adyen?

The flow runs one way, from Adyen into Sage 100. Settlement and reconciliation activity becomes journal entries posted into the Sage 100 general ledger. Adyen is a payments platform with no GL of its own, so ml-connector treats it as a read-only accounting source and never writes financial entries or payment instructions back into Adyen.

How does ml-connector reach Sage 100 if it has no cloud API?

Sage 100 is on-premises and cannot be called directly over the internet. A lightweight agent runs on the customer's Sage 100 server and wraps the Business Object Interface, exposing a secured HTTPS endpoint that ml-connector calls. Writing through the Business Object Interface means Sage 100's own posting rules run on every journal entry, rather than bypassing them with a direct database write.

How are duplicate Adyen events handled when posting to Sage 100?

Adyen can deliver the same webhook more than once, and Sage 100 has no built-in idempotency key. ml-connector uses the Adyen pspReference as the unique reference on each Sage 100 journal entry and checks for an existing entry before inserting. That combination keeps a redelivered settlement event from posting the same amount twice.

Sage 100Adyen

Sage 100 and Adyen integration

Sage 100 runs accounting and operations on a server in your building. Adyen processes card and online payments, refunds, and payouts in the cloud. Connecting the two brings settled payment activity into the general ledger without re-keying. After each Adyen settlement, the captured amounts, refunds, and processing fees post into Sage 100 as journal entries against the correct accounts. ml-connector handles the very different surfaces on each side and reconciles payment activity to the ledger on the cadence you set.

How Sage 100 works

Sage 100 is on-premises and has no native cloud API, so ml-connector reaches it through a lightweight local agent installed on the customer's Sage 100 server. That agent wraps the Business Object Interface, the COM layer that exposes the full chart of accounts, GL journal entries, AP vendors and invoices, and AR records with Sage 100's own business rules applied. Authentication is Windows service identity inside the server, with an API key or mutual TLS protecting the agent's HTTPS endpoint. Sage 100 has no webhooks, so records are confirmed by polling the agent on DateLastUpdated and similar fields. GL accounts are segmented strings such as 1000-01-00, and the server URL and company code are unique to each customer.

How Adyen works

Adyen is a payments platform, not an ERP, so it has no native vendor, invoice, purchase order, or GL account objects. It exposes payments, captures, refunds, payouts and transfers, disputes, and reconciliation reports through versioned REST APIs, each with its own base URL. Every call carries an X-API-Key header or Basic auth, scoped to a company or merchant account, and live endpoints require a merchant-specific URL prefix. Adyen pushes events such as AUTHORISATION, CAPTURE, REFUND, CHARGEBACK, and REPORT_AVAILABLE by webhook, signed with HMAC-SHA256. Settlement and reconciliation reports are the canonical accounting source, since there is no batch pull API for historical transactions.

What moves between them

The flow runs from Adyen into Sage 100. ml-connector consumes Adyen settlement and reconciliation reports and posts the resulting journal entries into Sage 100's general ledger through the local agent: captured payments, refunds, and processing fees, each mapped to the matching segmented GL account. CAPTURE, REFUND, and REPORT_AVAILABLE webhooks trigger the work as soon as activity settles, and a scheduled poll of the agent confirms each entry posted and 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 on every call, adds the merchant-specific live URL prefix for production, and verifies the HMAC-SHA256 signature on each webhook before doing any work. On REPORT_AVAILABLE it downloads the settlement report from the signed URL, parses the lines, and turns them into Sage 100 journal entries. Because Sage 100 has no remotely callable API, those entries are written through the local agent, which applies them via the Business Object Interface so Sage 100's own posting rules run. Segmented GL accounts such as 1000-01-00 are mapped first, so every journal line references an account that already exists. Sage 100 offers no idempotency key, so ml-connector uses the Adyen pspReference as the unique reference on each entry and checks before insert to avoid duplicates, which also protects against Adyen redelivering the same webhook. Adyen rate limits return a 429-style error, so it backs off and retries, and record-locking errors from the Sage 100 agent are retried with backoff. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A regional omnichannel retailer with around 120 staff runs Sage 100 on a server in its head office for AP, AR, and the general ledger, and takes card payments online and in store through Adyen. Before the integration, an accountant pulled Adyen settlement reports each week and typed the captured totals, refunds, and processing fees into Sage 100 by hand, then spent the first days of month-end close chasing the difference between the bank deposit and what the ledger showed. With Sage 100 and Adyen connected, each settlement report posts into Sage 100 as a journal entry against the right accounts, with refunds and fees split out. Month-end starts with payments already reconciled, and the manual re-keying step is gone.

What you can do

Post Adyen settlement and reconciliation activity into Sage 100's general ledger as journal entries after every settlement.
Split captured payments, refunds, and processing fees onto the correct segmented Sage 100 GL accounts.
Verify each Adyen webhook with HMAC-SHA256 and download settlement reports from their signed URLs.
Write into Sage 100 through a local agent and the Business Object Interface so its posting rules apply.
Deduplicate on the Adyen pspReference and retry on rate limits and record locks, with a full audit trail on every entry.

Questions

Which direction does data move between Sage 100 and Adyen?: The flow runs one way, from Adyen into Sage 100. Settlement and reconciliation activity becomes journal entries posted into the Sage 100 general ledger. Adyen is a payments platform with no GL of its own, so ml-connector treats it as a read-only accounting source and never writes financial entries or payment instructions back into Adyen.
How does ml-connector reach Sage 100 if it has no cloud API?: Sage 100 is on-premises and cannot be called directly over the internet. A lightweight agent runs on the customer's Sage 100 server and wraps the Business Object Interface, exposing a secured HTTPS endpoint that ml-connector calls. Writing through the Business Object Interface means Sage 100's own posting rules run on every journal entry, rather than bypassing them with a direct database write.
How are duplicate Adyen events handled when posting to Sage 100?: Adyen can deliver the same webhook more than once, and Sage 100 has no built-in idempotency key. ml-connector uses the Adyen pspReference as the unique reference on each Sage 100 journal entry and checks for an existing entry before inserting. That combination keeps a redelivered settlement event from posting the same amount twice.

Connect Sage 100 and Adyen

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started