SANDBOX — test deployment of the website. Nothing here is real.

Developers / Guides / Integrations

Accounting, CRM and store sync

PayMidWare keeps a merchant's accounting system, CRM or online store in step with its customers and invoices. Every connection is opt-in per merchant and does nothing until the merchant connects it. Connecting needs the other system's own sign-in screen, so it is always done in the Portal; the API reads status, starts a sync and disconnects.

QuickBooks Online sync

Keep a merchant's customers and invoices in sync with their own QuickBooks Online company — so you don't have to hand-build a QuickBooks integration on top of PayMidWare's invoicing. This is opt-in per merchant and does nothing until a merchant connects.

What syncs to QuickBooks

Customers and invoices push automatically — a customer is created, an invoice is sent, or an invoice is paid — best-effort, the same way an invoice-sent email goes out. When a PayMidWare invoice is paid, that payment is also recorded against the matching invoice in QuickBooks.

What pulls back from QuickBooks

Invoice status only. If an invoice is marked paid directly inside QuickBooks (e.g. a check recorded there, never through the pay portal), that reflects back as Paid in PayMidWare on the next background check. Nothing else flows QuickBooks → PayMidWare.

Connecting a merchant

Establishing the connection needs a real sign-in to QuickBooks' own consent screen, so it's done from the Admin Portal only — there's no API endpoint that can complete this step.

Open the merchant's QuickBooks page

/Merchants → your merchant → QuickBooks

Connect to QuickBooks

Click Connect to QuickBooks and sign in to the QuickBooks company you want this merchant linked to. You're redirected straight back to the same page once you approve access.

Check status, sync now, or disconnect

The page shows the connected company, environment, and the result of the last sync attempt. Sync now pushes every not-yet-synced customer/invoice and pulls the latest invoice statuses in one pass — the same operation that otherwise runs automatically and on a background timer. Disconnect stops syncing immediately; reconnect any time.

API endpoints

EndpointPurpose
GET /api/merchant-accounts/{ref}/quickbooksConnection status — company, environment, last sync result.
POST /api/merchant-accounts/{ref}/quickbooks/sync-nowPush everything unsynced, then pull invoice status. Same as the Portal's "Sync now."
POST /api/merchant-accounts/{ref}/quickbooks/sync-customersPull the company's customers into PayMidWare (and push unsynced ones). Customer matching uses the account number when there is one.
POST /api/merchant-accounts/{ref}/quickbooks/disconnectDisconnect this merchant's QuickBooks company.

There's no API endpoint to connect a merchant — that step always happens in the Admin Portal (see above).

Things to know before relying on this in production: an invoice line linked to a catalog product (productId) is booked against that product's QuickBooks item; a free-text line, or a product not linked yet, falls back to one shared default Item. Products can be imported from and pushed to QuickBooks, and tax rates are imported from it (never written back). Tax goes to QuickBooks as its own "Sales Tax" line so the QuickBooks total matches PayMidWare's to the cent; a company on QuickBooks automated sales tax may recompute it and show a different total (PayMidWare logs the difference). And the sync assumes the connected QuickBooks company runs in a single (home) currency — a multi-currency company isn't handled yet.

QuickBooks Desktop sync

The same idea as QuickBooks Online, for a merchant who runs QuickBooks Desktop on their own computer. The merchant's Desktop company is reached through a connector, so the merchant (or you) sets the connection up in the Admin Portal at /Merchants → your merchant → QuickBooks Desktop; there is no API call to connect.

Customers, invoices and payments push across, products sync with Desktop items, tax rates are read from Desktop sales-tax items, and an invoice marked paid in QuickBooks reflects back as Paid. Desktop limits some names to 31 characters, so longer names are shortened on the way out.

EndpointPurpose
GET /api/merchant-accounts/{ref}/quickbooks-desktopConnection status and the last sync result.
POST .../quickbooks-desktop/sync-nowPush everything unsynced, then pull invoice status.
POST .../quickbooks-desktop/sync-customersPull the Desktop company's customers.
POST .../quickbooks-desktop/disconnectDisconnect.

Salesforce sync

Keeps a merchant's customers and invoices in their own Salesforce org, using only standard objects — no custom setup in Salesforce.

A customer becomes a Salesforce Account and an invoice becomes an Opportunity. When an invoice is paid in full, its Opportunity moves to the configured "won" stage (Closed Won by default); and if a rep moves the Opportunity to that stage in Salesforce, the invoice is marked paid in PayMidWare. Connecting needs Salesforce's own sign-in screen, so it is done in the Portal (/Merchants → your merchant → Salesforce).

EndpointPurpose
GET /api/merchant-accounts/{ref}/salesforceConnection status and last sync result.
POST .../salesforce/sync-nowPush everything unsynced and pull stage changes.
POST .../salesforce/disconnectDisconnect.

HubSpot, Dynamics 365, Zoho CRM & NetSuite

Four more CRM add-ons that work exactly like Salesforce: customers become accounts, sent invoices become deals, and a deal won on either side is reflected on the other.

A customer becomes a Company (HubSpot), Account (Dynamics 365, Zoho CRM) or Customer (NetSuite). An invoice becomes a Deal (HubSpot, Zoho) or an Opportunity (Dynamics 365, NetSuite). When an invoice is paid in full, its deal moves to the won stage; if a rep marks the deal won in the CRM, the invoice is marked paid in PayMidWare. Each CRM is its own billable add-on, and a merchant can connect several at once. Connecting needs the CRM's own sign-in screen, so it is done in the Portal (/Merchants → your merchant → the CRM). {crm} is hubspot, dynamics365, zoho or netsuite.

EndpointPurpose
GET /api/merchant-accounts/{ref}/crmConnection status for all four.
GET .../crm/{crm}Connection status and last sync result for one.
POST .../crm/{crm}/sync-nowPush everything unsynced and pull won deals.
POST .../crm/{crm}/disconnectDisconnect.

BigCommerce & WooCommerce

These two work the other way round from the accounting integrations: the merchant's online store is the source of truth, and PayMidWare pulls orders in so their sales show up alongside everything else. Nothing is ever written back to the store.

  • Only orders the store already counts as paid are pulled in, and each arrives as a customer plus an invoice that is already Paid. An unpaid, on-hold, cancelled or failed order is skipped, so no order ever gets a second way to pay.
  • Customers are matched by the store's own customer id, or by email for a guest checkout, so a returning shopper is not duplicated.
  • BigCommerce is connected by installing the PayMidWare app from the merchant's BigCommerce control panel. WooCommerce is connected by the merchant entering their store address and a WooCommerce API key under /Merchants → your merchant → WooCommerce (or POST .../woocommerce/connect).
  • A refund made in the store after the order was pulled in does not reduce the invoice's paid amount.
EndpointPurpose
GET /api/merchant-accounts/{ref}/bigcommerceConnection status and last sync result.
POST .../bigcommerce/sync-nowPull new orders now.
POST .../bigcommerce/disconnectDisconnect.
GET /api/merchant-accounts/{ref}/woocommerceConnection status and last sync result.
POST .../woocommerce/connectConnect a store (store address and API key).
POST .../woocommerce/sync-nowPull new orders now.
POST .../woocommerce/disconnectDisconnect.