Visma and GoCardless integration

What moves between them

Payment and payout records flow from GoCardless into Visma. After each collection, ml-connector reads the payment from GoCardless, matches it to the Visma customer and AR invoice via the customer mandate and invoice reference, and writes a cash receipt journal entry into Visma's general ledger, reducing the customer's open balance. Payout records are read periodically and posted as bank deposit entries aligned to the company's bank account in Visma. Refunds flow the same direction as credit memos. Mandate and customer records are synchronized in both directions so payment collectors in GoCardless match customer accounts in Visma.

How ml-connector handles it

ml-connector stores both the GoCardless bearer token and Visma OAuth credentials encrypted, and obtains a fresh Visma OAuth token before the service credentials expire. On the GoCardless side, ml-connector registers a webhook endpoint and verifies every incoming event batch with HMAC-SHA256 using the registered webhook secret; it returns 2xx only on valid signature to ensure GoCardless continues retrying failed deliveries. For payment records, ml-connector reads the mandate and payment metadata to identify the Visma customer account and invoice, then constructs a journal entry for cash and AR reduction. Because Visma webhooks are one-time only and cannot be retried if the receiver is down, ml-connector polls GoCardless payment and payout state as a primary mechanism, with webhook events used for notification triggers. Customer and mandate records are kept in sync so payment collectors in GoCardless align to account numbers in Visma. All payment posting carries a full audit trail and can be replayed if a downstream Visma call fails.

A real-world example

A mid-sized Nordic services company uses Visma for accounting and subscription billing, and GoCardless to collect monthly recurring payments from customers via direct bank debit. Before the integration, the accounts receivable team received a daily batch report from GoCardless, spent an hour matching payments to open invoices, and manually entered cash receipts into Visma. Month-end close required a second pass to reconcile the GoCardless payout report to the bank statement. With Visma and GoCardless connected, each payment flows into Visma as a cash receipt and AR reduction on the correct customer account the same day it is collected. Payouts are tracked against the bank deposit. The manual entry work is gone, and cash position and customer aging are always current.

What you can do

• •Post GoCardless payment collections into Visma as cash receipts and AR reductions on the customer account.
• •Sync customer bank account mandates between GoCardless and Visma so payment collectors align to AR customer accounts.
• •Reconcile GoCardless payouts to Visma's bank account with automatic deposit journal entries.
• •Verify every GoCardless webhook with HMAC-SHA256 signature and manage Visma OAuth token expiry so the integration does not interrupt.
• •Track posted payments with a full audit trail and replay any failed journal entry without creating duplicate postings.

Questions

Which direction does data move between Visma and GoCardless?

Payment and payout records flow from GoCardless into Visma. Each payment collected by GoCardless is posted as a cash receipt and AR reduction in Visma, and payouts are recorded as bank deposits. Customer and mandate records are synchronized in both directions so payment collectors align to Visma AR accounts.

How does ml-connector handle GoCardless webhook signatures?

GoCardless requires HMAC-SHA256 signature verification on every webhook batch. ml-connector stores the webhook secret encrypted, computes the signature from the raw request body, compares it to the Webhook-Signature header, and returns 2xx only on a valid match. This ensures GoCardless continues retrying failed deliveries.

Why does ml-connector poll GoCardless instead of relying only on webhooks?

Visma webhooks deliver one-time only and cannot be retried if the receiver is unavailable, making them unreliable for critical payment data. ml-connector polls GoCardless payment and payout state on a schedule as the primary mechanism, using webhook events as notification triggers to reduce polling latency.