Behöver vi en licens för penningöverföring?

Det beror på flödet. Marknadsplatsbetalningar där pengarna passerar din huvudbok kräver normalt en MTL eller en BaaS-partner som har en. Direkt integration mot handlare (Stripe Connect) gör det oftast inte. Vi kartlägger regelkravet mot arkitekturen i discoveryfasen och bygger inget flöde som skapar en oväntad licensexponering.

Vilken PSP rekommenderar ni?

Stripe för utvecklarupplevelse och snabb tid till marknad. Adyen för flera marknader, hög volym och direkt tillgång till inlösande bank. Checkout.com för konkurrenskraftig interchange i Europa och MENA. Vi bygger ett PSP-abstraktionslager så att valet inte är permanent – att byta senare kostar en veckas ingenjörsarbete, inte en omskrivning.

Vad skiljer en huvudbok med dubbel bokföring från en betalningsdatabas?

En betalningsdatabas håller reda på transaktioner. En huvudbok med dubbel bokföring håller reda på saldon med ett spår som bevisar varje saldo från grunden. Varje debet har en kredit, varje saldo går att härleda ur transaktionsloggen, och inget saldo kan bli negativt utan ett uttryckligt beslut. Det är det revisorer och tillsynsmyndigheter menar när de säger ”visa ert underlag”.

Hur hanterar ni chargebacks?

Automatiserad sammanställning av bevis utifrån dina orderdata, fraktuppgifter och användningsloggar – formaterat efter kortnätverkets format för tvistesvar. Bevakning av deadlines och påminnelser, så att inget tvistesvar missas. Rapportering av vinstandel per tvisteorsak, så att du kan åtgärda de produktproblem som orsakar flest chargebacks.

Inbyggd finans och betalningar

Inbyggd finans – betalningar, huvudbok, regelefterlevnad

Inbyggd finans är det enklaste produktbeslutet och det svåraste ingenjörsproblemet. Den första Stripe-integrationen tar en dag. Huvudboken som stämmer av varje krona vid T+0, KYC-flödet som inte tappar kunder på vägen och tvisteprocessen som inte kräver en egen ops-avdelning – det är där det riktiga ingenjörsarbetet ligger.

En betalning, från start till mål

1
Initiering
Användarens handling – kassa, överföring, kortdrag
2
KYC/AML-kontroll
Automatisk kontroll innan auktorisation
3
PSP-auktorisation
Auktorisation via Stripe/Adyen/nätverket
4
Bokföringspost
Dubbel bokföring, båda sidor bokförs atomiskt
5
Avräkning
Avstämt mot kontoutdraget, öre för öre

Chargeback- och tvisteflödet löper parallellt – bevis sammanställs automatiskt innan deadline.

Det här får du

Arkitektur för betalningsrails med ett PSP-abstraktionslager – Stripe, Adyen, Checkout.com eller direkt mot kortnätverket, utbytbart utan omskrivning

En huvudbok med dubbel bokföring, konstruerad efter din datamodell – varje krona redovisad, varje transaktion oföränderlig, varje saldo avstämbart på under en sekund vid din förväntade volym

Integration för kortutgivning (Marqeta, Lithic eller Stripe Issuing) med programuppsättning, utgiftskontroller och leverans av virtuella och fysiska kort

KYC/AML-pipeline med automatiserad dokumentverifiering (Persona, Jumio eller Onfido), sanktionskontroll och en mänsklig granskningskö som möter din tillsynsmyndighets krav

Arbetsflöde för chargebacks och tvister – automatiserad sammanställning av bevis, bevakning av deadlines och rapportering av vinstandel

Avstämning vid avräkning som fångar ören som inte stämmer innan de blir en revisionsanmärkning – batchad varje natt eller kontinuerlig vid högre volymer

När det passar

Betalningar, plånböcker eller kortutgivning är en produktfunktion, inte en perifer integration
Volym eller marginal gör tredjepartsaggregatorer till fel ekonomiska val i din 3-årsmodell
Regelverket (tillstånd för penningöverföring, e-pengar, banktillstånd) kräver direkta relationer med rails
Du behöver en huvudbok som går att granska – inte Stripes dashboard-export, utan ett riktigt system med dubbel bokföring som du äger

