Det er sjelden enten eller
Diskusjonen blir presentert som et valg mellom to leverandører. I praksis er det et valg om arkitektur, og de to leverandørene løser hver sin del av det.
Vipps MobilePay er distribusjon. Den ligger allerede på telefonen til kunden, kunden vet hvordan den ser ut, og et kjøp er tre trykk og et ansikt. Det er derfor den hører hjemme i kassen for norske forbrukere, uansett hva som ligger bak.
Stripe er verktøykasse. Abonnement, prøveperioder, proratering, fakturaer, kvitteringer, tilbakebetalinger, uttrekk til regnskap, og en API-dokumentasjon som gjør at utviklere ikke må gjette. Det er derfor den hører hjemme der forretningslogikken bor.
Klarna hører hjemme i samme samtale
Klarna er tilgjengelig som betalingsmåte gjennom Stripe, så teknisk er det sjelden et eget prosjekt. Spørsmålet er om «betal senere» passer produktet deres. Det gjør det ofte for varer, og sjeldnere for tjenester som leveres med en gang – en badstutime i går er en vanskelig sak å ta en tvist på. Ta beslutningen ut fra hva dere selger, ikke ut fra at knappen finnes.
Systemet som eier sannheten
Dette er den beslutningen som faktisk koster penger å ta feil.
En betalingsleverandør kan holde sannheten om et abonnement, eller den kan bare gjennomføre trekk. Velger dere det første, blir leverandøren vanskelig å bytte, og dere kan bare svare på spørsmål leverandøren har tenkt på. Velger dere det andre, må dere skrive litt mer kode, men dere eier begrepene deres selv.
Vi bygger som regel slik: en ordre eller en avtale er en rad hos kunden. Hver betalingsleverandør er en adapter som rapporterer hendelser inn – betalt, feilet, refundert, sagt opp – og systemet reagerer på hendelsen. Da er en ny betalingsmåte en adapter til, og et bytte av leverandør er ikke en omskriving av produktet.
Det er samme mønster som ellers i denne kodebasen: hendelser inn i en logg som ikke kan endres, og abonnenter som gjør jobben. Det er kjedelig, og det er grunnen til at det holder.
Tre feil vi ser oftest
Å la kassen definere produktet. Når «hva et medlemskap er» bare finnes i leverandørens kontrollpanel, kan ingen svare på et kundespørsmål uten å logge inn der. Første gang dere skal endre en pris for eksisterende medlemmer, merker dere det.
Å behandle webhooks som garantert. De kommer, men ikke alltid én gang, og ikke alltid i riktig rekkefølge. Håndteringen må tåle å få samme melding to ganger og gamle meldinger sent. Dette er nesten alltid årsaken når «betalingen gikk gjennom, men ordren mangler».
Å utsette avstemmingen. Det som skjedde hos leverandøren og det som står hos dere, skal stemme hver dag. Bygger dere den sammenligningen sist, finner dere avvikene når de er tre måneder gamle.
Slik bestemmer du på en ettermiddag
Tre spørsmål holder som regel:
- Hvem er kundene? Norske forbrukere: Vipps i kassen, ikke diskuter. Bedrifter eller utland: start med Stripe og legg til Vipps hvis det trengs.
- Er det engangskjøp eller løpende avtale? Løpende avtaler er der forskjellene i modell betyr noe – bestem hvem som eier avtalen før dere velger.
- Hvor mange steder skal betalingen få konsekvenser? Ett sted er enkelt. Regnskap, adgang, medlemskap og varsling er fire, og da er hendelsesmodellen over verdt arbeidet.
HeatBooking gjør nettopp dette: betaling, medlemskap, klippekort og adgang henger på de samme hendelsene, og betalingsleverandøren er en av flere kilder – ikke fasiten.
Skal dere gjøre valget på ordentlig, beskriv tjenesten i Living Brief, så får du en skisse av flyten, fasene og et tidsrom tilbake med én gang.