Har bygget adgangsret via Stripe og in‑app‑køb

Situation. Penge er den del af en platform, ingen har lov til at tage let på. Et abonnement skal kunne overleve et udløbet kort, en refusion, et planskifte, en webhook, der ankommer to gange, og en webhook, der ankommer i forkert rækkefølge. I det øjeblik betaling kan ske i tre butikker — et kort på nettet, Apple i den ene app store, Google i den anden — findes der tre forskellige udlægninger af, hvad nogen har købt, og produktet har stadig brug for ét svar på ét spørgsmål: hvad må denne person lige nu?

Opgave. At tage imod penge og at give adgang skulle være to systemer i stedet for ét, så en ny butik ikke betød, at hver eneste adgangskontrol i produktet skulle skrives om.

Handling. Stripe håndterer kort og abonnementer gennem 18 Go‑filer, og Apple- og Google‑in‑app‑køb kommer ind gennem deres egen kvitteringsverifikation. Alle tre løber sammen i et payments‑skema på 9 tabeller og 34 funktioner — og stopper så dér. Det, produktet faktisk spørger om, er et separat access‑skema på 11 tabeller og 34 funktioner, som svarer på “må denne konto det her?” uden at vide eller bryde sig om, hvilken butik der har betalt for det. Det svar styrer adgangen til virksomhedskataloget, søgningen og dataeksporten, og det genkontrolleres på serveren ved hver request, for en skjult knap er en høflighed og ikke en kontrol.

Resultat. En ny butik rører nu ved payments‑siden og lader adgangskontrollerne være, og et supportspørgsmål om nogens adgang har én tabel at kigge i frem for tre. Prisen er to skemaer, hvor et mindre produkt ville nøjes med ét, plus et rettighedsopslag på requests, der ellers ville have været gratis.