Systemintegrasjon i praksis — slik koblet vi Vipps, Dintero og regnskap i én flyt
De fleste virksomheter bruker 5–10 systemer som ikke snakker sammen. Her deler vi konkrete erfaringer fra å koble betaling, fakturering og regnskap i Splice — og hva du kan lære av det.
Systemintegrasjon handler om å koble separate systemer — betaling, booking, regnskap — slik at data flyter automatisk uten manuelt arbeid. Her deler vi erfaringene fra å integrere Vipps, Dintero og regnskapssystemer i Splice.
Når en elev booker en kjøretime i Splice, skjer det mye under panseret: betalingen prosesseres via Vipps eller kort, transaksjonen registreres i betalingsoversikten, fakturaen genereres automatisk, og beløpet avstemmes mot regnskapssystemet — alt uten at noen løfter en finger.
Å komme dit var ikke trivielt. Denne artikkelen handler om de tekniske valgene vi tok, utfordringene vi møtte, og prinsippene som har gjort integrasjonene robuste over tid.
Utgangspunktet: fire systemer i siloer
Før Splice brukte pilotskolene våre typisk denne kombinasjonen:
- Vipps for mobilbetalinger (manuelle forespørsler)
- Bankoverføring for fakturakunder
- Tripletex eller Fiken for regnskap og fakturering
- Excel for å holde oversikt over hvem som hadde betalt
Resultatet var forutsigbart: data levde i fire systemer som aldri var synkroniserte. Kontoransatte brukte 2–4 timer per uke bare på å avstemme betalinger manuelt. Feilen lå ikke hos de ansatte — systemene var simpelthen ikke bygget for å snakke sammen.
Hvordan fungerer adapterbasert integrasjon?
Vi løste problemet ved å bygge et internt betalings-API som fungerer som et abstraksjonslag mellom Splice og de ulike betalingsleverandørene. Prinsippet er enkelt: Splice snakker bare med vårt eget API — aldri direkte med Vipps, Dintero eller regnskapssystemet.
Hvorfor et abstraksjonslag?
| Tilnærming | Fordel | Ulempe |
|---|---|---|
| Direkte integrasjon mot hver leverandør | Raskere å starte | Tett kobling, vanskelig å bytte leverandør |
| Abstraksjonslag (adapter pattern) | Leverandøruavhengig, enklere å teste | Mer kode å vedlikeholde initialt |
Vi valgte abstraksjonslaget fordi vi visste at betalingslandskapet i Norge er i bevegelse. Da Vipps og MobilePay fusjonerte i 2022 og ble Vipps MobilePay, endret API-ene seg. Med vårt abstraksjonslag trengte vi bare å oppdatere én adapter — Splice-koden forble uendret.
Adaptermønsteret i praksis
Hver betalingsleverandør implementeres som en adapter med et felles grensesnitt:
- Initier betaling — opprett en transaksjon med beløp, referanse og callback-URL
- Sjekk status — hent gjeldende status for en transaksjon
- Bekreft/avbryt — fullfør eller kanseller en pågående transaksjon
- Webhook-mottak — ta imot statusoppdateringer fra leverandøren
Når vi la til Mastercard Payment Services via Dintero som en tredje betalingskanal, tok det under en uke å implementere adapteren. Alt eksisterende funksjonalitet — oversikter, rapporter, avstemming — fungerte umiddelbart fordi det nye grensesnittet fulgte samme kontrakt.
Hvordan integrere Vipps i et bookingsystem?
Vipps ePayment API er i utgangspunktet godt dokumentert, men asynkron betalingsflyt byr på utfordringer som ikke er åpenbare ved første øyekast.
Utfordring 1: Callback-rekkefølge
Vipps sender webhooks (callbacks) når betalingsstatusen endres. Men callbacks er ikke garantert å komme i riktig rekkefølge. Vi opplevde tilfeller der CANCELLED-callback kom før AUTHORIZED — noe som skapte inkonsistent tilstand i databasen.
Løsning: Vi implementerte en tilstandsmaskin (state machine) for transaksjoner. Hver statusovergang er definert eksplisitt, og ugyldige overganger ignoreres med logging. I tillegg poller vi Vipps-API-et med jevne mellomrom for å fange opp tapte callbacks.
Utfordring 2: Idempotens
Vipps kan sende samme callback flere ganger. Hvis vi ikke håndterer dette, risikerer vi å registrere samme betaling to ganger.
Løsning: Hver transaksjon har en unik referanse (idempotency key). Før vi prosesserer en callback, sjekker vi om transaksjonen allerede er i ønsket tilstand. Er den det, returnerer vi 200 OK uten å gjøre noe.
Utfordring 3: Timeout og brukeropplevelse
Hvis en bruker lukker Vipps-appen uten å fullføre betalingen, får vi ingen callback. Transaksjonen blir hengende i INITIATED-status.
Løsning: En bakgrunnsjobb sjekker alle transaksjoner som har vært i INITIATED-status i mer enn 15 minutter, og kansellerer dem automatisk. Brukeren får en vennlig melding om at betalingen utløp og kan prøve igjen.
Hvordan koble betaling til regnskap automatisk?
Den kanskje mest verdifulle integrasjonen er den mot regnskapssystemet. Før Splice ble kontoransatte brukt timer på manuell avstemming. Nå skjer det automatisk.
Flyten
- Betaling fullføres i Splice (via Vipps, kort eller faktura)
- Betalings-API-et registrerer transaksjonen med metadata (elev, kurstype, instruktør, dato)
- En asynkron jobb genererer et regnskapsbilag med riktig kontoplan
- Bilaget sendes til regnskapssystemet via API
- Avstemming skjer automatisk basert på betalingsreferanse
Feilhåndtering
Hva skjer når regnskapssystemet er nede? Vi implementerte en kømekanisme:
- Mislykkede bilag legges i en retry-kø med eksponentiell backoff
- Etter tre mislykkede forsøk varsles administrasjonen
- Bilaget kan sendes manuelt fra Splice når systemet er tilbake
I praksis har vi sett nedetid hos regnskapsleverandører 2–3 ganger i løpet av et år. Kømekanismen har håndtert dette automatisk hver gang.
Hva ble resultatet av integrasjonen?
| Område | Før integrasjon | Etter integrasjon |
|---|---|---|
| Manuell betalingsavstemming | 2–4 timer per uke | Automatisk |
| Tid fra betaling til bokføring | 1–3 dager | Under 5 minutter |
| Feil i avstemming | 3–5 per måned | Tilnærmet null |
| Støttede betalingsmetoder | 1–2 (manuelt) | 4 (automatisk) |
Tallene er basert på erfaringer fra pilotskoler som bruker Splice.
Prinsipper vi tar med videre
Erfaringene fra betalingsintegrasjonen i Splice har gitt oss prinsipper vi bruker i alle integrasjonsprosjekter:
Design for feil. Eksternt API-er vil feile. Bygg kømekanismer, retry-logikk og fallback-strategier fra dag én.
Bruk abstraksjonslag. Aldri la forretningslogikken din avhenge direkte av en tredjepartsleverandørs API. Leverandører endrer API-er, fusjonerer eller legges ned.
Idempotens er ikke valgfritt. Alle integrasjonspunkter må tåle å motta samme melding flere ganger uten sideeffekter.
Logg alt. Når noe går galt i en integrasjon mellom to systemer, trenger du detaljerte logger på begge sider for å finne feilen.
Test med realistisk data. Sandbox-miljøer er nyttige, men de simulerer sjelden alle edge cases. Test med reelle beløp og reelle API-er i staging før lansering.
Trenger du hjelp med systemintegrasjon?
Hvis du kjenner deg igjen i utfordringene over — fragmenterte systemer, manuell dataflytting, manglende oversikt — kan vi hjelpe. Vi tilbyr systemintegrasjon som kobler dine systemer i en sammenhengende flyt.
Ta kontakt for en uforpliktende samtale om integrasjonsbehovene dine.
Kilder og videre lesning
- Vipps MobilePay (2025). ePayment API Documentation. vippsmobilepay.com/api
- Dintero (2025). «Unified Commerce API Reference.» docs.dintero.com
- Tripletex (2025). API Documentation for regnskapsintegrasjon. developer.tripletex.no
- Fowler, M. (2002). Patterns of Enterprise Application Integration. Addison-Wesley.
- Richardson, C. (2018). Microservices Patterns. Manning Publications.