ml-connector
QADGoCardless

QAD and GoCardless integration

QAD runs manufacturing, sales, and finance. GoCardless collects bank debit payments from customers and pays the settled funds out to your account. Connecting the two keeps your accounts receivable in QAD in step with what GoCardless actually collected. When a direct debit payment confirms in GoCardless, the receipt is recorded against the right customer in QAD, and when a payout lands, its individual items are matched back to the bank account in the ledger. ml-connector handles the very different APIs on each side and turns GoCardless webhook events into QAD finance records.

How QAD works

QAD Adaptive ERP exposes customers, suppliers, supplier invoices, GL accounts, cost centers, items, and goods receipts 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 and no public sandbox. Older on-premise sites run QAD Enterprise Edition with the QXtend SOAP framework instead. QAD has no native webhook system for cloud connectors, so its finance records are read by polling and its receipts are posted by write calls.

How GoCardless works

GoCardless exposes customers, customer bank accounts, mandates, payments, subscriptions, payouts, payout items, refunds, and an event log through its REST Payments API over HTTPS, with all bodies in JSON. Every call uses a Bearer access token plus a pinned GoCardless-Version header, and list endpoints use cursor pagination with a 5000 requests per hour account limit. GoCardless pushes real-time webhook events, batched up to 250 per request and signed with HMAC-SHA256 in the Webhook-Signature header, which is the intended path rather than polling the event log. Payouts and events are read-only; GoCardless creates them automatically.

What moves between them

The main flow runs from GoCardless into QAD. As payments move through their lifecycle, GoCardless sends webhook events, and ml-connector records each confirmed and paid out collection against the matching customer receivable in QAD. When a payout settles, its payout items are enumerated and reconciled against the bank GL account so the deposit ties out to the underlying payments, fees, refunds, and chargebacks. In the other direction, QAD customers can be pushed into GoCardless to create the customer and supporting records needed before a mandate is set up. Payouts and the event log are read-only in GoCardless, so ml-connector never writes settlement records back to the processor.

How ml-connector handles it

ml-connector stores both credential sets encrypted, sends the GoCardless Bearer access token and the GoCardless-Version header on every request, and verifies each incoming webhook by computing HMAC-SHA256 over the raw request body and comparing it to the Webhook-Signature header, returning 401 rather than 200 on a mismatch so GoCardless keeps retrying. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base address, and validates entity paths against that instance. GoCardless amounts arrive as integers in the smallest currency unit, so pence and cents are converted to the decimal values QAD expects, and the currency on each payment is mapped to the matching QAD account. Because GoCardless settles in batches, payout reconciliation reads payout items, which can be archived after six months, so settlements are recorded promptly. POST calls to GoCardless carry an Idempotency-Key, and creating a payment requires an existing active mandate, so customer and mandate setup runs before any collection. Rate limit responses of 429 trigger backoff and retry, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized subscription manufacturer ships consumable equipment to trade customers on monthly bank debit plans and runs QAD Adaptive ERP for orders, inventory, and finance. Before the integration, the finance team downloaded GoCardless payment and payout reports, then manually marked customer invoices as paid in QAD and tried to tie each lump-sum payout back to the dozens of payments inside it, which made cash application slow and left receivables open longer than they should be. With QAD and GoCardless connected, each confirmed collection is applied to the right customer automatically, and every payout is broken into its items and reconciled against the bank account. The receivables ledger reflects real collections within the day, and the payout matching step is gone.

What you can do

  • Record confirmed GoCardless bank debit collections against the matching customer receivable in QAD as payment webhooks arrive.
  • Reconcile each GoCardless payout against the bank GL account by enumerating its payout items, including fees, refunds, and chargebacks.
  • Push QAD customers into GoCardless to create the records needed before a direct debit mandate is set up.
  • Verify GoCardless webhook signatures with HMAC-SHA256 and authenticate QAD with its tenant-specific token.
  • Convert GoCardless integer amounts to QAD decimal values, with retries, idempotency keys, and a full audit trail on every record.

Questions

Which direction does data move between QAD and GoCardless?
The main flow is GoCardless into QAD. Confirmed payments and settled payouts move from GoCardless into QAD to apply customer receipts and reconcile deposits, while QAD customers can be pushed into GoCardless to support mandate setup. Payouts and the GoCardless event log are read-only, so ml-connector does not write settlement records back to the processor.
Does the integration poll GoCardless or use webhooks?
It uses webhooks, which is the intended path for GoCardless. GoCardless pushes signed events, batched up to 250 per request, and ml-connector verifies the HMAC-SHA256 signature on the raw body before recording anything. Because QAD cloud has no native webhooks, ml-connector posts receipts into QAD with write calls and accepts the tenant-specific QAD URL per customer.
How are GoCardless payouts matched to individual payments in QAD?
GoCardless settles many payments together in one payout, so ml-connector reads the payout items for each payout to break it down into the underlying payments, fees, refunds, and chargebacks. Those items are reconciled against the bank GL account in QAD so the deposit ties out. Payout items can be archived after six months, so reconciliation runs promptly after each payout settles.

Related integrations

Connect QAD and GoCardless

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

Get started