ml-connector
QADAdyen

QAD and Adyen integration

QAD runs manufacturing and finance. Adyen processes payments, refunds, and payouts. Connecting the two brings settled card and payment activity into the general ledger without re-keying. After each Adyen settlement, the captured amounts, refunds, processing fees, and chargebacks post into QAD against the correct GL accounts and cost centers. ml-connector handles the very different APIs on each side and reconciles payment activity to the ledger on the cadence you set.

How QAD works

QAD Adaptive ERP exposes suppliers, purchase orders, supplier invoices, GL accounts, cost centers, items, goods receipts, and AP payments through REST business document APIs, documented in Swagger inside each customer instance. The cloud product authenticates with a JWT session or OAuth2 bearer token against a tenant-specific URL, so there is no shared hostname. Older on-premise sites run QAD Enterprise Edition with the QXtend SOAP framework instead. QAD has no public webhook system for cloud connectors, so finance records are read by polling.

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 source for accounting, since there is no batch pull API for historical transactions.

What moves between them

The flow runs from Adyen into QAD. ml-connector consumes Adyen settlement and reconciliation reports and posts the resulting journals into QAD's general ledger: captured payments, refunds, processing fees, and chargebacks, each mapped to the matching QAD GL account and cost center. 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 and sends the Adyen X-API-Key on every request, switching to the merchant-specific live URL prefix when the environment is live. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base URL, and validates entity paths against that instance. Adyen webhooks arrive signed with HMAC-SHA256, so each notification is verified before processing and the pspReference is used as an idempotency 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 QAD GL accounts and cost centers, which are aligned first so every journal line lands on a valid dimension. Because QAD cloud is pull-only, QAD itself is polled on a schedule rather than pushed to. Adyen rate limits return a too-many-requests error, so ml-connector backs off and retries, and every record carries a full audit trail and can be replayed if a QAD post fails.

A real-world example

A mid-sized direct-to-consumer manufacturer sells finished goods through its own online store and uses QAD Adaptive ERP for production, inventory, and finance, with Adyen as the payment processor at checkout. Before the integration, the finance team downloaded Adyen settlement reports each day and manually entered the gross sales, refunds, and processing fees into QAD, then spent month-end close reconciling the bank deposit against the orders it was supposed to cover. With QAD and Adyen connected, each settlement report posts into QAD automatically, split into the right GL accounts and cost centers, so the payment 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 QAD's general ledger after every payout.
  • Record captured payments, refunds, processing fees, and chargebacks against the correct QAD GL accounts and cost centers.
  • 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 QAD with its tenant-specific token.
  • Poll QAD on a schedule with retries and a full audit trail on every record, because QAD cloud cannot be pushed to.

Questions

Which direction does data move between QAD and Adyen?
The flow is Adyen into QAD. Settlement reports, captures, refunds, fees, and chargebacks move from Adyen into QAD's 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 QAD?
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 QAD's general ledger as journal lines rather than as AP documents.
How does the integration handle Adyen webhooks and QAD's lack of webhooks?
Adyen pushes signed HMAC-SHA256 notifications such as CAPTURE, REFUND, and REPORT_AVAILABLE, which ml-connector verifies and deduplicates by pspReference before posting to QAD. Because QAD cloud is pull-only with no webhook system, QAD is read by polling on a schedule you control, and a scheduled pass backfills anything a webhook missed.

Related integrations

Connect QAD and Adyen

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

Get started