Oracle PeopleSoft and Stripe integration

What moves between them

The main flow is Stripe to Oracle PeopleSoft. Charge and invoice events from Stripe are read via API polling or captured via webhooks, mapped to PeopleSoft customers by matching Stripe customer IDs to PeopleSoft CUSTOMER_CI keys, and posted into AR as invoices and payments. Payments and refunds flow from Stripe charges into PeopleSoft AR receipt records and general ledger cash accounts. Reference data such as customer ship-to addresses and AR terms can be synced in both directions so Stripe customer profiles stay aligned with PeopleSoft. GL postings are managed by PeopleSoft's AR engine, not written directly by the integration, so every payment maps to a valid customer and cash account already in the ledger.

How ml-connector handles it

ml-connector stores the Stripe secret API key encrypted and presents it as HTTP Basic Auth on every REST call. On the PeopleSoft side it accepts the unique hostname, port, and node name per customer, since PeopleSoft is self-hosted. It authenticates with HTTP Basic Auth using the customer's OPRID and password, or with OAuth2 Bearer token if PeopleTools 8.58 or later is detected. For AR postings that require writing new invoices or receipts, ml-connector uses SOAP Component Interface calls rather than REST, since the REST API is read-only. Stripe webhooks for payment_intent.succeeded, charge.completed, and invoice.finalized are validated with the Stripe-Signature header and update PeopleSoft AR, but ml-connector also polls Stripe periodically to catch any events outside the replay window or if a webhook is dropped. Customer master data is matched by storing the Stripe customer ID in a custom PeopleSoft field or by matching Stripe company name to PeopleSoft CUSTOMER_CI, with manual mapping for the first setup. Every transaction carries a full audit trail and can be replayed if a PeopleSoft write fails. PeopleSoft's lack of API rate limits means heavy polling can impact production performance, so ml-connector batches requests and respects the customer's PeopleSoft window of quiet time, typically after business hours or on weekends.

A real-world example

A mid-market SaaS company runs Oracle PeopleSoft on-premise for accounting and reporting, and Stripe as the payment processor for online subscriptions sold to customers worldwide. Before the integration, the finance team exported Stripe reports daily, cross-referenced customer names by hand, and entered the charges and payments into PeopleSoft AR manually, often one or two days after the payment cleared. This created timing mismatches, duplicate entries when Stripe auto-retried failed charges, and week-long month-end close meetings chasing reconciliation errors. With Stripe and Oracle PeopleSoft connected, charges post to AR on the day the payment succeeds, refunds reverse the original invoice, and the AR aging and cash position are always current. Month-end close starts with AR already reconciled to Stripe, and manual entry is gone.

What you can do

• •Post Stripe charges and invoices into Oracle PeopleSoft AR, matched to the customer in both systems.
• •Sync Stripe payment receipts and refunds into PeopleSoft AR and cash GL accounts.
• •Keep Stripe customer master data aligned with PeopleSoft CUSTOMER_CI names and addresses.
• •Validate Stripe webhook events with HMAC-SHA256 signatures and post authenticated charges to AR without re-keying.
• •Poll Stripe for transactions outside the webhook replay window, with encrypted credential storage and full audit trail on every record.

Questions

How does the integration match Stripe customers to Oracle PeopleSoft customers?

The integration stores the Stripe customer ID in a custom PeopleSoft field on the first run, or matches by comparing Stripe company name to PeopleSoft CUSTOMER_CI and validating the match with a human during setup. After the initial match, every Stripe charge is routed to the correct PeopleSoft customer record. If a new Stripe customer appears with no match, the transaction is queued for review rather than creating a duplicate customer.

Does ml-connector use Stripe webhooks or does it poll?

ml-connector uses both. Stripe webhooks for payment_intent.succeeded and invoice.finalized update AR in real time when they arrive, validated with Stripe-Signature HMAC-SHA256. However, because Stripe webhook delivery is at-least-once and not ordered, and the replay window is only 5 minutes, ml-connector also polls Stripe on a schedule (typically daily or after your billing run) to catch any events outside the replay window or if a webhook is missed.

How does the integration handle PeopleSoft's self-hosted architecture and lack of webhooks?

ml-connector accepts the unique hostname, port, and node name for each PeopleSoft instance and authenticates with HTTP Basic Auth or OAuth2 Bearer token depending on the PeopleTools version. Because PeopleSoft has no standard webhook system and no published API rate limits, ml-connector polls for new AR data on a schedule you set, typically after business hours, to avoid impacting production performance. SOAP Component Interface calls are used for write operations like posting invoices and receipts, not REST, so the integration respects PeopleSoft's read-only REST API design.