Which direction does data move between Sage 300 and Square?

The main flow is Square into Sage 300. Orders, payments, and customer records move from Square into Sage 300's Accounts Receivable and General Ledger. Sage 300 invoices are read for reconciliation but not written back to Square, since Square is a commerce layer only and has no GL Accounts endpoint.

How does the integration handle Sage 300's HTTP Basic Auth requirement and uppercase credentials?

ml-connector stores Sage 300 credentials encrypted and converts them to uppercase before base64-encoding and including them in every API request's Authorization header. The API user must be created in Sage 300's Administrative Services with Web API security group assigned; the built-in Admin user lacks API privileges.

How does ml-connector handle Square's 30-day access token expiry and webhook verification?

ml-connector obtains an OAuth Bearer token via the Authorization Code flow and automatically refreshes it using the non-expiring refresh token before the 30-day window closes. For webhooks, it verifies the x-square-hmacsha256-signature header on every push notification so spoofed or altered events are rejected before they reach Sage 300.

Sage 300Square

Sage 300 and Square integration

Sage 300 handles accounting and operations for mid-market businesses, while Square powers point-of-sale and payments. Connecting them keeps your order records and customer receivables aligned. Orders created in Square post directly into Sage 300's Order Entry or General Ledger, customer payments in Square flow into Sage 300's cash receipts, and invoice batches created in Sage 300 can be synced back to Square for unified visibility. ml-connector manages the very different APIs on each side and moves the data on a schedule you control.

How Sage 300 works

Sage 300 is an on-premise ERP exposing Accounts Payable, Accounts Receivable, General Ledger, Purchase Orders, Orders, and Inventory through REST and OData APIs served from a customer-managed IIS server with SQL Server backend. Every request requires HTTP Basic Authentication with a base64-encoded USERNAME:PASSWORD header, and both credentials must be uppercase. The API accepts OData query parameters for filtering and pagination ($filter, $orderby, $skip, $top). Sage 300 has no webhooks or push notifications; all sync is pull-based via polling with date/time filters on a scheduled cadence. Master data endpoints support full CRUD operations, while transaction batches accept reads and inserts only.

How Square works

Square exposes payments, invoices, orders, customers, inventory, and vendors through a versioned REST API at connect.squareup.com/v2, authenticating with OAuth 2.0 Bearer tokens or Personal Access Tokens. Access tokens expire in 30 days and must be refreshed via non-expiring refresh tokens. Square publishes push notifications through webhooks for payment.created, payment.updated, invoice.created, invoice.published, order.created, and customer.created events, with HMAC-SHA256 signature verification via the x-square-hmacsha256-signature header. The Vendors API is beta; Purchase Orders are modeled through Orders and Vendor references, and there is no Chart of Accounts endpoint, so Square remains a commerce layer only.

What moves between them

Orders and payments flow from Square into Sage 300's Accounts Receivable and General Ledger on a schedule synchronized with your payment processing cadence. When an order is created or a payment is processed in Square, ml-connector reads those records and posts matching invoices and cash receipt batches into Sage 300. Customer records created or updated in Square sync into Sage 300's ARCustomers endpoint. The sync is one-way: Sage 300 invoices are read from ARInvoiceBatches and can be queried for reconciliation, but updates are not written back to Square. Inventory adjustments in Square can also trigger corresponding updates in Sage 300's ICItems when quantities change.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For Square, it obtains an OAuth Bearer token via the Authorization Code flow and refreshes it before the 30-day expiry window, listening for webhook notifications on payment.created and invoice.published events and verifying signatures via the x-square-hmacsha256-signature header. For Sage 300, it encodes credentials in uppercase and submits them with every HTTP Basic Auth request to the customer's IIS server, using OData $filter parameters to poll for new or updated orders and payments since the last sync run. Customer records are mapped first so invoices land on valid ARCustomers, and cost centers or GL accounts are aligned if order tags or metadata contain Sage 300 dimension codes. Sage 300's IIS AppPool can timeout under high-volume polling (1500+ calls); ml-connector includes exponential backoff and retry logic with per-request timeouts to navigate this. Every record carries a full audit trail and can be replayed if a downstream Sage 300 post fails.

A real-world example

A mid-sized retail chain runs Square for point-of-sale and payments across 15 store locations and an online shop, and uses Sage 300 on-premise for accounting and inventory. Before the integration, the operations team exported Square payment summaries each morning and manually entered corresponding invoices into Sage 300's Accounts Receivable, then spent hours each month reconciling totals and tracking missing customer records. With Sage 300 and Square connected, each day's Square orders and payments post automatically into Sage 300's receivables and GL, mapped to the correct store and payment method, and customer records sync so headcount and cash application never drift. Month-end close now starts with AR already reconciled to Square.

What you can do

Sync Square orders and payments into Sage 300 Accounts Receivable and General Ledger on a scheduled cadence.
Map Square customers to Sage 300 ARCustomers, keeping customer records and credit terms aligned.
Authenticate Square via OAuth 2.0 Bearer tokens with automatic refresh before 30-day expiry, and Sage 300 via HTTP Basic Auth with uppercase credentials.
Handle Square webhook signatures via HMAC-SHA256 verification and Sage 300 polling via OData date filters and pagination.
Replay failed invoices and cash receipts with a full audit trail, backed off and retried if Sage 300 IIS encounters timeouts.

Questions

Which direction does data move between Sage 300 and Square?: The main flow is Square into Sage 300. Orders, payments, and customer records move from Square into Sage 300's Accounts Receivable and General Ledger. Sage 300 invoices are read for reconciliation but not written back to Square, since Square is a commerce layer only and has no GL Accounts endpoint.
How does the integration handle Sage 300's HTTP Basic Auth requirement and uppercase credentials?: ml-connector stores Sage 300 credentials encrypted and converts them to uppercase before base64-encoding and including them in every API request's Authorization header. The API user must be created in Sage 300's Administrative Services with Web API security group assigned; the built-in Admin user lacks API privileges.
How does ml-connector handle Square's 30-day access token expiry and webhook verification?: ml-connector obtains an OAuth Bearer token via the Authorization Code flow and automatically refreshes it using the non-expiring refresh token before the 30-day window closes. For webhooks, it verifies the x-square-hmacsha256-signature header on every push notification so spoofed or altered events are rejected before they reach Sage 300.

Connect Sage 300 and Square

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

Get started