Visma and BigCommerce integration

What moves between them

Orders and customers flow from BigCommerce into Visma. Each BigCommerce order triggers a webhook; ml-connector fetches the full order details and creates a customer invoice in Visma, mapped to the correct customer account and GL accounts for revenue. Customer records from BigCommerce are synced to Visma customer accounts to keep the source of truth aligned. Order refunds and adjustments flow the same direction. No data flows back from Visma to BigCommerce; the connection is read-only on the Visma side and write-only on the BigCommerce ingest.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For BigCommerce, it uses the static API key in the X-Auth-Token header; for Visma, it obtains an OAuth 2.0 token via client credentials against Visma Connect and includes the ipp-company-id header on all Visma calls. Because BigCommerce webhooks contain only stubs, ml-connector immediately calls the REST API to fetch the full order and customer records. It handles BigCommerce's rate limits with backoff and retry, and tracks webhook deliverability so re-registration occurs before webhooks auto-deactivate. On the Visma side, ml-connector must fetch the current ETag on a customer or invoice before updating it (optimistic locking via If-Match header), and it handles token expiry by obtaining a fresh token without requiring a refresh token. Customer dimension mappings are configured so order totals land on the correct GL accounts. Every record carries an audit trail and can be replayed if a Visma call fails.

A real-world example

A Nordic e-commerce merchant runs BigCommerce for a multi-channel online storefront and Visma.net ERP for accounting and financial reporting. Previously, finance staff manually exported orders from BigCommerce each day and created invoices in Visma by hand, reconciling payment terms and customer accounts each month-end. With the integration live, each BigCommerce order automatically generates a customer invoice in Visma within seconds of purchase, customers are synced to keep the chart of accounts current, and revenue is recognized in the general ledger in real-time. Month-end close begins with customer invoices already posted, and the manual export-and-entry step is eliminated.

What you can do

• •Sync BigCommerce orders into Visma as customer invoices, allocated to the correct GL revenue accounts.
• •Keep Visma customer master aligned with BigCommerce customer records and email addresses.
• •Fetch full BigCommerce order details immediately when webhooks are received, since BigCommerce webhook payloads contain only stubs.
• •Authenticate BigCommerce with static API keys and Visma with OAuth 2.0 client credentials, handling token expiry and refresh.
• •Manage Visma optimistic locking via ETag headers, rate limit backoff on both platforms, and maintain a complete audit trail.

Questions

Which direction does data move between BigCommerce and Visma?

Orders and customers flow from BigCommerce into Visma. Each BigCommerce order becomes a customer invoice in Visma, and customer records are synced to keep Visma's customer master current. No data flows back from Visma to BigCommerce; the integration is read-only on the Visma side.

Why must ml-connector fetch the full order details if BigCommerce sends a webhook?

BigCommerce webhooks contain only the entity ID and event type, not the full record. ml-connector must immediately call the BigCommerce REST API to fetch the complete order, customer, and transaction details so it can map all fields correctly into Visma. This avoids incomplete invoices.

How does the integration handle Visma's ETag locking and token expiry?

On updates, ml-connector fetches the current ETag before sending a PUT request (optimistic locking via If-Match header) to prevent race conditions. For token expiry, Visma does not issue refresh tokens to service applications, so ml-connector obtains a fresh OAuth token from Visma Connect whenever the current token is rejected with 401.