Does ml-connector support both Visma.net and Visma Severa, or is it Visma.net only?

This integration targets Visma.net ERP specifically, which uses the OAuth 2.0 Visma Connect authentication flow. Visma Severa is a separate cloud product with its own REST API contract and is not included in this integration. If you run Severa instead, it requires a separate connector build.

What happens if a PayPal webhook fails to deliver?

PayPal webhooks are one-time delivery with no automatic retry guarantee. ml-connector compensates by polling the PayPal transaction API on a fixed schedule within the 31-day lookback window. If a webhook fails, the transaction is caught by the next poll cycle, ensuring no payments are orphaned. Every record carries a source ID linking back to PayPal for audit purposes.

Can payments be allocated to different Visma GL accounts and cost centers per transaction?

Yes. ml-connector accepts a mapping table (PayPal transaction type, amount range, or customer group) to different Visma GL accounts and dimensions. Before posting, every GL account and dimension is validated against the live Visma instance. If an account is inactive or a customer dimension does not exist in Visma, the transaction is flagged for review rather than posted in error.

VismaPayPal

Visma and PayPal integration

Visma.net ERP manages your financial records across AP, AR, purchasing, and the general ledger. PayPal processes payments, invoices, and refunds. Connecting the two keeps your payment records synchronized without manual data entry. Every PayPal transaction can post to Visma's GL, customer payments reconcile automatically, and invoice adjustments flow both directions. ml-connector handles the OAuth dance on both platforms and ensures every record lands on a valid GL account and dimension in Visma.

How Visma works

Visma.net ERP exposes customers, invoices, GL accounts, dimensions, journal transactions, and financial records through REST APIs using OAuth 2.0 credentials. The platform authenticates via Visma Connect service account credentials (client_id, client_secret, tenant_id) and requires an ipp-company-id header on every API call. Visma publishes events via webhooks with one-time delivery (no automatic retry) and also supports delta polling using lastModifiedDateTime. Data modifications require ETag-based optimistic locking via If-Match headers.

How PayPal works

PayPal exposes orders, payments, captures, refunds, invoices, and transaction history through REST APIs secured by OAuth 2.0 Client Credentials. Bearer tokens are cached and live roughly 8 hours. PayPal pushes events via webhooks with up to 25 retries over 3 days and requires RSA-SHA256 signature verification on incoming notifications. Transaction search is limited to a 31-day lookback window, and refunds must be issued against specific captures rather than orders.

What moves between them

The primary flow moves PayPal payments and refunds into Visma. After each PayPal transaction (payment capture, refund, invoice), ml-connector reads the event and posts a corresponding journal entry into Visma's GL, allocated to the correct GL account and customer dimension. Customer invoices sent via PayPal sync back into Visma's AR records for reconciliation. Refunds and partial payments adjust the customer balance automatically. Data moves on PayPal webhook events when enabled, with polling fallback for missed webhooks.

How ml-connector handles it

ml-connector stores both OAuth credentials securely and refreshes Visma and PayPal bearer tokens on expiry before they can cause outages. On the Visma side, it validates every GL account number and dimension (customer, project) against the live Visma instance before posting, since Visma does not support draft journal entries and enforces ETag-based optimistic locking on updates. PayPal transactions arrive via webhook signature verification (RSA-SHA256), but since PayPal webhooks are one-time delivery with no guarantee, ml-connector also polls the transaction API with a 31-day rolling window to catch any missed events. Refunds are matched to their original capture records so the customer balance reflects the net payment. Timeouts and transient failures trigger exponential backoff and retry.

A real-world example

A Nordic e-commerce business runs Visma ERP for accounting and uses PayPal for all customer payments and invoicing. Previously, the finance team exported PayPal transaction reports weekly and manually entered each payment and refund into Visma's customer AR records, then spent days chasing discrepancies between the two systems during month-end close. With Visma and PayPal connected, every payment posts to the correct customer within minutes of capture, refunds automatically reduce the AR balance, and the reconciliation step is eliminated. The AR aging is always current, and the team reclaims days of manual work each cycle.

What you can do

Post PayPal capture and refund transactions into Visma's general ledger and customer AR records, allocated to the correct GL account and customer dimension.
Validate every payment against Visma's chart of accounts and customer master data before posting, preventing downstream reconciliation errors.
Handle PayPal webhook delivery failures by polling the transaction history API with a rolling 31-day window to catch missed events.
Manage OAuth 2.0 token refresh on both Visma and PayPal, ensuring seamless authentication without manual credential updates.
Trace every payment and refund through a complete audit log with source record IDs from both systems for dispute resolution.

Questions

Does ml-connector support both Visma.net and Visma Severa, or is it Visma.net only?: This integration targets Visma.net ERP specifically, which uses the OAuth 2.0 Visma Connect authentication flow. Visma Severa is a separate cloud product with its own REST API contract and is not included in this integration. If you run Severa instead, it requires a separate connector build.
What happens if a PayPal webhook fails to deliver?: PayPal webhooks are one-time delivery with no automatic retry guarantee. ml-connector compensates by polling the PayPal transaction API on a fixed schedule within the 31-day lookback window. If a webhook fails, the transaction is caught by the next poll cycle, ensuring no payments are orphaned. Every record carries a source ID linking back to PayPal for audit purposes.
Can payments be allocated to different Visma GL accounts and cost centers per transaction?: Yes. ml-connector accepts a mapping table (PayPal transaction type, amount range, or customer group) to different Visma GL accounts and dimensions. Before posting, every GL account and dimension is validated against the live Visma instance. If an account is inactive or a customer dimension does not exist in Visma, the transaction is flagged for review rather than posted in error.

Connect Visma and PayPal

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

Get started