Support Extended
Families
+ ECC Datasets
Supported
Timeline
Why Oracle EBS customers add Payment Hub, and what changes when they do
Oracle E-Business Suite (EBS) is the on-premise enterprise ERP that's been the backbone of Fortune 500 / Global 2000 financial operations for over 25 years, from Oracle Financials in the late 1990s through Release 11i, 12.0, 12.1, and now Release 12.2 with annual minor releases through 12.2.15 (October 2025). The brochure leads with a clear strategic anchor: Oracle has extended Premier Support through 2036 and committed to a rolling 10+ years notice before any potential end of support. EBS customers can plan around at least the next decade with full confidence the platform will remain supported, enhanced, and viable. Customer enhancement votes drive the roadmap. 12.2.15 Alone delivered hundreds of customer-requested enhancements across the six product families: ERP, SCM, Asset Lifecycle Management, Service, HCM, and Applications Technology.
The gap, and it's a specific kind of gap that's nearly universal across long-running EBS installations, is the legacy iPayment + CyberSource lock-in on the payment-acceptance side. EBS ships with iPayment (formerly Oracle Payments / IBY), the cross-product payment foundation that handles funds capture, payment instrument storage, settlement processing, and gateway integration via Funds Capture Process Profiles. In practice, the most common EBS payment integration runs through CyberSource (Oracle's long-standing payment-partner relationship), often configured a decade or more ago. Most EBS customers are effectively single-gateway, single-MID, processing all card volume across all Operating Units through one CyberSource merchant account, with no Level III interchange enrichment, no surcharging, no real customer portal payment surface beyond basic iReceivables, no multi-MID flexibility, and no automated dunning. The capabilities sit frozen at whatever was implemented during the original ERP go-live, typically years ago.
Payment Hub fills this gap through Oracle's own published integration surfaces, REST APIs (where exposed via Oracle REST Data Services / ORDS), SOAP web services (the extensive WSDL surface across the EBS product families), Oracle Integration Cloud (OIC) for hybrid orchestration, documented PL/SQL APIs (AR_RECEIPT_API_PUB for cash receipts, AP_INVOICE_API_PUB for AP invoices, AutoInvoice via RA_INTERFACE_LINES_ALL, and many others), Open Interface tables for batch loads, and Web ADI for Excel-based scenarios. The integration is non-invasive (no Oracle Forms / OAF / ADF source changes, no PL/SQL package modifications, no DFF or AME or Workflow changes). It respects your decades of EBS customizations, and it works across all six EBS product families plus Enterprise Command Centers (ECC). What you gain: gateway- and processor-agnostic flexibility (pick from 19+, keep CyberSource if you want), Level III interchange optimization, customer portal payment surface modernization, real-time line-level cash application, multi-Operating-Unit / multi-ledger / multi-currency routing, surcharging where legal, dunning automation. And, for EBS customers planning an Oracle Fusion Cloud ERP migration, Payment Hub's configuration ports forward when the migration completes.
Premier Support extended through 2036, EBS is here for the long haul
Oracle's announcement (April 2025) extending EBS Premier Support through 2036, combined with the rolling 10+ years notice commitment, confirms that EBS will remain a supported, evolving, critical enterprise ERP for well into the next decade. Payment Hub investment on EBS is a 10+ year horizon investment, valuable independent of any Cloud ERP migration timeline.
Customer-driven enhancements have shaped each EBS release. EBS 12.2.15's release notes confirm Oracle's strategy of investing in customer-requested functionality: Receivables Reconciliation Dashboard for Receivables Command Center, Open Liabilities Dashboard for Payables Command Center, Lease Accounting enhancements (IFRS 16 / ASC 842 / GASB 87 / SFFAS 54 compliance), Cost Planning and Margin Analysis with tariff-impact simulation, Mobile Field Service AI summaries, Redwood Look and Feel UX modernization, Oracle JET-based HTML UIs replacing Oracle Forms-era screens. The platform continues to evolve. Payment Hub follows the same modernization arc, gateway flexibility, L3 enrichment, customer portal modernization, surcharging, dunning automation, capabilities long overdue on the payment-acceptance side.
EBS on-premise → Oracle Fusion Cloud ERP, Payment Hub bridges both sides
For EBS customers planning an Oracle Fusion Cloud ERP migration in the next 2-5 years, Payment Hub is a bridge investment, modernize payment now on EBS and the configuration ports forward when the cloud migration completes. Same gateway connections, same routing rules, same surcharging, same dunning, same customer portal, all carry across the migration.
Today (or for the long haul)
Oracle EBS On-Premise
PORTS
FORWARD
When you're ready
Oracle Fusion Cloud ERP
Same gateway connections, same routing rules, same surcharging policy, same dunning ladder, same customer portal, same Level III field mappings. The integration surface changes from EBS REST/SOAP/PL/SQL to Cloud ERP REST/OIC/FBDI. The application configuration ports forward without re-implementation.
For EBS customers planning a Cloud ERP migration in the next 2-5 years, this changes the calculus on payment modernization. You don't have to wait for the cloud migration to be done before fixing the iPayment + CyberSource lock-in, and you don't have to throw away the payment integration when you eventually do migrate. The same Clarity team configures Payment Hub on EBS first, then re-points the integration surface to Oracle Cloud REST APIs and OIC when Fusion Cloud ERP cuts over. Customer portal, gateway connections, surcharging rules, dunning automation, L3 enrichment, multi-Business-Unit routing, all of it carries. For customers staying on EBS through the full Premier Support horizon (a perfectly valid choice given the 2036 commitment), the same Payment Hub configuration runs continuously.
The six EBS product families, all touched by Payment Hub
EBS organizes around six product families that share a common technology foundation. Payment Hub integrates across all six, though the primary touch point is the ERP family (Receivables, Payables, GL, Procurement). Every family emits payment-relevant events.
ERP Family
Receivables (RA_CUSTOMER_TRX, AR_CASH_RECEIPTS_ALL), Payables (AP_INVOICES_ALL), General Ledger, Lease Accounting (IFRS 16 / ASC 842 / GASB 87 / SFFAS 54), Lease and Finance Management, Procurement, iSupplier Portal, Project Costing/Billing, G-Invoicing for US Federal. Where customer payments flow.
SCM Family
Order Management, Internal Sales Orders (ISOs)/Internal Org Transfers (IOTs), Channel Revenue Management, Warehouse Management with mobile dashboards, Inventory with ML-driven cycle counting, Cost Management with margin analysis, Manufacturing (MES + Process Mfg + Outsourced Mfg), Quality, Product Hub. For shipment-triggered captures and CTO/MTO deposits.
Asset Lifecycle Management (ALM)
Enterprise Asset Management with AI maintenance summaries, Scheduler Workbench, Mobile Maintenance, Enhanced Asset Quality Management. For asset-leasing recurring payments, capital-equipment-as-a-service, and field-service deposits.
Service
Mobile Field Service with AI-generated field service summaries, Dispatch Center HTML UI on Oracle JET, laptop apps for Windows/iOS/Android. For per-ticket invoicing with stored credentials, on-site capture via mobile, and field-service-driven recurring service contracts.
HCM Family
HCM Mobile Apps with common Mobile Home Page, Mobile Learning on Oracle JET, Self-Service HR with modernized organization chart. For employee expense reimbursement scenarios and corporate-card transaction reconciliation where applicable to the payment flow.
Applications Technology
Enterprise Command Center Framework (ECC) currently V15, Receivables Reconciliation Dashboard, Open Liabilities Dashboard, GL Account Analysis with DFF support, Procurement Command Center. Redwood Look and Feel UX. Oracle JET HTML UIs replacing Oracle Forms. Payment KPIs surface here.
The six families share Oracle's common technology foundation, the same security model, the same workflow engine (AME plus the older Workflow Builder), the same database (Oracle Database, typically 19c), the same Concurrent Manager for batch jobs, the same WebLogic Server tier. Payment Hub uses Oracle's documented integration paths exclusively, so the integration works the same way regardless of which families are deployed at the customer. Customers running just ERP get the primary integration. Customers running the full stack (common in Fortune 500) get the broader payment-event reach across SCM, ALM, Service, and HCM-related events.
Payment Hub vs Oracle iPayment + CyberSource, honest side-by-side
iPayment (formerly Oracle Payments / IBY) is the payment foundation that ships with EBS. CyberSource is the most common gateway choice through Oracle's long-standing partner relationship, often configured a decade or more ago at most EBS shops. The combination works for simple invoice-payment scenarios. Payment Hub is the gateway-agnostic alternative for EBS customers who need more, multi-gateway flexibility, Level III enrichment, customer portal modernization, and capabilities iPayment doesn't ship.
| Capability | iPayment + CyberSource (typical EBS state) | Payment Hub on EBS |
|---|---|---|
| Gateway / processor choice | ● Effectively single-gateway (CyberSource the dominant choice). Switching = re-do Funds Capture Process Profile, re-certify | ● 19+ gateways behind one integration (Worldpay, Adyen, Fortis, PayTrace, Stripe, Authorize.Net, NMI, USAePay, plus CyberSource if you want) |
| Level III interchange enrichment | ● Not auto-enriched, requires custom config or third-party | ● Auto-enriched from RA_CUSTOMER_TRX_LINES / OE_ORDER_LINES / Project Invoice, 20+ fields per transaction |
| Customer portal payment surface | ● iReceivables view + basic payment via iPayment | ● Modernized payment surface, multi-invoice batch pay, stored credentials, ACH, multi-currency, L3, surcharging |
| Multi-invoice consolidation | ● Per-invoice flow standard | ● Batch pay across multiple invoices, single auth, single capture, line-level cash app |
| Multi-OU / multi-ledger routing (different MIDs) | ● Per-OU Funds Capture Profiles possible, rigid. Usually single-MID in practice | ● Per-OU / per-ledger / per-Legal-Entity routing, different MIDs, gateways, currencies, tax setups |
| Surcharging / convenience fees | ● Not native | ● Compliant surcharging engine (per-state, per-card-brand, per-merchant rules, per-country) |
| Real-time line-level cash application | ● AutoLockbox handles bank-side, line-level mapping varies | ● Real-time line-level cash app via AR_RECEIPT_API_PUB + AR_RECEIPT_APPLICATIONS_ALL |
| ECC dashboard publishing | ● Standard iPayment events, limited ECC payment-specific dashboards | ● Payment KPIs (L3 yield, surcharge yield, retry success, dispute rate) publish into ECC datasets |
| Dunning automation | ● Collections module has dunning, not gateway-aware | ● Full dunning ladder with auto-retry, gateway-aware, configurable per OU |
| Custom AME / Workflow / DFF respect | ● Native, AME and Workflow fire on iPayment-driven postings | ● Same, AME, Workflow, DFFs fire on Payment Hub-driven postings, full preservation |
| Cloud ERP migration bridge | ● N/A, iPayment doesn't carry across migration | ● Configuration ports forward to Oracle Fusion Cloud ERP. Same vendor through the migration |
The Missing LinkBetween Paymentsand Your ERP
Clarity Payment Hub closes that gap, connecting your orders, invoices, and payment channels into one flow.
Speak to a Platform ArchitectHow the integration works, REST + SOAP + OIC + PL/SQL APIs
Payment Hub plugs into EBS through Oracle's published integration surfaces, REST APIs (where exposed via ORDS), SOAP web services (the extensive WSDL surface), Oracle Integration Cloud (OIC), documented PL/SQL APIs, Open Interface tables for batch, and Web ADI for Excel-based scenarios. No core EBS source modifications. Eight features that come online when EBS gets Payment Hub:
REST APIs (via ORDS) for primary calls
Where Oracle REST Data Services (ORDS) is enabled, Payment Hub uses REST endpoints for synchronous calls. Standard HTTPS, OAuth 2.0 or session-based authentication, JSON payloads. Modern integration path matching what the rest of the Oracle ecosystem uses.
SOAP web services for the broader EBS surface
EBS exposes an extensive WSDL surface across the product families, orders, invoices, receipts, customers, suppliers, projects, and more. Payment Hub uses SOAP where REST isn't available. Standard XML envelopes, certificate-pinned outbound HTTPS.
Documented PL/SQL APIs
For deep integration scenarios, Payment Hub uses Oracle's documented PL/SQL APIs: AR_RECEIPT_API_PUB.create_cash for cash receipts, AR_RECEIPT_APPLICATIONS_PUB.activity_application for line-level cash app, AP_INVOICE_API_PUB.create_invoice for AP, AR_CREDIT_MEMO_API_PUB for refunds. These are Oracle-published, version-stable APIs.
Level III auto-enrichment
Pulls 20+ required L3 fields from RA_CUSTOMER_TRX_LINES, OE_ORDER_LINES, and PA_PROJECT_INVOICE_LINES records. Packages and submits per gateway / card-brand spec. Enterprise EBS customers commonly recover $75K–$1M+/yr, substantial when L3 turns on for the first time after years on iPayment without enrichment.
iReceivables portal modernization
Embedded payment surface inside EBS iReceivables. Multi-invoice batch pay, stored credentials, ACH, multi-currency, L3 enrichment, surcharging. Authentication through EBS's standard self-service framework. Modernizes the iReceivables payment experience without modifying the iReceivables UI itself.
Multi-OU / multi-ledger / MOAC / SVS routing
Each Operating Unit / Ledger / Legal Entity gets its own gateway, MID, bank account, currency, tax setup. Routing decisions respect MOAC (Multi-Org Access Control) and SVS (Segment Value Security). Scales to 100+ OUs across multi-Ledger Fortune 500 deployments.
Enterprise Command Center (ECC) integration
Payment events publish into ECC datasets. Surcharge yield, L3 yield, gateway uptime, dispute / chargeback flow, retry success rate flow into the Receivables Command Center, Payables Command Center, and GL Command Center alongside EBS's native KPIs. ECC V15-compatible.
Migration-ready architecture
Configuration held in Clarity's payment platform, not in EBS source. Migration to Oracle Fusion Cloud ERP changes the integration surface (REST/SOAP/PL/SQL on EBS → Cloud REST/OIC/FBDI on Cloud ERP). The application configuration ports forward without re-implementation.
The integration workflow, a long-running EBS customer's order-to-cash, end to end
Walk through one realistic EBS scenario. Calhoun Industrial Holdings, a $4.2B North American industrial manufacturing company running EBS 12.2.13 since 2004, with 12 Operating Units, 8 Ledgers, 4 currencies (USD, CAD, EUR, GBP), 35 manufacturing plants, 8 distribution centers, 4,200 employees. The company has been on iPayment + CyberSource for over a decade, single-MID across all OUs, no L3 enrichment, basic iReceivables portal payment, no surcharging or dunning automation. They're planning an Oracle Fusion Cloud ERP migration in 3 years but want payment modernization now. Eight steps showing a specific $580,000 B2B order from a major distributor (Acme Industrial Distributors) processed through Payment Hub, replacing the legacy iPayment + CyberSource flow.
Order entry, Acme places $580K B2B order through OE_ORDER_HEADERS_ALL
Acme Industrial Distributors (long-time Calhoun customer, $40M annual spend) submits a $580,000 PO for industrial machinery components. Calhoun's CSR enters Sales Order SO-2026-08412 in Order Management: 87 line items, OU=Calhoun-Manufacturing-US, Ledger=Calhoun-US-Ledger, Currency=USD, Plant=Pittsburgh. Standard EBS order flow: OE_ORDER_HEADERS_ALL header + 87 OE_ORDER_LINES_ALL records. Custom AME approval workflow runs (Calhoun has 14 years of AME customizations preserved). Order approves, ships, AutoInvoice generates invoice via AR_INTERFACE_LINES_ALL → RA_CUSTOMER_TRX (RAX-2026-08412) for $580,000.
SO-2026-08412 · $580KOU=Calhoun-Manufacturing-US87 line items · AME preservedCustomer portal payment, Acme AP team logs into iReceivables, pays via Visa Purchasing
Acme's AP contact receives standard EBS dunning/notification email with iReceivables portal link. Logs in (standard EBS self-service auth, no change to authentication flow). Sees RAX-2026-08412 in their portal view. Click "Pay", instead of the old iPayment + CyberSource UI, the Payment Hub embedded payment surface activates. Acme batch-pays this invoice plus 2 smaller open invoices ($580K + $42K + $18K = $640K total) in a single transaction via stored Visa Purchasing card. Pre-Payment-Hub this would have been three separate iPayment transactions. Now it's one batch.
iReceivables · embedded surface3-invoice batch · $640KVisa PurchasingRouting, OU=Calhoun-Manufacturing-US → Worldpay merchant account (replacing CyberSource)
Routing matrix: OU=Calhoun-Manufacturing-US → Worldpay (Calhoun chose to break the CyberSource lock-in and consolidate to Worldpay across all US OUs), USD, GL=10110-CASH-USD-OPS, surcharge=disabled (B2B, customer relationship). L3 enrichment auto-fires from the 87 line items in RA_CUSTOMER_TRX_LINES on the main invoice, plus the 2 batched smaller invoices: 102 line items total, packaged as 102 separate L3-enriched line records, plus the 20+ required L3 fields per transaction (commodity codes, freight, tax, ship-from, ship-to addresses).
Worldpay · USD · GL-CASH-USD-OPSL3 from 102 line itemsNo surcharge · B2BCapture &, cash receipt, AR_RECEIPT_API_PUB creates AR_CASH_RECEIPTS_ALL
Capture confirms at Worldpay. Payment Hub calls AR_RECEIPT_API_PUB.create_cash via PL/SQL: creates AR_CASH_RECEIPTS_ALL record in Calhoun-US OU for $640,000, references Worldpay transaction ID. Custom AME approval rules for cash receipts $500K+ fire (Calhoun's policy). AME routes to the Pittsburgh plant controller for ratification, auto-approved within 30 seconds based on the AME rule for stored-credential captures from approved customers. AR_RECEIPT_APPLICATIONS_PUB.activity_application then applies the receipt against all 3 invoices line-level. AR aging refreshes immediately.
AR_RECEIPT_API_PUB3-invoice line-level applyAME ratifiedL3 savings, first calculation since 2014, immediate visible savings
This is the first card transaction Calhoun has ever processed with full L3 enrichment. Pre-Payment-Hub state: card volume processed at non-qualified or partially-qualified interchange rates, costing Calhoun roughly 2.45-2.95% per B2B card transaction. Post-Payment-Hub state: large-ticket L3 interchange where qualifying. Savings on this single $640K transaction: ~$5,200. Projected annual L3 savings on Calhoun's $42M B2B card volume across all 12 OUs: $420K-$680K depending on commercial-card mix. Going-forward.
L3 saved · $5,200 (this txn)Annual proj · $420K-$680KECC dashboard, payment KPIs surface in Receivables Command Center
The Pittsburgh controller's Receivables Command Center dashboard refreshes. Today's view: Outstanding Receivables down $640K, DSO improved (Acme's open balance closed in real time), L3 savings tracked separately as a new dataset alongside the standard EBS Receivables Command Center datasets. Pre-Payment-Hub there was no L3-savings tracking anywhere in EBS. Now it's a first-class metric. The 12.2.15 Receivables Reconciliation Dashboard also benefits, discrepancies between subledger and GL on this transaction are zero (real-time line-level cash app via PL/SQL APIs eliminates the typical reconciliation lag).
Receivables Command CenterL3 savings trackedZero reconciliation lagMulti-OU expansion, Calhoun rolls out Payment Hub to remaining 11 OUs over 6 months
Pittsburgh OU lit up first. Over the next 6 months, Calhoun rolls Payment Hub out to the other 11 OUs progressively: 3 US manufacturing OUs, 2 US distribution OUs (where Stripe gets added as the secondary gateway for B2C-adjacent retail traffic), 2 Canadian OUs (Adyen for CAD-native processing instead of CyberSource USD-only handling), 2 European OUs (Adyen for EUR/GBP), and 2 Mexican OUs (Stripe for MXN). Each OU gets its own MID/gateway/currency. Single Payment Hub configuration table. Consolidated reporting back to corporate finance via standard EBS multi-Org views.
12 OUs · 4 currencies3 gateways live6-month rolloutYear 3, Calhoun migrates to Oracle Fusion Cloud ERP. Payment Hub configuration ports forward
Three years later, Calhoun's planned Cloud ERP migration cuts over. EBS data migrates to Oracle Fusion Cloud ERP via Oracle's standard migration tooling (the OUs become Business Units. The Ledgers carry over directly. Custom AME rules migrate where supported). Payment Hub's integration surface re-points: instead of REST/SOAP/PL/SQL against EBS, the calls now go to Oracle Cloud ERP REST APIs and OIC. Calhoun's gateway connections (Worldpay, Stripe, Adyen), routing matrix (12 BUs now instead of 12 OUs), surcharging policy, dunning ladder, customer portal customizations, L3 field mappings, all carry forward. Two-day cutover, zero re-implementation of the payment layer. The L3 savings, by now ~$1.8M cumulative over 3 years on EBS, continue uninterrupted on Cloud ERP.
Cloud ERP cutoverConfig ports forward$1.8M L3 saved (3yr cumulative)Use cases that light up on Oracle E-Business Suite
All eleven Payment Hub use cases run on EBS. These are the patterns where the EBS integration shines, and where Fortune 500 / Global 2000 EBS customers get the highest use given the typical decade-plus iPayment + CyberSource starting state.
Real-time line-level cash application via AR_RECEIPT_API_PUB and AR_RECEIPT_APPLICATIONS_ALL. AR aging refreshes immediately. Manual reconciliation drops to near zero across all OUs. ECC Receivables Reconciliation Dashboard benefits.
Interchange Level III cost reductionAuto-enrichment from RA_CUSTOMER_TRX_LINES, OE_ORDER_LINES, and PA_PROJECT_INVOICE_LINES. Enterprise EBS customers commonly recover $75K–$1M+/yr, substantial when L3 turns on for the first time.
Multi-OU Multi-OU / multi-ledger paymentsPer-OU / per-ledger / per-Legal-Entity routing, different gateways, MIDs, currencies, GLs. MOAC and SVS aware. Scales to 100+ OUs across multi-Ledger Fortune 500 deployments.
Customer Portal iReceivables payment modernizationEmbedded payment surface inside iReceivables. Multi-invoice batch pay, stored credentials, ACH, multi-currency, L3 enrichment. Modernizes the iReceivables payment experience without modifying iReceivables UI.
Order-to-Cash OE_ORDER → AR → Cash automationEnd-to-end O2C through EBS Order Management → AutoInvoice → Receivables. Deposits, milestone billing on Project Costing/Billing, partial-shipment captures via OE_ORDER_LINES_ALL.
ACH ACH / eCheck automationSame-day ACH, NACHA validation, returns handling, auto-pay programs. Best fit for B2B enterprise net-30 buyers running on EBS for years where ACH was previously batched manually.
Collections Dunning &, collections automationAugments EBS Collections module with gateway-aware retry logic. Configurable dunning ladder per OU. Email templates branded per region/language. Integrates with custom AME-driven escalation rules.
Cost Recovery Compliant surchargingPer-state, per-card-brand, per-merchant-class, per-country rules. Auto-disclosure on iReceivables portal and hosted pages. Surcharge revenue offsets card cost. Not native to iPayment.
Recurring Service contracts &, recurring billingFor EBS customers running Service Contracts module, automated recurring billing through OKS/OKL, gateway-independent. Auto-retry, dunning ladder, mid-cycle changes.
B2C / B2B eCommerce checkoutFor EBS customers running eCommerce front-ends (Oracle iStore or third-party): hosted checkout, tokenization, 3DS2 / SCA in EU, Apple Pay / Google Pay.
Card Present Counter sales / branch operationsFor retail and branch-network EBS customers: P2PE-validated terminals integrated through Order Management module. Per-location MID routing.
If you're running EBS 12.2.x today (or planning a Cloud ERP migration), Clarity will run a guided demo on your environment, your gateways, your routing scenario, and your AME / DFF / custom Workflow customizations. Pilot one OU live in 48 hours, ride through to Cloud ERP when you migrate.
Technical details, for the EBS architects
For Oracle partners, EBS architects, and DBA teams: the connection model, PL/SQL API surface, security posture, and deployment options.
Integration surface
REST APIs (via Oracle REST Data Services / ORDS) for synchronous calls where exposed. SOAP web services for the broader EBS WSDL surface. Oracle Integration Cloud (OIC) for hybrid orchestration with other Oracle SaaS and non-Oracle systems. Documented PL/SQL APIs: AR_RECEIPT_API_PUB, AR_RECEIPT_APPLICATIONS_PUB, AP_INVOICE_API_PUB, AR_CREDIT_MEMO_API_PUB, HZ_CUST_ACCOUNT_V2PUB, plus many others. Open Interface tables for batch, RA_INTERFACE_LINES_ALL (AutoInvoice), AR_PAYMENTS_INTERFACE_ALL, AP_INVOICES_INTERFACE. Web ADI for Excel-based scenarios. Authentication via EBS native security or federated SSO.
EBS tables consumed and posted
- HZ_CUST_ACCOUNTS / HZ_PARTIES: read/write via TCA APIs. Stored credentials linked back via DFF.
- RA_CUSTOMER_TRX / RA_CUSTOMER_TRX_LINES: read for invoice payment + L3 enrichment.
- AR_CASH_RECEIPTS_ALL: written via AR_RECEIPT_API_PUB on every capture.
- AR_RECEIPT_APPLICATIONS_ALL: written via AR_RECEIPT_APPLICATIONS_PUB for line-level cash app.
- AP_INVOICES_ALL: read/write for AP rebate refund flows via AP_INVOICE_API_PUB.
- OE_ORDER_HEADERS_ALL / OE_ORDER_LINES_ALL: read for L3 enrichment and order-state events.
- PA_PROJECT_INVOICES / PA_PROJECTS: read for project-level milestone billing.
- HR_OPERATING_UNITS / GL_LEDGERS / XLE_FIRSTPARTY_INFO_V: read for routing rule lookup.
- AR_DUNNING_LETTERS / AR_COLLECTORS: read for collections workflow integration.
Customization respect
- Custom Oracle Forms screens, Payment Hub doesn't modify the Forms tier.
- OAF (OA Framework) extensions, custom controllers fire normally.
- ADF pages, Payment Hub doesn't modify ADF UI.
- Custom PL/SQL packages, coexist with Payment Hub's API calls.
- Descriptive Flexfields (DFFs), custom DFF defaults, validations, value sets fire as designed.
- Approvals Management Engine (AME), custom AME rules fire on Payment Hub-driven postings.
- Workflow Builder, custom workflows fire on the standard event triggers.
- Custom Concurrent Programs, coexist. Payment Hub uses standard scheduling where appropriate.
ECC integration
Enterprise Command Center Framework (ECC), currently V15 as of 12.2.15 release timeframe, provides the modern dashboard layer. Payment Hub publishes payment events into ECC datasets via Oracle's published ECC dataset framework. Surcharge yield, L3 yield, gateway uptime, dispute / chargeback flow, retry success rate, recurring MRR all surface alongside EBS's native KPIs in Receivables, Payables, GL, and Procurement command centers. Because ECC V15 can run on EBS 12.2.10 (ECC and EBS releases are decoupled), Payment Hub's ECC integration runs independently of which EBS minor release you're on.
Security and compliance
- EBS native authentication or federated SSO (Oracle Access Manager / Identity Manager).
- PCI DSS Level 1 service provider, with PCI scope minimized via tokenization at gateway.
- Card data never lands in EBS's Oracle Database. Tokens stored in HZ_CUST_ACCOUNTS DFF.
- P2PE-validated terminals available for card-present scenarios.
- SOC 2 Type II (Clarity).
- 3DS2 / SCA support natively across all gateways for European compliance (PSD2).
Deployment scenarios
- EBS on customer-hosted infrastructure: outbound HTTPS only. Standard REST/SOAP/PL/SQL integration.
- EBS on Oracle Cloud Infrastructure (OCI) IaaS: same integration model, OCI hosts the EBS stack.
- EBS on AWS / Azure IaaS: supported, standard outbound integration.
- Multi-instance EBS: separate Payment Hub deployments per EBS instance with shared corporate-finance reporting.
- Hybrid EBS + Oracle Cloud SaaS: Payment Hub bridges EBS-side flows and Cloud SaaS-side flows where customers run a mixed environment.
EBS vs Oracle Fusion Cloud ERP, at the integration layer
EBS and Oracle Fusion Cloud ERP share substantial functional DNA, the Cloud ERP product was built largely on patterns originally developed in EBS. At the Payment Hub integration layer, the differences are: EBS integrates via REST/SOAP/PL/SQL APIs / Open Interface tables / Web ADI. Cloud ERP integrates via Oracle's modern REST APIs and Oracle Integration Cloud (OIC). The data models map similarly (RA_CUSTOMER_TRX in EBS ↔ Receivables Transaction in Cloud ERP. AR_CASH_RECEIPTS_ALL in EBS ↔ ArReceipts in Cloud ERP. HZ_CUST_ACCOUNTS in EBS ↔ HzCustAcct in Cloud ERP). Payment Hub's application configuration ports forward across the migration without re-implementation, same gateway connections, same routing rules, same surcharging, same dunning, same customer portal.
Frequently asked questions about Oracle E-Business Suite + Payment Hub
Answers to the most common questions from EBS customers, Oracle partners, and architects planning payment modernization on long-running EBS installations.
Does Clarity Payment Hub integrate with Oracle E-Business Suite?
Yes. Clarity Payment Hub integrates with Oracle E-Business Suite (EBS) 12.2.x through Oracle's standard integration surfaces, REST APIs (where available via Oracle REST Data Services / ORDS), SOAP web services (extensive WSDL surface across the EBS product families), Oracle Integration Cloud (OIC) for hybrid orchestration, documented PL/SQL APIs (AR_RECEIPT_API_PUB for cash receipts, AP_INVOICE_API_PUB for AP invoices, AR_INTERFACE_LINES_ALL via AutoInvoice, etc.), Open Interface tables for batch loads, and Web ADI for Excel-based scenarios.
Authentication uses EBS's native security model with optional federated SSO. Every transaction posts to EBS in real time. RA_CUSTOMER_TRX (Receivables transactions), AR_CASH_RECEIPTS_ALL (Cash Receipts), AP_INVOICES_ALL (AP Invoices), and HZ_CUST_ACCOUNTS (Customer Accounts) stay as the single source of truth in your EBS database.
Why does Payment Hub matter for EBS customers given Oracle's commitment to support EBS through 2036?
Oracle has extended EBS Premier Support through 2036 and committed to a rolling 10+ years notice before any potential end of support, confirming that EBS will remain a critical ERP platform for many enterprise customers for at least the next decade.
That long horizon makes payment modernization on EBS valuable. Customers can replace legacy iPayment + CyberSource configurations (which most long-running EBS shops have accumulated) with Payment Hub's gateway-agnostic flexibility, gain Level III interchange savings, modernize the customer-portal payment surface, add surcharging and dunning automation, all without depending on a Cloud ERP migration timeline. Payment Hub investment pays back across the full Premier Support horizon.
How is this different from Oracle's iPayment / Oracle Payments and the typical CyberSource lock-in?
EBS ships with iPayment (formerly Oracle Payments / IBY), the cross-product payment foundation that handles funds capture, payment instrument storage, settlement processing, and gateway/processor integration via Funds Capture Process Profiles. In practice, the most common EBS payment integration runs through CyberSource (Oracle's long-standing payment-partner relationship), which means most EBS customers are effectively single-gateway.
Payment Hub is the gateway- and processor-agnostic alternative: pick any of 19+ gateways (Worldpay, Adyen, Fortis, PayTrace, Stripe, Authorize.Net, NMI, USAePay, plus CyberSource if you want to keep it) without changing the integration. Your existing merchant accounts, processors, and negotiated rates stay. Payment Hub also adds capabilities iPayment doesn't ship, full customer portal payment surface, multi-invoice consolidation, automatic Level III enrichment, surcharging, dunning automation.
Will my Payment Hub investment carry over if I migrate from EBS to Oracle Fusion Cloud ERP?
Yes, and this is one of the strongest reasons to deploy Payment Hub on EBS even if a Cloud ERP migration is on the multi-year roadmap. Payment Hub's configuration is held in Clarity's payment platform, not in EBS source.
The gateway connections, routing rules, surcharging policy, dunning ladder, customer portal customizations, and Level III field mappings carry forward to Oracle Fusion Cloud ERP without re-implementation. The integration surface changes (from REST / SOAP / PL/SQL on EBS to Oracle Cloud REST APIs and OIC on Cloud ERP), but the application-layer configuration ports forward. Many of our EBS go-lives are scoped specifically as bridge deployments, modernize payment now on EBS, ride the integration through to Cloud ERP when the migration completes, all in a single unified payment-modernization storyline.
Does Payment Hub work across the full EBS product family, ERP, SCM, Asset Lifecycle, Service, HCM, Applications Technology?
Yes. Payment Hub integrates across all six EBS product families. ERP Family, Receivables (RA_CUSTOMER_TRX), Payables (AP_INVOICES_ALL), General Ledger, Lease Accounting (Property Manager / IFRS 16 / ASC 842 / GASB 87 / SFFAS 54), Lease and Finance Management, Procurement, iSupplier Portal, Project Costing, Project Billing, G-Invoicing for US Federal, primary integration surface for customer payments.
SCM Family, Order Management, Internal Sales Orders (ISOs), Channel Revenue Management, Warehouse Management, Inventory, Cost Management, Manufacturing, for shipment-triggered captures and configured-to-order deposits. Asset Lifecycle Management, Enterprise Asset Management for asset-leasing recurring payments. Service, Mobile Field Service for per-ticket invoicing. HCM, for employee expense reimbursement scenarios where applicable. Applications Technology, Enterprise Command Centers (ECC) where payment KPIs surface in the Receivables / Payables / GL command centers.
Does Payment Hub work with EBS Enterprise Command Centers (ECC)?
Yes. Enterprise Command Centers, currently at ECC V15 release, are the modern dashboard layer for EBS, providing Receivables Command Center, Payables Command Center, General Ledger Command Center, Procurement Command Center, and others. ECC delivers the Receivables Reconciliation Dashboard (12.2.15 enhancement) for analyzing differences between Receivables subledger and General Ledger balances.
Payment Hub publishes payment events into ECC via the published ECC dataset framework, surcharge yield, L3 yield, gateway uptime, dispute / chargeback flow, retry success rate, recurring MRR all surface alongside EBS's native KPIs. Because ECC updates on a separate cadence from EBS major releases (ECC V15 can run on EBS 12.2.10), Payment Hub's ECC integration runs independently of which EBS minor release you're on.
Does Payment Hub support EBS's multi-Org / multi-ledger / MOAC / SVS architecture?
Yes. EBS's enterprise multi-Org architecture, Operating Units, Ledgers, Legal Entities, Multi-Org Access Control (MOAC), Segment Value Security (SVS), maps directly into Payment Hub's location routing table.
Each Operating Unit (OU) can have its own merchant ID, gateway, bank account, currency, tax setup, and country. Each Ledger maps to its own GL routing. Routing decisions respect MOAC (a transaction's OU determines which MID it routes to) and SVS (segment-value-restricted users see only their authorized segment's transactions in dashboards). For Fortune 500 EBS customers running 25, 50, 100+ OUs across multiple Ledgers and Legal Entities, common in industrial holdings, financial services, federal agencies, Payment Hub's routing matrix scales to match.
Does Level III interchange optimization work for EBS customers?
Yes, and EBS customers tend to have very large absolute L3 savings opportunities because they're typically Fortune 500 / Global 2000 organizations with substantial B2B and B2G commercial-card volume that's been running for years on iPayment / CyberSource without L3 enrichment. Payment Hub automatically pulls line-item data from RA_CUSTOMER_TRX_LINES, OE_ORDER_LINES, and Project Invoice records, then packages the 20+ required L3 fields per gateway / card-brand spec.
Typical EBS customer with $25M in annual B2B card volume recovers $75K–$250K annually. Larger global EBS customers with $100M+ commercial-card volume can recover $500K–$1M+. The retroactive cumulative savings across an EBS install that's been running on a single gateway for years can be substantial when L3 enrichment turns on for the first time.
Does Payment Hub respect EBS customizations, custom Forms, OAF, ADF, PL/SQL, DFFs, custom workflows?
Yes. EBS customers typically have decades of customizations: custom Oracle Forms screens, OAF (OA Framework) extensions, ADF pages, custom PL/SQL packages, custom Descriptive Flexfields (DFFs), custom Approvals Management Engine (AME) rules, custom Workflow Builder routing, custom interface tables, custom Concurrent Programs.
Payment Hub uses Oracle's documented integration surfaces exclusively (REST, SOAP, PL/SQL APIs, Open Interface tables), it doesn't bypass your custom logic. When Payment Hub posts via AR_RECEIPT_API_PUB or AP_INVOICE_API_PUB, your existing custom validations, custom AME approvals, custom DFF defaults, and custom workflow events fire as designed. Where you have custom OAF / ADF UI personalizations, they continue to render normally, Payment Hub doesn't modify the EBS UI layer at all.
Does Payment Hub work with G-Invoicing for US Federal Program Agencies?
Yes. EBS provides G-Invoicing support to 100+ U.S. Federal Program Agencies and 4 shared services (initial use began October 2022 when the G-Invoicing standard went into effect). G-Invoicing handles intragovernmental buy/sell transactions through a centralized common platform.
Payment Hub coexists alongside G-Invoicing, G-Invoicing handles federal-to-federal transactions. Payment Hub handles the federal-to-commercial payment side (vendor payments to federal contractors, federal customer-fee collections, FOIA fee collection, etc.). For agencies running both, the integration surfaces don't conflict: G-Invoicing uses JSON RESTful services for buyer-initiated and seller-initiated orders. Payment Hub uses Oracle's standard REST / SOAP / PL/SQL APIs for the commercial transaction flow.
Does Payment Hub work with EBS's iReceivables and iSupplier Portal?
Yes. iReceivables is EBS's customer-facing self-service portal, customers view invoices, request adjustments, and (with iPayment + CyberSource) make basic payments. Payment Hub embeds a unified payment surface into iReceivables: multi-invoice batch pay, stored credentials, ACH / direct debit, multi-currency, surcharging disclosure, L3 enrichment on commercial cards, and gateway-agnostic flexibility.
The portal continues to render and authenticate through EBS's standard self-service framework. The payment slice is Payment Hub. iSupplier Portal, for supplier-facing transactions including the new 12.2.15 Supplier Broker for Sourcing Negotiations, coexists too. Payment Hub handles the AP rebate refund and supplier-payout flows that supplement what the supplier portal natively provides.
What's the implementation timeline for Oracle E-Business Suite?
A typical Payment Hub + EBS integration goes live in 48 hours once Clarity receives EBS test environment access (database connectivity for PL/SQL APIs or REST/SOAP endpoint access), gateway credentials, and your baseline routing configuration.
For EBS customers with multi-Operating-Unit / multi-ledger / multi-Legal-Entity structures, pilot with one OU / one Ledger in the first 48 hours, then add additional OUs and Ledgers in subsequent batches. For customers planning a phased rollout matching the EBS minor-release upgrade cadence (12.2.13 → 12.2.14 → 12.2.15), Payment Hub follows that cadence and the configuration carries through the EBS upgrades. Your existing EBS license, custom Forms / OAF / ADF customizations, PL/SQL packages, AME rules, Workflow definitions, ECC dashboards, and iPayment configurations all stay intact.