Which direction does data move between Oracle PeopleSoft and Adyen?

The flow is one-way, from Adyen into Oracle PeopleSoft. Settled payments, refunds, fees, and chargebacks from Adyen reconciliation reports post as journals into the PeopleSoft general ledger. Adyen is a payments platform with no ledger to update, so ml-connector treats it as a read-only accounting source and never writes financial entries back.

How does the integration get data into PeopleSoft when its REST endpoints are read-only?

PeopleSoft's delivered REST endpoints are read-only inquiry calls, so journals cannot be written through them. ml-connector posts to the JOURNAL_ENTRY_CI SOAP Component Interface instead, which is the supported path for creating GL journals. The connector accepts the customer's base URL and Integration Broker node name and authenticates with Basic Auth or an OAuth2 bearer token.

How are duplicate Adyen notifications kept from double-posting?

Adyen can deliver the same notification more than once, and a scheduled poll runs alongside the webhook. ml-connector verifies each webhook's HMAC-SHA256 signature and carries the Adyen pspReference as the source reference on every PeopleSoft journal, so an already-processed settlement line is skipped rather than posted twice.

Oracle PeopleSoftAdyen

Oracle PeopleSoft and Adyen integration

Oracle PeopleSoft runs core finance and the general ledger. Adyen processes card and online payments, refunds, and payouts. Connecting the two brings settled payment activity into the ledger without re-keying. After each Adyen settlement batch, captured amounts, refunds, processing fees, and chargebacks post into Oracle PeopleSoft against the right accounts and ChartFields. ml-connector handles the very different interfaces on each side and reconciles payment activity to the ledger on the cadence you set.

How Oracle PeopleSoft works

Oracle PeopleSoft is self-hosted, so it has no shared hostname; each customer runs its own environment and provides a base URL plus an Integration Broker node name. Its delivered REST endpoints under the RESTListeningConnector are read-only inquiry calls for invoice and payment status, while writes such as GL journals and vouchers go through SOAP Component Interfaces like JOURNAL_ENTRY_CI and AP_VOUCHER. Authentication is HTTP Basic Auth with an OPRID and password, or OAuth2 bearer tokens on PeopleTools 8.58 and later through an external identity provider. PeopleSoft has no self-service webhooks, so it is read by polling unless an admin configures Integration Broker async routing.

How Adyen works

Adyen is a payments platform, not an ERP, so it has no native vendor, invoice, purchase order, or GL account objects. It exposes payments, captures, refunds, payouts and transfers, disputes, and reconciliation reports through versioned REST APIs, each with its own base URL. Every call carries an X-API-Key header or Basic auth scoped to a company or merchant account, and live endpoints require a merchant-specific URL prefix. Adyen pushes events such as AUTHORISATION, CAPTURE, REFUND, CHARGEBACK, and REPORT_AVAILABLE by webhook, signed with HMAC-SHA256. Settlement and reconciliation reports are the canonical source for accounting, since there is no batch pull API for historical transactions.

What moves between them

The flow runs from Adyen into Oracle PeopleSoft. ml-connector consumes Adyen settlement and reconciliation reports and posts the resulting journals into the PeopleSoft general ledger through the JOURNAL_ENTRY_CI Component Interface: captured payments, refunds, processing fees, and chargebacks, each mapped to the matching PeopleSoft account and ChartFields. The REPORT_AVAILABLE webhook signals when a new report is ready, and a scheduled poll backfills anything a webhook missed. Adyen is treated as a read-only accounting source, so ml-connector never writes payment instructions or financial entries back into Adyen.

How ml-connector handles it

ml-connector stores both credential sets encrypted and sends the Adyen X-API-Key on every call, retrying after the configured window when Adyen returns a too-many-requests error. On the PeopleSoft side it accepts the full base URL and Integration Broker node name per customer, since PeopleSoft publishes no shared address, and authenticates with Basic Auth or an OAuth2 bearer token depending on the PeopleTools version. When the REPORT_AVAILABLE webhook arrives, ml-connector verifies the HMAC-SHA256 signature before processing, downloads the reconciliation report from the signed URL, and parses each settlement line. Because PeopleSoft has no delivered REST write endpoint for journals, postings go through the JOURNAL_ENTRY_CI SOAP Component Interface, and the Adyen pspReference is carried as the source reference so a re-delivered webhook or a poll never double-posts the same journal. Adyen amounts are in minor units, so values are converted to the PeopleSoft currency scale, and accounts and ChartFields are mapped first so every line lands on a valid combination. A scheduled poll runs alongside the webhook to catch reports that did not push, with retries and a full audit trail on every record.

A real-world example

A mid-sized online retailer with about 300 staff runs Oracle PeopleSoft Financials for its general ledger and uses Adyen to take card and wallet payments across its web store and a handful of physical locations. Before the integration, an analyst downloaded Adyen settlement reports each day and keyed the gross sales, refunds, and Adyen fees into PeopleSoft journals by hand, and month-end close stalled while the team reconciled the payment processor balance against the bank deposit. With Oracle PeopleSoft and Adyen connected, every settlement batch posts into the ledger automatically, split into sales, refunds, fees, and chargebacks against the right ChartFields. Close starts with the cash and clearing accounts already reconciled, and the daily manual journal is gone.

What you can do

Post settled Adyen payments, refunds, processing fees, and chargebacks into the Oracle PeopleSoft general ledger from reconciliation reports.
Trigger on the Adyen REPORT_AVAILABLE webhook after HMAC-SHA256 verification, with a scheduled poll as a backfill.
Write journals through the PeopleSoft JOURNAL_ENTRY_CI SOAP Component Interface, mapped to the correct accounts and ChartFields.
Carry the Adyen pspReference as the source reference so re-delivered notifications never double-post a journal.
Bridge the Adyen X-API-Key and the PeopleSoft node login per customer, with retries and a full audit trail on every record.

Questions

Which direction does data move between Oracle PeopleSoft and Adyen?: The flow is one-way, from Adyen into Oracle PeopleSoft. Settled payments, refunds, fees, and chargebacks from Adyen reconciliation reports post as journals into the PeopleSoft general ledger. Adyen is a payments platform with no ledger to update, so ml-connector treats it as a read-only accounting source and never writes financial entries back.
How does the integration get data into PeopleSoft when its REST endpoints are read-only?: PeopleSoft's delivered REST endpoints are read-only inquiry calls, so journals cannot be written through them. ml-connector posts to the JOURNAL_ENTRY_CI SOAP Component Interface instead, which is the supported path for creating GL journals. The connector accepts the customer's base URL and Integration Broker node name and authenticates with Basic Auth or an OAuth2 bearer token.
How are duplicate Adyen notifications kept from double-posting?: Adyen can deliver the same notification more than once, and a scheduled poll runs alongside the webhook. ml-connector verifies each webhook's HMAC-SHA256 signature and carries the Adyen pspReference as the source reference on every PeopleSoft journal, so an already-processed settlement line is skipped rather than posted twice.

Connect Oracle PeopleSoft and Adyen

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

Get started