QAD and Stripe integration

What moves between them

Data moves in both directions. From QAD into Stripe, ml-connector pushes customer records and open AR invoices so Stripe can bill and collect them. From Stripe back into QAD, it reads paid invoices, succeeded payments, refunds, and completed payouts and posts them as customer cash receipts and reconciliation entries against the matching QAD accounts. Balance transactions are read to reconcile Stripe fees and net deposits. Payment-side events arrive through Stripe webhooks for fast updates, and a scheduled poll backfills any events that were missed, since QAD cloud cannot receive pushes itself.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Stripe side it sends the secret API key over HTTPS on every call, and a restricted key can be used to limit the connector to invoices, customers, and payments. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base URL, and validates entity paths against that instance. Stripe customers are matched to QAD customer records by email and metadata so payments land on the right account, and amounts are converted from Stripe's smallest-unit values into QAD currency amounts. Stripe webhooks are verified against the endpoint secret using the raw request body before anything is processed, events are deduplicated on the event id, and the current object is re-fetched from the API because Stripe events are unordered and at-least-once. Because QAD cloud is pull-only, scheduled polling backfills any gaps. Stripe rate limits return HTTP 429, so ml-connector backs off and retries, every outbound write carries an idempotency key so a retry is never double-charged, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized equipment maker runs QAD Adaptive ERP for production, inventory, and finance, and sells spare parts and service plans online through Stripe. Before the integration, a clerk exported Stripe payouts and payment reports each week and keyed the receipts into QAD by hand, then spent time at month-end matching Stripe deposits to open receivables and backing out processing fees. With QAD and Stripe connected, open AR invoices flow from QAD to Stripe for collection, and each paid invoice, payment, and payout flows back into QAD against the right customer, with Stripe fees reconciled from balance transactions. The weekly re-keying disappears and cash matches receivables without the month-end chase.

What you can do

• •Push QAD customers and open AR invoices into Stripe so they can be billed and collected.
• •Post Stripe paid invoices, succeeded payments, and refunds back into QAD as customer cash receipts.
• •Reconcile Stripe payouts and processing fees against QAD using balance transactions.
• •Receive Stripe webhooks for fast settlement updates and backfill any gaps with scheduled polling.
• •Authenticate Stripe with its secret API key and QAD with its tenant-specific token, with retries and a full audit trail.

Questions

Which direction does data move between QAD and Stripe?

Data moves both ways. QAD customers and open AR invoices flow out to Stripe so they can be charged, and Stripe paid invoices, payments, refunds, and payouts flow back into QAD as cash receipts and reconciliation entries. Stripe balance transactions are read to reconcile fees and net deposits against the QAD ledger.

Does Stripe use OAuth, and how does ml-connector authenticate?

For standard server-to-server use Stripe does not use OAuth; it authenticates with a secret API key sent over HTTPS. ml-connector stores that key encrypted and sends it on every Stripe call, and a restricted key can scope the connector to only invoices, customers, and payments. On the QAD side it uses the tenant-specific JWT or OAuth2 token against each customer's instance URL.

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

Stripe pushes signed webhook events for payments, invoices, and payouts, so ml-connector verifies each event against the endpoint secret using the raw body, deduplicates on the event id, and re-fetches the current object because Stripe events are unordered and at-least-once. Because QAD cloud cannot receive pushes, a scheduled poll backfills any missed events and reads QAD records on a cadence you control.