Sage 300 and GoCardless integration

What moves between them

The main flow moves from GoCardless into Sage 300 AR. Customer mandates and bank account details from GoCardless sync into Sage 300 AR customers on a scheduled poll, so the mandate status is always current. Sage 300 AR invoices flow the opposite direction into GoCardless to initiate payments, either one-off or recurring via subscriptions. Payouts and reconciliation flow back from GoCardless into Sage 300's general ledger, allocated to the AR account for matching. Webhook events from GoCardless trigger near-real-time updates when subscriptions start, payments clear, or refunds are issued.

How ml-connector handles it

ml-connector stores both credential sets encrypted: Sage 300 HTTP Basic Auth (uppercase username and password, with the API user validated in Sage 300 first) and GoCardless bearer token. For Sage 300 reads it polls on a schedule via OData filters on mandate creation and update dates; for writes it POSTs new AR invoices as Open invoices ready for manual or automatic payment routing. For GoCardless, ml-connector registers a webhook endpoint and verifies every inbound request by computing HMAC-SHA256(webhook_secret, raw_body) against the Webhook-Signature header, returning 2xx only on match so GoCardless does not mark the endpoint healthy on bad signatures. When GoCardless returns a payout, ml-connector reads the payout items and posts them as a general ledger journal batch in Sage 300, allocated to the AR control account. Mandates and subscriptions are mapped first, so every payment flows from a valid mandate and every payout reconciles to the matching AR invoice. Every record carries a full audit trail and failed payments can be retried.

A real-world example

A mid-sized professional services firm uses Sage 300 for billing and finance, and collects retainers and project invoices from customers across Europe. Before the integration, the billing team exported customer bank account details from client emails and forms, manually keyed them into Sage 300 AR customer records, then initiated payments in GoCardless by hand. Reconciling payouts required exporting payout reports from GoCardless and matching them by hand to AR invoices before posting to the GL. With Sage 300 and GoCardless connected, customer mandates sync automatically from GoCardless into AR each week, AR invoices flow to GoCardless for collection on the due date, and payouts post into the GL instantly, leaving the reconciliation fully automated.

What you can do

• •Sync customer bank account mandates from GoCardless into Sage 300 AR customers on a scheduled poll, keeping mandate status always current.
• •Initiate one-off and recurring bank debit payments from Sage 300 AR invoices via GoCardless without re-keying payment details.
• •Verify webhook signatures from GoCardless using HMAC-SHA256 and process mandate, payment, and refund events in near-real-time.
• •Reconcile GoCardless payouts into Sage 300's general ledger as journal batches, allocated to the AR control account for automated matching.
• •Authenticate Sage 300 with HTTP Basic Auth and GoCardless with bearer token, with a full audit trail on every record.

Questions

Which direction does data move between Sage 300 and GoCardless?

Data flows both directions. Customer mandates and bank accounts move from GoCardless into Sage 300 AR to keep records current. Sage 300 AR invoices are sent to GoCardless to initiate collection. Payouts from GoCardless post back into Sage 300's general ledger for reconciliation.

How does ml-connector verify GoCardless webhook signatures and what happens if verification fails?

ml-connector computes HMAC-SHA256(webhook_secret, raw_body) and compares it to the Webhook-Signature header on every inbound request. If the signature does not match, ml-connector returns an error response so GoCardless knows to retry, preventing it from marking the endpoint as healthy and stopping retries.

Why does Sage 300 require uppercase username and password, and what does ml-connector do about it?

Sage 300's HTTP Basic Auth API enforces uppercase credentials as a security constraint. ml-connector stores credentials encrypted and converts the username and password to uppercase before base64-encoding them in the Authorization header on every request.