Oracle E-Business Suite and PayPal integration

What moves between them

PayPal webhook events flow into Oracle EBS. Customer payments captured through PayPal are received as webhook notifications, transformed into Oracle EBS AP invoice headers and GL journal lines, and posted through the ISG REST gateway. Refunds are received as separate webhook events and reverse the original GL entries. Payment amounts map to GL accounts based on the invoice type and customer, and settlement summaries can be queried from PayPal's transaction search and posted as daily reconciliation entries into Oracle EBS. The flow is one-directional: PayPal to Oracle EBS. Oracle EBS does not create or cancel PayPal orders; it only receives and records the resulting transactions.

How ml-connector handles it

ml-connector listens for PayPal webhook events using RSA-SHA256 signature verification against PayPal's public certificate, ensuring every notification is authentic. On receipt of a payment webhook, ml-connector queries the PayPal transaction search API for settlement details within the past 31 days. The transaction is mapped to an Oracle EBS invoice by matching the PayPal invoice_id field against EBS AP_INVOICES_ALL. ml-connector then assembles a GL journal entry, populating GL_JE_HEADERS with the posting date and period, and GL_JE_LINES with the debit (bank account) and credit (revenue) sides, using the EBS GL_CODE_COMBINATIONS view to validate the GL account combinations. The entry is posted through the ISG REST gateway using HTTP Basic Auth and the required context headers ctx_orgid, ctx_responsibility, ctx_respapplication, ctx_securitygroup, and ctx_nlslanguage. For refunds, the same flow reverses the original entry. PayPal Bearer tokens expire at approximately 8 hours and are cached and refreshed transparently. EBS session tokens have shorter lifespans (typically 30-60 minutes) and trigger a 401 re-authentication with Basic Auth. ml-connector retries on transient errors and maintains a full audit trail of every webhook received, every API call, and every GL entry posted.

A real-world example

A mid-market e-commerce business runs Oracle E-Business Suite for accounting and order fulfillment, and accepts payments globally through PayPal. Before the integration, the finance team received daily PayPal settlement reports via email, manually entered each transaction into Oracle EBS as an AP invoice and GL entry, and spent hours each month reconciling the accounts payable ledger against PayPal settlement records. With PayPal and Oracle EBS connected, customer payments flow in automatically as GL journal entries on the day they are captured, refunds reverse the entries immediately, and the bank reconciliation is complete. Month-end close starts with the accounts already reconciled, the cash position is always current, and there are no re-keying errors.

What you can do

• •Post PayPal payments and refunds into Oracle EBS as GL journal entries immediately upon webhook notification.
• •Map PayPal transactions to Oracle EBS AP invoices and cost objects using invoice_id matching and GL account validation.
• •Authenticate PayPal with OAuth 2.0 and Oracle EBS with HTTP Basic Auth or session tokens, including the required application context headers.
• •Verify PayPal webhook signatures using RSA-SHA256 and PayPal's public certificate, ensuring authenticity on every notification.
• •Maintain a full audit trail of all PayPal webhooks received, all API queries executed, and all GL entries posted to Oracle EBS.

Questions

Does Oracle EBS require polling or can PayPal push transactions directly?

PayPal pushes transactions via HTTPS webhook notifications, so ml-connector receives them in near real-time. Oracle EBS itself does not support webhooks, but ml-connector acts as the receiver, listens for PayPal events, and immediately posts them into EBS through the ISG REST gateway. This approach is faster and more reliable than polling EBS for changes.

What are the Oracle EBS application context headers, and why are they required?

Oracle EBS requires five context headers on every API request: ctx_orgid (the operating unit), ctx_responsibility (the responsibility code assigned to the user), ctx_respapplication (the application code for that responsibility), ctx_securitygroup (the security group), and ctx_nlslanguage (the language code, typically en). These headers determine which data the API returns and which GL accounts and cost centers are available for posting. ml-connector obtains these values from your customer configuration and includes them on every request.

How does ml-connector handle PayPal refunds and chargebacks?

PayPal webhook events distinguish between captures (successful payments) and refunds (full or partial reversals). When ml-connector receives a refund event, it queries PayPal's transaction search API for the original capture and then posts a reversing GL journal entry into Oracle EBS, using the same GL accounts and amounts as the original payment but with opposite signs. Chargebacks are tracked separately in the audit log and can trigger manual review depending on your configuration.