Which direction does data move between QAD and PayPal?

It runs both ways. Approved supplier invoices move from QAD into PayPal as payouts, while settled payment amounts, refunds, and fees move from PayPal back into QAD's general ledger and onto the invoice as a status. PayPal is the system of record for payment execution and QAD for accounting, so ml-connector never writes financial entries back into PayPal.

How does the integration handle PayPal webhooks and QAD's lack of webhooks?

PayPal pushes signed events such as PAYMENT.CAPTURE.COMPLETED and payout events, which ml-connector verifies using the certificate from the paypal-cert-url and an RSA-SHA256 check before posting to QAD. Because QAD cloud is pull-only with no webhook system, QAD is read by polling on a schedule you control, and a scheduled pass backfills anything a webhook missed.

QADPayPal

QAD and PayPal integration

QAD runs manufacturing and finance. PayPal moves money through payouts, payments, and invoicing. Connecting the two lets QAD pay approved supplier invoices through PayPal Payouts and pulls the settled payment and fee activity back into the general ledger without re-keying. When a QAD AP invoice is approved, ml-connector sends a payout to the supplier's PayPal account and stamps it with the QAD bill number, then records the result and the processing fee back in QAD. ml-connector handles the very different APIs on each side and reconciles payment activity to the ledger on the cadence you set.

How QAD works

QAD Adaptive ERP exposes suppliers, purchase orders, supplier invoices, GL accounts, cost centers, items, goods receipts, and AP payments through REST business document APIs, documented in Swagger inside each customer instance. The cloud product authenticates with a JWT session or OAuth2 bearer token against a tenant-specific URL, so there is no shared hostname. Older on-premise sites run QAD Enterprise Edition with the QXtend SOAP framework instead. QAD has no public webhook system for cloud connectors, so finance records are read by polling, and supplier invoices post only after the goods receipt for a three-way match.

How PayPal works

PayPal is a payments platform, not an accounting system, so it has no native vendor, purchase order, or GL account objects. It exposes payouts, orders, payments and captures, invoicing, subscriptions, and transaction search through REST APIs that mix v1 and v2 base paths. Every call carries an OAuth 2.0 bearer token, obtained by sending a Base64-encoded client id and secret to the token endpoint with HTTP Basic auth; the token lasts about eight hours and must be cached and reused. PayPal pushes events such as PAYMENT.CAPTURE.COMPLETED, PAYMENT.CAPTURE.REFUNDED, and invoice events by webhook, signed with RSA-SHA256 rather than HMAC. Transaction search is read-only and limited to a 31-day window per request.

What moves between them

Two flows run. Outbound, ml-connector reads approved QAD supplier invoices and pays each one through PayPal Payouts to the supplier's PayPal email, carrying the QAD bill number in the batch so the payment can be traced. Inbound, it reads PayPal captures and transaction search results and posts the settled amounts, refunds, and processing fees into QAD's general ledger against the matching GL accounts and cost centers, and writes the payment status back onto the QAD invoice. Payout and capture webhooks trigger the inbound work as money settles, and a scheduled poll backfills anything a webhook missed. PayPal is treated as the system of record for payment execution and QAD for accounting, so financial entries are never written back into PayPal.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For PayPal it requests a bearer token by sending the Base64-encoded client id and secret to the token endpoint, then caches the token for its roughly eight-hour life and reuses it rather than authenticating per call, since PayPal throttles abusive traffic with HTTP 429. On the QAD side it accepts the full tenant URL per customer, because QAD publishes no shared base URL, and validates entity paths against that instance. Every payout carries a PayPal-Request-Id and a unique sender_batch_id so a retried send never double-pays a supplier, and payouts require the recipient to hold a PayPal account, so suppliers without one are flagged rather than paid. Inbound webhooks are verified by fetching PayPal's certificate from the paypal-cert-url, confirming it is a paypal.com address, and checking the RSA-SHA256 signature before anything posts. Transaction search is read in 31-day windows because that is the maximum range per request, and an initial backfill loops across windows. GL accounts and cost centers are mapped first so every journal line lands on a valid QAD dimension, and because QAD cloud is pull-only it is polled on a schedule rather than pushed to. Every record carries a full audit trail and can be replayed if a QAD post or a payout fails.

A real-world example

A mid-sized contract manufacturer running QAD Adaptive ERP pays a long tail of small overseas suppliers and freelancers who prefer PayPal over wire transfers. Before the integration, the AP team approved bills in QAD, then logged into PayPal to create each payout by hand and later re-entered the amounts and fees back into the ledger, which was slow and easy to mis-key on a busy run. With QAD and PayPal connected, approved invoices are paid through PayPal Payouts automatically, each stamped with its QAD bill number, and the settled amounts and processing fees flow back into QAD against the right accounts. The duplicate data entry is gone and the team can see which bills are paid without leaving QAD.

What you can do

Pay approved QAD supplier invoices through PayPal Payouts, stamped with the QAD bill number for traceability.
Post PayPal captures, refunds, and processing fees into QAD's general ledger against the correct GL accounts and cost centers.
Write PayPal payment status back onto the matching QAD supplier invoice.
Receive PayPal payout and capture webhooks, verified by RSA-SHA256, and act on them as money settles.
Authenticate PayPal with a cached OAuth 2.0 bearer token and QAD with its tenant-specific token, with retries and a full audit trail on every record.

Questions

Which direction does data move between QAD and PayPal?: It runs both ways. Approved supplier invoices move from QAD into PayPal as payouts, while settled payment amounts, refunds, and fees move from PayPal back into QAD's general ledger and onto the invoice as a status. PayPal is the system of record for payment execution and QAD for accounting, so ml-connector never writes financial entries back into PayPal.
Can PayPal pay QAD supplier invoices directly?: PayPal has no purchase order or vendor objects, so the invoice itself is not sent to PayPal. Instead ml-connector reads the approved bill in QAD and creates a PayPal payout to the supplier's PayPal email, carrying the QAD bill number as a reference. The payout requires the supplier to have a PayPal account; suppliers without one are flagged rather than paid, since PayPal payouts have no native ACH or wire support.
How does the integration handle PayPal webhooks and QAD's lack of webhooks?: PayPal pushes signed events such as PAYMENT.CAPTURE.COMPLETED and payout events, which ml-connector verifies using the certificate from the paypal-cert-url and an RSA-SHA256 check before posting to QAD. Because QAD cloud is pull-only with no webhook system, QAD is read by polling on a schedule you control, and a scheduled pass backfills anything a webhook missed.

Connect QAD and PayPal

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

Get started