ml-connector
Sage 300PayPal

Sage 300 and PayPal integration

Sage 300 runs your financial records and order entry. PayPal REST APIs handle your payments and orders. Connecting the two keeps your revenue accurate and your order records current. Payments captured in PayPal flow into Sage 300's general ledger without manual re-entry, matched to the customer and GL account for each transaction. Order records from PayPal sync into Sage 300's order entry module so your fulfillment and finance teams work from the same data.

How Sage 300 works

Sage 300 is an on-premise ERP system exposing Accounts Receivable, General Ledger, Order Entry, and Inventory modules through REST and OData APIs. The system exposes key entities including ARCustomers, ARInvoiceBatches, ARReceiptAndAdjustmentBatches, GLAccounts, GLJournalBatches, OEOrders, and ICItems. Access requires HTTP Basic Authentication with uppercase username and password included on every request. Sage 300 has no webhooks or push notifications, so data is read by polling with OData filters on document date and pagination. The API user must be created in Administrative Services with Web API security group assigned, and the IIS server must expose HTTPS without Windows Authentication enabled.

How PayPal works

PayPal REST APIs expose Orders, Captures, Refunds, Invoices, Transactions, Subscriptions, and Payouts through REST endpoints at api-m.paypal.com. Authentication uses OAuth 2.0 Client Credentials grant, with a bearer token cached and reused across multiple requests. PayPal can also push transaction and order events to registered webhook endpoints with RSA-SHA256 signature verification. Key limitations include a 31-day window on transaction search, maximum 500 results per page, and no native GL account or vendor registry objects. Refunds must be issued against captures, not orders directly, and invoices require a dedicated send endpoint to notify recipients.

What moves between them

PayPal orders and payment transactions flow into Sage 300. After a PayPal order is captured, ml-connector reads the order and capture records via the Transactions API, then posts the payment amount as a receipt into Sage 300's ARReceiptAndAdjustmentBatches, matched to the PayPal customer email in Sage 300's ARCustomers. Order records from PayPal flow into Sage 300's OEOrders module so fulfillment staff can see which PayPal orders have been captured. Refunds and disputes flow in the same direction so the AR team can post credit memos against the original customer invoice. The sync runs on a schedule you control, typically hourly or daily, and all records are reconciled to avoid re-processing the same PayPal transaction twice.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For PayPal, it exchanges the OAuth 2.0 CLIENT_ID and CLIENT_SECRET at token-endpoint on the first request, caches the bearer token, and refreshes it when a call returns 401. For Sage 300, it includes the HTTP Basic Authentication header (base64-encoded USERNAME:PASSWORD in uppercase) on every request. Because Sage 300 has no webhooks and PayPal's webhook system is optional, ml-connector polls both systems on a schedule tied to your settlement or AR reconciliation cycle. It reads PayPal transactions within a sliding window to catch late captures and refunds, maps the PayPal customer email to the matching Sage 300 ARCustomer record, and posts the payment as a receipt batch using the correct GL account and AR account set. Captures that PayPal marks as refunded are excluded from the receipt batch. The integration tracks PayPal transaction IDs and Sage 300 receipt batch numbers to prevent duplicate posts. Rate limits on the PayPal side return HTTP 429, so ml-connector backs off and retries with jitter. Every record carries a full audit trail and can be replayed if a Sage 300 post fails.

A real-world example

A mid-sized e-commerce business runs Sage 300 on-premise for order entry, invoicing, and accounting, and accepts payments through PayPal REST APIs for customer orders. Before the integration, the finance team pulled a transaction report from PayPal each day, matched payment email addresses to Sage 300 customer codes by hand, and entered the payment amounts into Sage 300 as AR receipts. This process was error-prone, slow, and left a gap between when PayPal captured the payment and when the AR team could reconcile it. With PayPal and Sage 300 connected, each captured payment flows into Sage 300 automatically within an hour, matched to the correct customer and GL account. Refunds and disputes are posted as credit memos automatically. The AR reconciliation step that used to take a full day now completes in minutes, and there is no manual re-keying.

What you can do

  • Read PayPal orders and capture transactions via OAuth 2.0 and post them into Sage 300's order entry and AR receipt batches on a schedule you control.
  • Map PayPal customer email addresses to Sage 300 ARCustomer records and GL accounts so payments land on the correct revenue account.
  • Handle HTTP Basic Authentication with uppercase credentials for Sage 300 and OAuth 2.0 token refresh and caching for PayPal.
  • Track PayPal transaction IDs and Sage 300 batch numbers to prevent duplicate receipt posts when the schedule overlaps.
  • Encrypt both credential sets, poll on a reconciliation schedule, back off and retry on rate limits, and carry a full audit trail on every payment record.

Questions

Which direction does data move between Sage 300 and PayPal REST APIs?
The main flow is PayPal into Sage 300. Captured payments, orders, and refunds move from PayPal into Sage 300's order entry and AR modules. Sage 300 is the system of record for invoices and customer master data, so ml-connector reads from Sage 300 only to match customer email addresses and GL accounts for incoming PayPal records. No data flows back from Sage 300 into PayPal.
How does the integration handle Sage 300's HTTP Basic Authentication requirement and uppercase credentials?
ml-connector stores the Sage 300 username and password encrypted. On every API request, it converts both to uppercase (as the Sage 300 API requires) and sends them base64-encoded in the Authorization header. The Sage 300 API user must be created in Administrative Services with the Web API security group assigned so the request succeeds.
How often should the integration poll PayPal and Sage 300?
ml-connector runs on a schedule you set, typically hourly for real-time AR reconciliation or daily for batch AR processing. Because PayPal transactions can be refunded or disputed after capture, the integration reads PayPal transactions within a sliding window (typically the last 24-48 hours) and checks Sage 300 batch numbers to prevent duplicate posts if the same transaction appears twice in overlapping windows.

Related integrations

Connect Sage 300 and PayPal

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

Get started