Oracle JD Edwards and Wise integration

What moves between them

The main flow moves from JD Edwards to Wise. Each polling cycle, ml-connector retrieves open vouchers and vendor records from JD Edwards, groups them by vendor and currency, creates quotes and recipients in Wise, and executes transfers to settle approved payments. Wise webhooks (transfersstate-change, transferspayout-failure) fire when payments succeed, fail, or stall in the correspondent network, and ml-connector ingests these events to update payment status in JD Edwards' account ledger, post confirmation entries, and flag failed transfers for investigation. Vendor masters in JD Edwards (F0401, F0101) are mapped to Wise recipients by email or bank account, enabling recurring payment runs without manual recipient setup.

How ml-connector handles it

ml-connector stores both credential sets encrypted: the JD Edwards AIS Server URL and service account token (refreshed on 401 or token expiry), and the Wise OAuth2 client credentials or Personal API Token. On each poll cycle, it queries JD Edwards F0411 (AP Ledger) filtered by date updated, assembles payment batches by vendor and currency, and for each batch obtains a Wise quote, verifies or creates the recipient in Wise, initiates a transfer order, and funds the payment via the Wise Platform API. Wise returns a transfer ID which ml-connector stores encrypted for reconciliation. When Wise webhooks arrive, the signature is verified using the public key from Wise' webhook signature verification process, the transfer ID is matched to the original JD Edwards batch, and the state change (complete, failed, pending) is posted back as a confirmation entry or rejection reversal in JD Edwards' GL. JD Edwards rate limits depend on AIS Server JVM heap and configuration, so ml-connector backs off on slower batches. Vendor IP allowlists on the AIS Server side require the connector egress IP to be pre-whitelisted by the JD Edwards administrator. The JD Edwards session token lifetime and Wise OAuth2 token expiry are tracked independently; token refresh is handled on 401 responses or proactively before expiry. Every record carries a full audit trail and can be replayed if a Wise transfer confirmation fails to post.

A real-world example

A mid-sized manufacturing and distribution company uses Oracle JD Edwards for complete financial operations and has invoices due to international suppliers in multiple currencies. Before the integration, the AP team manually reviewed open vendor invoices in JD Edwards, created payment instructions in Wise by hand, and then returned to JD Edwards to post the payment status once Wise confirmed the transfer cleared the correspondent bank. Month-end close was delayed by the time spent on manual payouts and reconciliation mismatches. With Wise and JD Edwards connected, the AP team runs an automated payment cycle that pulls open invoices from JD Edwards, executes transfers in Wise at favorable rates with no manual steps, and receives webhook confirmations that post back to the ledger automatically. The month-end close cycle is compressed, international payments move faster, and reconciliation errors from manual re-entry are eliminated.

What you can do

• •Poll open AP vouchers from Oracle JD Edwards by vendor and currency, and execute cross-border payments via Wise without manual re-entry.
• •Map JD Edwards vendor masters to Wise recipients by email or bank account, enabling recurring payment runs with no manual recipient setup.
• •Receive Wise webhook notifications when transfers succeed, fail, or stall, and post confirmation or reversal entries back to the JD Edwards account ledger.
• •Handle JD Edwards session token refresh on expiry or 401 errors, and manage Wise OAuth2 token lifecycle with 12-hour refresh windows.
• •Track payment status end-to-end with full audit trails in both systems, enabling replay and investigation of failed transfers without data loss.

Questions

How does ml-connector handle the on-premises JD Edwards environment when Wise is cloud-based?

ml-connector stores the full JD Edwards AIS Server URL (hostname and port) as a credential in the cell, since JD Edwards has no fixed public hostname. The service account token is refreshed proactively on token expiry or on 401 response. Wise credentials (OAuth2 or Personal API Token) are stored separately and encrypted. Both systems' credentials are managed independently within the same flow, so the connector can run in any network location that can reach both the AIS Server (by IP allowlist) and api.wise.com.

What happens when a Wise transfer fails or gets stuck in the correspondent network?

Wise sends a transferspayout-failure or transfersstate-change webhook event to the connector's ingest endpoint. ml-connector verifies the webhook signature using Wise' RSA-SHA256 public key, matches the transfer ID to the original JD Edwards voucher batch, and posts a reversal or investigation entry back to the account ledger. The payment status is tracked in the audit trail, so you can manually investigate the specific correspondent bank delay or rejection and resubmit when ready.

Does ml-connector support recurring vendor payments on a fixed schedule?

Yes. JD Edwards vendor masters (F0401, F0101) are mapped to Wise recipients by email or bank account. On each polling cycle, ml-connector queries open vouchers filtered by due date or aging, groups them by vendor and currency, and executes transfers automatically. You control the polling frequency (daily, weekly, on-demand) via the flow schedule in ml-connector.