Oracle PeopleSoft and GoCardless integration

What moves between them

The main flow runs from GoCardless into Oracle PeopleSoft. When GoCardless collects a payment or records a refund, ml-connector receives the event via webhook, verifies the HMAC signature, and posts a payment record into Oracle PeopleSoft's customer account and AR subledger, mapped to the matching customer and GL account. Customer master records such as bank account status and mandate information sync from GoCardless into Oracle PeopleSoft so that AR teams can see which customers are active in the payment plan. Reference data such as customer names and payment terms flow both directions, ensuring Oracle PeopleSoft and GoCardless are aligned on collection status and customer creditworthiness.

How ml-connector handles it

ml-connector stores the GoCardless bearer token and Oracle PeopleSoft OAuth2 credentials or basic auth password encrypted and presents them on each request. On the GoCardless side it listens for webhooks at a registered HTTPS endpoint, verifies every incoming webhook signature with HMAC-SHA256 using the webhook signing secret, and discards unsigned or tampered events. On the Oracle PeopleSoft side it accepts the unique hostname and port for the customer's PeopleSoft instance, since there is no shared base URL, and authenticates with either HTTP Basic Auth or OAuth2 depending on the customer's PeopleTools version. Because Oracle PeopleSoft does not push outbound events, ml-connector also polls for new customer and payment data on a schedule, filtered by date ranges to stay within rate limits and avoid re-processing. GoCardless events carry globally unique IDs, so ml-connector tracks processed webhook event IDs to avoid re-posting duplicate payments. Payment amounts are converted from GoCardless's integer smallest-currency-unit format to the decimal GL format Oracle PeopleSoft expects. Every payment record and customer sync carries a full audit trail.

A real-world example

A mid-sized SaaS company runs Oracle PeopleSoft on-premise for general ledger, AP, AR, and customer master, and uses GoCardless to collect recurring subscription payments and one-off customer invoices across Europe and North America. Before the integration, the accounting team received daily reports from GoCardless, manually matched payments to customer records in Oracle PeopleSoft, and posted each one by hand in the AR module. Collections reconciliation took days each month, and discrepancies between GoCardless collection logs and Oracle PeopleSoft customer balances required manual investigation. With Oracle PeopleSoft and GoCardless connected, each payment GoCardless collects flows directly into the matching customer account and GL posting in Oracle PeopleSoft, reconciled automatically. The AR aging report reflects current collections status immediately, and month-end close starts with AR already reconciled.

What you can do

• •Receive payment and refund events from GoCardless in real-time via webhooks and verify HMAC-SHA256 signatures.
• •Post verified GoCardless payments into Oracle PeopleSoft customer accounts and AR subledger, mapped to the correct GL accounts.
• •Sync customer master records and mandate status from GoCardless into Oracle PeopleSoft to keep collection terms and customer creditworthiness current.
• •Authenticate GoCardless with bearer tokens and Oracle PeopleSoft with OAuth2 or HTTP Basic Auth, adapting to each customer's PeopleTools version.
• •Track processed webhook event IDs to prevent duplicate payments and maintain a full audit trail on every record.

Questions

Which direction does data flow between Oracle PeopleSoft and GoCardless?

The main flow is GoCardless into Oracle PeopleSoft. Payments, refunds, and customer mandate status move from GoCardless into Oracle PeopleSoft's AR module and customer master. Customer names, payment terms, and credit limits sync both directions to keep both systems aligned on collection eligibility and customer status.

How does the integration handle Oracle PeopleSoft's unique hostnames and lack of webhooks?

ml-connector accepts the unique hostname and port for each customer's Oracle PeopleSoft instance, since there is no shared base URL. Because Oracle PeopleSoft does not offer outbound webhooks, ml-connector listens for GoCardless webhook events and polls Oracle PeopleSoft on a schedule filtered by date ranges, so new payments are captured and posted without re-processing old data.

What happens if a GoCardless webhook arrives with a bad signature?

ml-connector verifies every webhook with HMAC-SHA256 and rejects unsigned or tampered events without posting them to Oracle PeopleSoft. This ensures that only authentic GoCardless payment events update your AR records. A rejected webhook is logged for audit and investigation by your support team.