Oracle PeopleSoft and BigCommerce integration

What moves between them

The flow runs from BigCommerce into Oracle PeopleSoft. As orders are placed and paid, ml-connector reads each BigCommerce order with its line items and payment transactions and posts a sales journal into the PeopleSoft general ledger, mapped to the correct accounts and ChartFields. Refunds raised in BigCommerce post offsetting journals the same direction. New BigCommerce shoppers are written into PeopleSoft customer records through the CUSTOMER_CI service so the ledger can attribute revenue. Order events arrive by BigCommerce webhook for near-real-time posting, and a scheduled poll backfills anything a webhook missed. PeopleSoft is the system of record for finance, so ml-connector does not write order or pricing data back into the store.

How ml-connector handles it

ml-connector stores both credential sets encrypted. It sends the BigCommerce access token in the X-Auth-Token header on every call and validates incoming BigCommerce webhooks with the HMAC-SHA256 X-BC-Signature before acting. Because the webhook payload is only a type and ID, the connector immediately calls GET /v2/orders/{id} plus the v3 transactions endpoint to pull the full order. On the PeopleSoft side it accepts the customer-specific base URL and Integration Broker node name, authenticates with Basic Auth using the OPRID and password (or an OAuth2 bearer token on 8.58 and later), and posts journals through the JOURNAL_ENTRY_CI SOAP Component Interface, since PeopleSoft has no delivered REST write endpoint for GL. PeopleSoft is polled on a schedule because it cannot be pushed to without admin-side routing. GL accounts and ChartFields are mapped first so every journal line lands on a valid combination, and the PeopleSoft object key, such as the journal ID, doubles as a natural idempotency check so a retry does not double-post. BigCommerce returns HTTP 429 when its per-window rate limit is exceeded, so the connector reads the reset header and backs off. Because BigCommerce auto-deactivates a webhook after about 48 hours of failures or 90 days of inactivity, the connector periodically verifies the hook is active and re-registers it. Every record carries a full audit trail and can be replayed if a PeopleSoft post fails.

A real-world example

A mid-sized manufacturer with roughly 300 employees sells finished goods direct-to-consumer through a BigCommerce store and runs Oracle PeopleSoft Financials for its general ledger and accounts receivable. Before the integration, the finance team exported BigCommerce order and refund reports each day and re-keyed the sales, tax, and refund totals into PeopleSoft by hand, then spent the first days of month-end close reconciling the storefront's payouts against the revenue posted in the ledger. With Oracle PeopleSoft and BigCommerce connected, each settled order posts a sales journal into PeopleSoft automatically against the right accounts, refunds post offsetting entries, and new shoppers land in the customer records. Close starts with online revenue already reconciled and the daily re-keying step is gone.

What you can do

• •Post BigCommerce orders into the Oracle PeopleSoft general ledger as sales journals through the JOURNAL_ENTRY_CI SOAP service.
• •Record BigCommerce payment transactions and refunds against the correct PeopleSoft accounts and ChartFields.
• •Sync new BigCommerce shoppers into PeopleSoft customer records through CUSTOMER_CI.
• •Bridge the BigCommerce X-Auth-Token to PeopleSoft Basic Auth or an OAuth2 bearer token on PeopleTools 8.58 and later.
• •React to BigCommerce order webhooks for near-real-time posting while polling PeopleSoft on a schedule you control.

Questions

Which direction does data move between Oracle PeopleSoft and BigCommerce?

The flow is BigCommerce into Oracle PeopleSoft. Orders, payment transactions, refunds, and new shoppers move from BigCommerce into PeopleSoft as GL journals and customer records. PeopleSoft is the system of record for finance, so ml-connector does not write order or pricing data back into the store.

How are sales posted to PeopleSoft when it has no REST endpoint for the general ledger?

PeopleSoft's delivered REST endpoints are mostly read-only inquiry operations, so GL journals are posted through the JOURNAL_ENTRY_CI SOAP Component Interface instead. ml-connector maps each BigCommerce order and refund to the correct PeopleSoft accounts and ChartFields first, then submits the journal so every line lands on a valid combination. The journal ID acts as a natural idempotency check so a retry does not double-post.

How does the integration handle BigCommerce webhooks and PeopleSoft's lack of push?

BigCommerce sends order events to a registered HTTPS endpoint signed with an HMAC-SHA256 X-BC-Signature, which ml-connector verifies before acting; because the payload is only a type and ID, it then calls the REST API to fetch the full order. PeopleSoft has no self-service webhooks a connector can register, so it is polled on a schedule, and the connector also re-registers the BigCommerce webhook if it auto-deactivates.