Oracle Fusion Cloud ERP and GoCardless integration

What moves between them

Oracle Fusion invoices and customer records flow into GoCardless as billing requests and customers, setting up the data for collection. Customer bank account mandates in GoCardless are polled regularly and synced back into Oracle Fusion customer records to track payment authorization status. After each collection, GoCardless payments and reconciled payouts are polled and posted into Oracle Fusion subledger as receivables receipts and cash posting, with the payout amount matched to the collection mandates. The flow runs on a daily or weekly schedule tied to your billing calendar, and ml-connector can also receive GoCardless webhook events in real time where registered.

How ml-connector handles it

ml-connector stores both OAuth 2.0 and bearer token credentials encrypted, refreshing the Oracle Fusion JWT after expiry and maintaining the GoCardless bearer token in cache. On the Oracle side, it polls invoices and customers using OData query filters on LastUpdateDate to catch only recent changes, then maps customer records to GoCardless customer format and Oracle Fusion invoices to GoCardless billing requests. On the GoCardless side, it accepts webhooks for real-time payment events and validates each webhook's HMAC-SHA256 signature against the shared secret; it also polls /events and /payouts to catch any webhook misses. Payment amounts are converted to the smallest currency unit (pence, cents) as GoCardless requires. Oracle Fusion journal batches are created from GoCardless payout data, mapped to the correct AR account and cash account per Oracle setup, and posted to the GL. The integration tracks mandate creation dates and payout item status to detect reconciliation issues and can replay failed postings if an Oracle GL call fails.

A real-world example

A mid-sized SaaS company runs Oracle Fusion Cloud ERP for complete financial management across receivables, cash, and the general ledger, and uses GoCardless for recurring subscription billing across European customers. Before the integration, the billing team exported unpaid invoices from Oracle each week, manually created billing requests in GoCardless, and then spent hours each month matching GoCardless payouts back to Oracle customer records and posting the cash receipts. With Oracle Fusion and GoCardless connected, each new Oracle invoice is automatically set up for collection the next day, customer mandate status flows back to Oracle, and every GoCardless payout automatically posts into the Oracle subledger as a cash receipt. Month-end close now starts with receivables and cash already reconciled, and the manual billing and cash-posting steps are gone.

What you can do

• •Sync Oracle Fusion invoices and customers into GoCardless as billing requests and customers, ready for collection.
• •Capture customer bank account mandates from GoCardless and update mandate status in Oracle Fusion.
• •Post GoCardless payments and payouts into Oracle Fusion subledger and GL, mapped to the correct AR and cash accounts.
• •Bridge OAuth 2.0 (Oracle) and bearer token (GoCardless) authentication with encrypted credential storage and automatic token refresh.
• •Poll on a weekly or daily schedule with webhook event support, HMAC-SHA256 signature verification, and a full audit trail on every record.

Questions

Which direction does data move between Oracle Fusion and GoCardless?

Oracle Fusion invoices and customers flow into GoCardless to set up collections. Customer mandate status flows back from GoCardless to Oracle. GoCardless payments and payouts are polled and posted into Oracle Fusion subledger and GL as cash receipts and AR postings. The flow is bidirectional for reference data (customers, mandates) and unidirectional for transactional records (invoices to billing requests, payments to GL postings).

How does ml-connector handle GoCardless webhook signature verification?

GoCardless sends webhook events with an HMAC-SHA256 signature in the Webhook-Signature header, computed over the raw request body with a shared secret. ml-connector validates the signature on every incoming webhook, rejecting any with an invalid signature and returning 2xx only on a valid match. This prevents processing forged or corrupted events and ensures GoCardless marks the endpoint healthy.

What happens if Oracle Fusion and GoCardless use different customer or invoice identifiers?

ml-connector maintains a mapping table linking Oracle Fusion customer IDs and invoice IDs to their GoCardless equivalents (customer ID, billing request ID). New customers and invoices in Oracle are mapped on first sync, and the mapping is stored encrypted for lookup on subsequent syncs. If an identifier changes in either system, ml-connector detects the change and updates the mapping.