System integration in practice — how we connected Vipps, Dintero, and accounting in one flow
Most businesses use 5–10 systems that don't talk to each other. Here we share concrete experiences from connecting payments, invoicing, and accounting in Splice — and what you can learn from it.
System integration is about connecting separate systems — payments, booking, accounting — so that data flows automatically without manual work. Here we share our experiences from integrating Vipps, Dintero, and accounting systems in Splice.
When a student books a driving lesson in Splice, a lot happens under the hood: the payment is processed via Vipps or card, the transaction is recorded in the payment overview, the invoice is generated automatically, and the amount is reconciled with the accounting system — all without anyone lifting a finger.
Getting there wasn't trivial. This article covers the technical decisions we made, the challenges we faced, and the principles that have kept these integrations robust over time.
Starting point: four systems in silos
Before Splice, our pilot schools typically used this combination:
- Vipps for mobile payments (manual requests)
- Bank transfer for invoice customers
- Tripletex or Fiken for accounting and invoicing
- Excel to track who had paid
The result was predictable: data lived in four systems that were never synchronized. Office staff spent 2–4 hours per week just manually reconciling payments. The fault didn't lie with the staff — the systems simply weren't built to communicate.
How does adapter-based integration work?
We solved the problem by building an internal payment API that acts as an abstraction layer between Splice and the various payment providers. The principle is simple: Splice only talks to our own API — never directly with Vipps, Dintero, or the accounting system.
Why an abstraction layer?
| Approach | Advantage | Disadvantage |
|---|---|---|
| Direct integration with each provider | Faster to start | Tight coupling, hard to switch providers |
| Abstraction layer (adapter pattern) | Provider-independent, easier to test | More code to maintain initially |
We chose the abstraction layer because we knew Norway's payment landscape was evolving. When Vipps and MobilePay merged in 2022 to become Vipps MobilePay, the APIs changed. With our abstraction layer, we only needed to update one adapter — the Splice code remained untouched.
The adapter pattern in practice
Each payment provider is implemented as an adapter with a common interface:
- Initiate payment — create a transaction with amount, reference, and callback URL
- Check status — fetch the current status of a transaction
- Confirm/cancel — complete or abort an ongoing transaction
- Webhook receiver — receive status updates from the provider
When we added Mastercard Payment Services via Dintero as a third payment channel, it took less than a week to implement the adapter. All existing functionality — overviews, reports, reconciliation — worked immediately because the new interface followed the same contract.
How to integrate Vipps in a booking system?
The Vipps ePayment API is well-documented, but asynchronous payment flows present challenges that aren't obvious at first glance.
Challenge 1: Callback ordering
Vipps sends webhooks (callbacks) when payment status changes. But callbacks aren't guaranteed to arrive in the correct order. We experienced cases where a CANCELLED callback arrived before AUTHORIZED — creating inconsistent state in the database.
Solution: We implemented a state machine for transactions. Each state transition is explicitly defined, and invalid transitions are ignored with logging. Additionally, we poll the Vipps API at regular intervals to catch missed callbacks.
Challenge 2: Idempotency
Vipps can send the same callback multiple times. If we don't handle this, we risk recording the same payment twice.
Solution: Each transaction has a unique reference (idempotency key). Before processing a callback, we check whether the transaction is already in the desired state. If so, we return 200 OK without taking action.
Challenge 3: Timeout and user experience
If a user closes the Vipps app without completing the payment, we receive no callback. The transaction remains stuck in INITIATED status.
Solution: A background job checks all transactions that have been in INITIATED status for more than 15 minutes and cancels them automatically. The user gets a friendly message that the payment expired and can try again.
How to connect payments to accounting automatically?
The perhaps most valuable integration is the one with the accounting system. Before Splice, office staff spent hours on manual reconciliation. Now it happens automatically.
The flow
- Payment completes in Splice (via Vipps, card, or invoice)
- The payment API records the transaction with metadata (student, course type, instructor, date)
- An asynchronous job generates an accounting voucher with the correct chart of accounts
- The voucher is sent to the accounting system via API
- Reconciliation happens automatically based on payment reference
Error handling
What happens when the accounting system is down? We implemented a queue mechanism:
- Failed vouchers are placed in a retry queue with exponential backoff
- After three failed attempts, the administration is notified
- The voucher can be sent manually from Splice when the system recovers
In practice, we've seen downtime from accounting providers 2–3 times per year. The queue mechanism has handled this automatically each time.
What were the results of the integration?
| Area | Before integration | After integration |
|---|---|---|
| Manual payment reconciliation | 2–4 hours per week | Automatic |
| Time from payment to bookkeeping | 1–3 days | Under 5 minutes |
| Reconciliation errors | 3–5 per month | Near zero |
| Supported payment methods | 1–2 (manual) | 4 (automatic) |
Figures are based on experiences from pilot schools using Splice.
Principles we carry forward
The experiences from the payment integration in Splice have given us principles we use in all integration projects:
Design for failure. External APIs will fail. Build queue mechanisms, retry logic, and fallback strategies from day one.
Use abstraction layers. Never let your business logic depend directly on a third-party provider's API. Providers change APIs, merge, or shut down.
Idempotency is not optional. All integration points must handle receiving the same message multiple times without side effects.
Log everything. When something goes wrong in an integration between two systems, you need detailed logs on both sides to find the error.
Test with realistic data. Sandbox environments are useful, but they rarely simulate all edge cases. Test with real amounts and real APIs in staging before launch.
Need help with system integration?
If you recognize the challenges above — fragmented systems, manual data movement, lack of overview — we can help. We offer system integration that connects your systems into a seamless flow.
Get in touch for a free consultation about your integration needs.
Sources and further reading
- Vipps MobilePay (2025). ePayment API Documentation. vippsmobilepay.com/api
- Dintero (2025). "Unified Commerce API Reference." docs.dintero.com
- Tripletex (2025). API Documentation for accounting integration. developer.tripletex.no
- Fowler, M. (2002). Patterns of Enterprise Application Integration. Addison-Wesley.
- Richardson, C. (2018). Microservices Patterns. Manning Publications.