IFS Cloud and GoCardless integration

What moves between them

AR invoices flow from IFS Cloud to GoCardless. ml-connector polls IFS Cloud for customer order invoices marked as ready for collection, maps them to GoCardless customers and their registered bank accounts, and initiates one-off bank debit payments. Payment success and failure events come back from GoCardless via webhooks, and ml-connector posts the results back into IFS Cloud's AR or payment proposal system for automatic matching. Customer records and active mandates are aligned in both directions so new customers in IFS Cloud are registered in GoCardless and mandate changes are reflected.

How ml-connector handles it

ml-connector stores IFS Cloud OAuth 2.0 credentials (client_id and client_secret) encrypted and retrieves bearer tokens on a 60-minute refresh cycle. It also stores the GoCardless bearer token encrypted and presents both tokens as Authorization headers on each API call. When polling IFS Cloud, it uses OData filters on modified timestamps to detect changed invoices, and reads the ETag header on each response so mutations (if needed) carry the required If-Match concurrency header. Before posting to GoCardless, ml-connector converts invoice amounts from IFS Cloud's decimal form to GoCardless's integer format (smallest currency unit) and validates the customer and bank account exist in GoCardless. Payment webhook events from GoCardless are HMAC-SHA256 verified against the webhook secret before processing. If a GoCardless call returns HTTP 429 (rate limit), ml-connector backs off exponentially and retries. The integration tracks payment state in an audit log so failed collections can be replayed or escalated.

A real-world example

A mid-sized European logistics company runs IFS Cloud for order management, invoicing, and finance across three countries with different company codes. They use GoCardless for direct bank debit collections from their B2B customers to reduce DSO and chasing work. Before the integration, the AR team exported invoices from IFS Cloud weekly, manually entered customer bank account details and payment amounts into GoCardless, and then manually matched payment confirmations back to the IFS Cloud AR ledger. With IFS Cloud and GoCardless connected, eligible invoices flow automatically to GoCardless, payments are collected on the scheduled day, and success or failure is posted back into IFS Cloud's payment proposals for month-end reconciliation. The manual data entry and matching step is eliminated.

What you can do

• •Poll IFS Cloud for AR invoices ready for collection and automatically set up bank debit payments in GoCardless.
• •Map IFS Cloud customers and company codes to GoCardless customer records and registered bank accounts.
• •Convert invoice amounts to GoCardless's integer format and validate each payment before collection.
• •Verify GoCardless webhook signatures and post payment success or failure back into IFS Cloud AR for automatic reconciliation.
• •Handle OData ETag concurrency headers, OAuth 2.0 token refresh, rate limit backoff, and a full audit trail on every record.

Questions

How does the integration handle different company codes in IFS Cloud?

IFS Cloud requires a company code on almost every financial entity. ml-connector accepts one or more company codes during setup and filters OData queries to only pull invoices from those codes. Each code maps to a GoCardless creditor or sub-account, so payments are collected under the right merchant identity.

Does the integration support multi-currency payments?

Yes. Both IFS Cloud and GoCardless support multi-currency. ml-connector reads the invoice currency from IFS Cloud, validates that GoCardless can collect in that currency in the customer's country, converts the amount to the smallest currency unit (pence, cents, etc.), and initiates collection. Currency mismatches are flagged in the audit log.

What happens if a GoCardless payment fails?

ml-connector receives a failure event via GoCardless webhook (verified by HMAC-SHA256), logs it with the reason code, and posts the failure back into IFS Cloud's payment proposal or AR module. The invoice remains open in IFS Cloud and can be retried, escalated, or handled manually based on the failure reason.