Which direction does data move between Visma and Square?

The primary flow is Square into Visma. Payments, refunds, orders, and invoices move from Square into Visma's general ledger and accounts payable, mapped to the correct GL accounts and cost centers. Reference data such as vendors and locations can be synchronized in both directions for mapping validation. GL postings and customer invoices are read-only in Square, so ml-connector does not write financial entries back.

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

ml-connector refreshes Square access tokens automatically every 29 days using the non-expiring refresh token from the OAuth2 Authorization Code flow. For Visma, new OAuth2 tokens are obtained on demand since Visma service applications do not receive refresh tokens. Both token sets are stored encrypted and rotated transparently.

How are Square webhooks verified and what happens if Visma webhooks fail?

Square webhooks are verified against the HMAC-SHA256 signature in the x-square-hmacsha256-signature header on every request; invalid signatures return a 401. Because Visma webhooks are one-time delivery without automatic retry, ml-connector polls Square on a configurable schedule to ensure no transactions are missed, and it can also consume the Square webhook stream for near-real-time updates where enabled.

VismaSquare

Visma and Square integration

Visma.net ERP runs accounting and finance. Square runs commerce, payments, and point-of-sale. Connecting the two keeps your accounting ledger in sync with your payment transactions without manual entry. Every Square payment, order, and invoice flows into Visma's accounts payable and general ledger, mapped to the correct GL accounts, cost centers, and vendors. ml-connector handles the very different APIs on each side and moves the data as it happens or on a schedule you define.

How Visma works

Visma.net ERP exposes suppliers, invoices, purchase orders, customers, accounts, dimensions, journals, and employees through a REST API over HTTPS. The platform uses OAuth2 client credentials for service integrations via Visma Connect, requiring client_id, client_secret, and tenant_id. All API calls must include the ipp-company-id header. Visma supports both webhooks (one-time delivery without automatic retry) and polling via lastModifiedDateTime query parameters. Webhook events must be explicitly enabled in company settings, and test clients are rate-limited to 500 calls per hour per company. Access tokens are not refreshed for service applications, so new tokens must be obtained on expiry.

How Square works

Square exposes payments, refunds, invoices, orders, vendors, customers, inventory, and team members through a versioned REST API. Authentication uses OAuth2 with Authorization Code flow or Personal Access Tokens, both sent as Bearer tokens. Access tokens expire every 30 days and require refresh-token handling. Square publishes webhooks for payment events, invoice lifecycle, order updates, customer changes, catalog versions, and inventory adjustments, with payload integrity verified via HMAC-SHA256 signatures. The Vendors API is in beta. Square does not expose a GL accounts or chart of accounts API, making it a commerce layer only. Inventory is read and write for adjustments but cannot create items directly.

What moves between them

The primary flow moves from Square into Visma. Square payments, orders, and invoices are synchronized into Visma's accounts payable and general ledger on a schedule tied to your commerce cadence or in real time via webhooks. Vendors from Square Vendors API can map to Visma suppliers. Reference data such as locations, merchants, and payment methods are aligned in both directions so transactions land on valid GL accounts and cost centers. GL postings and customer invoices are read-only in Square, so ml-connector does not write financial entries back to the payment platform.

How ml-connector handles it

ml-connector stores both credential sets encrypted and refreshes Square access tokens automatically every 29 days to prevent expiry during a sync. For Visma, it obtains new OAuth2 tokens on demand since refresh tokens are not issued to service apps. It accepts the Square location ID per customer and validates all Visma GL accounts and cost center dimensions before attempting a post. Square webhooks are verified against the HMAC-SHA256 signature in every request header; invalid signatures return a 401. Because Visma webhooks are one-time delivery without retry, ml-connector polls Square on a configurable schedule and uses the Square webhook stream where enabled for near-real-time updates. All gl postings carry the source Square payment or order ID so they can be traced back to the original transaction. Every record carries a full audit trail and can be replayed if a downstream post fails.

A real-world example

A multi-location retailer operates Square point-of-sale across ten stores and a web channel, and uses Visma.net ERP for accounting and AP management across the Nordic region. Before the integration, the accounting team exported daily payment summaries from Square and manually entered them into Visma's general ledger, a process that delayed daily close by hours and introduced re-entry errors. With Square and Visma connected, each payment, order, and refund flows automatically into the correct GL accounts and cost centers by location within minutes. Month-end close now includes accurate daily payment detail from day one, and the manual entry step is eliminated.

What you can do

Post Square payments and refunds into Visma's general ledger, allocated to the correct GL account and cost center per location.
Sync Square orders and invoices into Visma accounts payable and customer AR, with vendor and customer mapping.
Validate webhook signatures from Square using HMAC-SHA256 and automatically retry failed GL postings.
Authenticate Square with OAuth2 and handle 30-day access token expiry, and Visma with Visma Connect service credentials.
Poll Square on a schedule or consume real-time webhooks, with a full audit trail and GL posting history for every transaction.

Questions

Which direction does data move between Visma and Square?: The primary flow is Square into Visma. Payments, refunds, orders, and invoices move from Square into Visma's general ledger and accounts payable, mapped to the correct GL accounts and cost centers. Reference data such as vendors and locations can be synchronized in both directions for mapping validation. GL postings and customer invoices are read-only in Square, so ml-connector does not write financial entries back.
How does ml-connector handle Square's 30-day access token expiry?: ml-connector refreshes Square access tokens automatically every 29 days using the non-expiring refresh token from the OAuth2 Authorization Code flow. For Visma, new OAuth2 tokens are obtained on demand since Visma service applications do not receive refresh tokens. Both token sets are stored encrypted and rotated transparently.
How are Square webhooks verified and what happens if Visma webhooks fail?: Square webhooks are verified against the HMAC-SHA256 signature in the x-square-hmacsha256-signature header on every request; invalid signatures return a 401. Because Visma webhooks are one-time delivery without automatic retry, ml-connector polls Square on a configurable schedule to ensure no transactions are missed, and it can also consume the Square webhook stream for near-real-time updates where enabled.

Connect Visma and Square

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

Get started