How does ml-connector handle Oracle JD Edwards session tokens that expire every 30 to 60 minutes?

ml-connector maintains a persistent connection to the JD Edwards AIS Server and refreshes the session token every 50 minutes, well before the default expiry. If a request returns HTTP 444 (invalid token) or the AIS Server restarts and invalidates all sessions, ml-connector re-authenticates immediately using the stored username and password, ensuring no collections are missed mid-cycle.

What happens if a GoCardless webhook signature validation fails?

ml-connector computes HMAC-SHA256 using the webhook secret and raw request body, then compares it to the Webhook-Signature header. If the signatures do not match, the webhook is rejected immediately without processing, preventing fraudulent or corrupted payment events from posting to AR. Only validated events are applied.

Which direction do payments and invoices flow between Oracle JD Edwards and GoCardless?

Invoices and customers flow from JD Edwards to GoCardless so mandates can be registered and collections triggered. Payment receipts and mandate status flow back from GoCardless to JD Edwards via webhooks, where they are matched to open invoices and posted to the AR ledger. Refunds initiated in JD Edwards are sent to GoCardless to adjust customer balances.

Oracle JD EdwardsGoCardless

Oracle JD Edwards and GoCardless integration

Oracle JD Edwards runs your enterprise financials. GoCardless collects recurring payments directly from customer bank accounts. Connecting the two automates AR collections: new customers and open invoices in JD Edwards flow to GoCardless, payment mandates are registered without manual setup, recurring collections run on schedule, and payment receipts post back into JD Edwards AR ledger to close the invoice. Your AR team stops re-keying payment collections and month-end reconciliation moves faster.

How Oracle JD Edwards works

Oracle JD Edwards EnterpriseOne is deployed on customer infrastructure and exposes accounts receivable, customer master, and item data through REST APIs via Application Interface Services (AIS) Server at a customer-provided hostname. Authentication uses a session token obtained with username and password, valid for 30 to 60 minutes, passed in the jde-AIS-Auth header on all requests. JD Edwards has no native outbound webhooks, so data is read by polling with a date-updated filter. Key tables include F03012 (Customer Master), F0401 (open AR invoices via AR detail), F0101 (Address Book with payment terms and bank routing), and F0911 (AR ledger for posting collections received). Pagination uses maxPageSize parameter with a moreRecords flag for large result sets.

How GoCardless works

GoCardless is a global bank debit payment processor offering REST APIs at api.gocardless.com with production and sandbox environments. Authentication uses a bearer token from the merchant dashboard in the Authorization header. GoCardless exposes customers, bank account mandates, payment subscriptions, and payouts through REST endpoints and communicates payment events via HTTPS webhooks using HMAC-SHA256 signature verification. All key entities (customers, mandates, payments, payouts) are read-write except payouts, which are read-only and created automatically by GoCardless. Amount fields are integers in smallest currency units. Webhooks deliver events in batches up to 250 events per request.

What moves between them

Open AR customers and invoices flow from JD Edwards to GoCardless daily. For each customer, ml-connector creates or updates a GoCardless customer record and registers a bank account mandate if one does not exist. Payment subscriptions are created based on invoice due dates and customer payment terms. As GoCardless collects payments, webhook events are received and matched to JD Edwards invoices, creating cash receipt records in the F0911 AR ledger and marking invoices as paid. Refunds initiated in JD Edwards flow to GoCardless to adjust open mandates. Payment state and mandate status are tracked in both directions, with GoCardless as the system of record for collection status.

How ml-connector handles it

ml-connector maintains two persistent connections: one to the JD Edwards AIS Server with automatic session token refresh every 50 minutes (well before the 30 to 60 minute default expiry), and one to GoCardless with a static bearer token. On each poll cycle, it queries F03012 and open AR by updated date, maps customer email and address to GoCardless customer_bank_accounts schema, and registers mandates with the payer's bank and sort code from F0101. Webhook events from GoCardless are validated with HMAC-SHA256 before processing; invalid signatures are rejected immediately. Inbound payment events are parsed, matched to F0911 invoices by external reference ID, and payment entries are created with the correct GL account code for each JD Edwards business unit. Retry logic uses exponential backoff with jitter on HTTP 5xx and rate-limit (429) responses. JD Edwards token invalidation (HTTP 444 or server restart) triggers immediate re-authentication. Every payment and mandate carries an immutable audit trail.

A real-world example

A mid-sized B2B SaaS company invoices customers in multiple countries for recurring software subscriptions. Finance currently exports customer lists from Oracle JD Edwards monthly, uploads them to GoCardless manually, and reconciles payment receipts against AR at month-end. Payment mandates are set up one by one through the GoCardless dashboard, new customers are added late, and invoices sometimes miss their collection cycles. With Oracle JD Edwards and GoCardless connected, each invoice-ready customer in JD Edwards flows to GoCardless automatically with a pre-authorized mandate. Payments are collected on schedule and receipts post to AR immediately. Reconciliation now takes hours instead of days, and the finance team can focus on exceptions rather than data entry.

What you can do

Poll open AR customers and invoices from Oracle JD Edwards daily and register payment mandates in GoCardless.
Create and update GoCardless customer records, bank accounts, and payment subscriptions based on JD Edwards customer master data and invoice due dates.
Receive and validate payment and refund events from GoCardless via HMAC-SHA256-signed webhooks and post matching receipts to the JD Edwards AR ledger.
Refresh JD Edwards session tokens automatically every 50 minutes to prevent timeout mid-batch collection cycles.
Track payment state and mandate status bidirectionally with a full immutable audit trail on every transaction.

Questions

How does ml-connector handle Oracle JD Edwards session tokens that expire every 30 to 60 minutes?: ml-connector maintains a persistent connection to the JD Edwards AIS Server and refreshes the session token every 50 minutes, well before the default expiry. If a request returns HTTP 444 (invalid token) or the AIS Server restarts and invalidates all sessions, ml-connector re-authenticates immediately using the stored username and password, ensuring no collections are missed mid-cycle.
What happens if a GoCardless webhook signature validation fails?: ml-connector computes HMAC-SHA256 using the webhook secret and raw request body, then compares it to the Webhook-Signature header. If the signatures do not match, the webhook is rejected immediately without processing, preventing fraudulent or corrupted payment events from posting to AR. Only validated events are applied.
Which direction do payments and invoices flow between Oracle JD Edwards and GoCardless?: Invoices and customers flow from JD Edwards to GoCardless so mandates can be registered and collections triggered. Payment receipts and mandate status flow back from GoCardless to JD Edwards via webhooks, where they are matched to open invoices and posted to the AR ledger. Refunds initiated in JD Edwards are sent to GoCardless to adjust customer balances.

Connect Oracle JD Edwards and GoCardless

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started