När det inte passar

Betalningen är en enkel kassaintegration – använd Stripe Checkout och överkonstruera inte
Du har inte validerat att användarna faktiskt betalar – bygg produkten först, optimera rails senare
Du bygger i en jurisdiktion med komplexa lokala betalningsscheman (UPI, PIX, iDEAL) som du ännu inte har kartlagt – discovery först

Process

Vecka 1–2: granskning av betalningsarkitekturen, en kortlista med PSP:er och design av huvudbokens schema. Vecka 3–6: PSP-integration, implementation av huvudboken och KYC-pipeline. Vecka 7–10: kortutgivning (där det är aktuellt), tvisteprocess och avstämning vid avräkning. Vecka 11–12: belastningstester och överlämning av dokumentation för regelefterlevnad.

Hela leveransprocessen

Prissättning

Fast pris efter omfattning. Enkel betalningsintegration + huvudbok: $100–200k. Fullständig stack för inbyggd finans (betalningar + huvudbok + kortutgivning + KYC): $250–600k. Avgifter till PSP och BaaS faktureras enligt dina villkor – vi tar ingen del av interchange. Introduktion till licens- och bankpartner ingår där vi redan har relationer.

Se våra samarbetsformer

Kundcase

Finansiell teknik

Mobilbanksplattform för FinTech

Säker och AI-driven mobilbank som betjänar över 500 000 användare, med omedelbara överföringar och biometrisk autentisering.

E-handel & detaljhandel

E-handelsplattform för flera säljare

Skalbar marknadsplats som hanterar över 10 miljoner dollar i månaden, med AI-rekommendationer och lagerhantering i realtid.

Branscher där vi erbjuder det här

FinTech

Vanliga frågor

Behöver vi en licens för penningöverföring?: Det beror på flödet. Marknadsplatsbetalningar där pengarna passerar din huvudbok kräver normalt en MTL eller en BaaS-partner som har en. Direkt integration mot handlare (Stripe Connect) gör det oftast inte. Vi kartlägger regelkravet mot arkitekturen i discoveryfasen och bygger inget flöde som skapar en oväntad licensexponering.
Vilken PSP rekommenderar ni?: Stripe för utvecklarupplevelse och snabb tid till marknad. Adyen för flera marknader, hög volym och direkt tillgång till inlösande bank. Checkout.com för konkurrenskraftig interchange i Europa och MENA. Vi bygger ett PSP-abstraktionslager så att valet inte är permanent – att byta senare kostar en veckas ingenjörsarbete, inte en omskrivning.
Vad skiljer en huvudbok med dubbel bokföring från en betalningsdatabas?: En betalningsdatabas håller reda på transaktioner. En huvudbok med dubbel bokföring håller reda på saldon med ett spår som bevisar varje saldo från grunden. Varje debet har en kredit, varje saldo går att härleda ur transaktionsloggen, och inget saldo kan bli negativt utan ett uttryckligt beslut. Det är det revisorer och tillsynsmyndigheter menar när de säger ”visa ert underlag”.
Hur hanterar ni chargebacks?: Automatiserad sammanställning av bevis utifrån dina orderdata, fraktuppgifter och användningsloggar – formaterat efter kortnätverkets format för tvistesvar. Bevakning av deadlines och påminnelser, så att inget tvistesvar missas. Rapportering av vinstandel per tvisteorsak, så att du kan åtgärda de produktproblem som orsakar flest chargebacks.

En medarbetare på TekPiq leder en designgenomgång vid whiteboarden medan utvecklarna diskuterar — Designgenomgång vid whiteboarden – kunduppgifter suddade.

Vem som bygger det

Vårt eget team, som arbetar från vårt kontor i Istočno Sarajevo, Bosnien och Hercegovina. Ingenjörerna på ditt behovssamtal är samma personer som bygger det.

Möt teamet

Inbyggd finans och betalningar – ska vi prata?

Ett 30 minuters behovssamtal. Förutsättningslöst och utan säljtryck.