Sage 100 and GoCardless integration

What moves between them

The main flow is bidirectional. ml-connector polls Sage 100 AR invoices and customers, and subscribes to GoCardless payment and refund events via webhook. When a GoCardless payment arrives, ml-connector matches it to the customer and invoice in Sage 100, retrieves the full payment detail from GoCardless, and writes a reconciliation record into Sage 100's AR module to mark the invoice as collected. Customer data flows the opposite direction so GoCardless payment records match the Sage 100 customer master. Payouts from GoCardless are read-only, so ml-connector never writes payment records back to the payment processor.

How ml-connector handles it

ml-connector handles the very different transport layers on each side. For Sage 100, it forwards SOAP calls (username and password per request, no tokens) to the customer's on-premises SOAP endpoint or local agent, and includes the 3-character company code in every call. For GoCardless, it stores the bearer token encrypted, validates webhook signatures using HMAC-SHA256 against the registered secret, and verifies that only whitelisted event types are processed. On the Sage 100 side, AR invoices are polled by DateLastUpdated, and when a payment event arrives from GoCardless, ml-connector queries Sage 100 for the matching customer and invoice, then creates a reconciliation record using BOI via the agent. GoCardless payment amounts are in smallest currency units (pence/cents), so ml-connector converts them to Sage 100's invoice currency before matching. If a payment fails to match (customer not found, amount mismatch, or invoice already collected), it is logged and held for manual review. Retries use exponential backoff on both SOAP timeouts and webhook delivery failures.

A real-world example

A mid-sized B2B services company uses Sage 100 for invoicing and AR. They bill recurring customers monthly, and those customers authorize bank debit mandates with GoCardless for payment. Before the integration, the finance team received payment notifications from GoCardless, looked up the invoice in Sage 100 by customer and amount, and manually posted a collection record. Reconciliation at month-end took two days of chasing mismatches. With Sage 100 and GoCardless connected, each payment triggers an immediate match to the invoice in Sage 100, and a collection record is posted automatically. Reconciliation now takes hours and the team has visibility into failed collections in real time.

What you can do

• •Poll Sage 100 AR invoices and match incoming GoCardless payments to the correct customer and invoice.
• •Validate GoCardless webhook signatures using HMAC-SHA256 and process payment events in real time.
• •Write reconciliation records into Sage 100 to mark invoices as collected without manual lookup.
• •Handle SOAP authentication on Sage 100 and bearer token auth on GoCardless, including a local Windows agent for BOI access.
• •Log mismatched payments and hold them for manual review, with a full audit trail of every match and payment.

Questions

Can ml-connector access Sage 100 remotely if it is on-premises?

Sage 100 SOAP Web Services are hosted on the customer's on-premises server, so the connection is HTTP(S) from ml-connector to the customer's internal SOAP endpoint. For full AP, GL, and AR access via BOI, a local Windows agent running on the customer's Sage 100 server bridges the connection. ml-connector communicates with the agent over the network; the agent accesses BOI locally.

How does GoCardless webhook verification work and what happens if it fails?

GoCardless sends payment events as POST requests to a registered HTTPS endpoint, each batch signed with HMAC-SHA256 (computed using the webhook secret and the raw request body). ml-connector computes the same hash and compares it to the Webhook-Signature header. If the signature is invalid, ml-connector returns 401 and GoCardless retries the delivery; returning 200 on a bad signature tells GoCardless the endpoint is healthy and it stops retrying.

What happens if a GoCardless payment does not match any Sage 100 invoice?

ml-connector logs the unmatched payment with the customer ID, amount, and payment reference, and holds it in a queue for manual review. This can happen if the customer is not in Sage 100, the invoice was already collected, or the amount does not align exactly (GoCardless amounts are in smallest currency units). The operator can then reconcile the payment manually or update customer records and retry.