Betalningens livscykel: från auktorisering till avveckling

Betalningens livscykel är den fasta sekvens en betalning går igenom, från det att den godkänns till det att pengarna landar på handlarens konto: auktorisering, capture, clearing, avveckling och utbetalning. Varje steg gör exakt ett jobb, och pengarna befinner sig i ett nytt tillstånd efter vart och ett. De flesta tänker sig en kortbetalning som en enda händelse vid blippen, men i själva verket är den en kedja. Nästan allt som går rätt eller fel i betalningar beror på att stegen är separata, inte samtidiga.

Att förstå kedjan är skillnaden mellan en betalning som stämmer av sig själv och ett supportärende. Så vi går igenom den en gång, från början till slut och i rätt ordning.

Auktorisering: en reservation, inte en överföring

Auktorisering är en fråga, inte en förflyttning. När kortet blippas går förfrågan till kortutfärdaren, som kontrollerar att kontot finns, är i god ordning och har täckning eller kredit för beloppet. Om så är fallet läggs en reservation – pengarna öronmärks så att de inte kan spenderas två gånger – och en auktoriseringskod returneras. Inga pengar har flyttats. Handlaren har nu ett löfte om att medlen är säkra, giltigt under ett fönster som schemat bestämmer. En auktorisering kan återkallas (void) innan något har dragits, och den löper ut av sig själv om den aldrig används. Därför sjunker saldot på kortet i samma stund som du betalar, medan raden på kontoutdraget bekräftas först senare: minskningen är reservationen, inte debiteringen. En auktorisering kan också avslås direkt – otillräckliga medel, en bedrägeriregel, ett utgånget kort – och en bra gateway skiljer mellan ett mjukt avslag som är värt att försöka igen och ett hårt som inte är det. Eftersom reservationen är utfärdarens löfte om att pengarna finns kan handlaren lämna ut varorna på enbart auktoriseringskodens ord, innan en enda krona faktiskt har lämnat kundens konto.

Capture: reservationen blir ett krav

Capture är handlaren som säger ”hämta in detta nu”. Det omvandlar reservationen till en faktisk begäran om pengarna. Capture kan vara full, partiell (ett lägre slutbelopp än det auktoriserade – en skickad vara som blev billigare än förhandsreservationen) eller fördröjd (auktorisera vid beställning, capture vid leverans). Auktorisering och capture i ett steg är standard i en butikskassa. Enbart auktorisering följd av capture senare är hur hotell, bensinpumpar och marknadsplatser fungerar, eftersom de inte känner till slutbeloppet när kortet visas upp. Glappet mellan auktorisering och capture är en medveten och användbar skarv – det är där handlaren avgör vad som faktiskt ska debiteras.

Clearing: batchen som stämmer av

Capturade betalningar avvecklas inte en och en i realtid. De samlas i filer och utbyts mellan handlarens acquirer och kortscheman i batchar – det är clearing. I det här steget matchas transaktionerna, beloppen nettas och schemaavgifter och interchange tillämpas, så att alla är överens om vem som är skyldig vem hur mycket. Clearing är ett avstämningsjobb, inte en penningrörelse: det tar fram de överenskomna totalbeloppen som nästa steg agerar på. Det är dessutom till sin natur en batchprocess – och just därför kan en betalning som kändes omedelbar i kassan ta flera dagar på sig att landa som pengar. Inget av detta är en begränsning hos datorer. Så är scheman byggda för att effektivt netta tusentals institut mot varandra och utbyta överenskomna totaler en gång per cykel, i stället för att skicka en överföring för varje kaffe.

Auktorisering är ett löfte, capture är ett krav och avveckling är det enda steg där pengar faktiskt flyttas. Blandar man ihop de tre bokför man intäkter man ännu inte har.

Avveckling: pengarna flyttas på riktigt

Avveckling är där medel på riktigt byter ägare mellan banker. Med de nettade totalerna från clearing flyttar schemat pengar från utfärdare till acquirers, och varje institut avvecklar sin nettoposition i stället för varje enskild transaktion. Avvecklingen sker mot ett valutadatum – dagen då medlen faktiskt finns tillgängliga – vilket är skälet till att betalningar följer en T+1- eller T+2-rytm: pengarna är verkliga, men de kommer enligt schemats kalender, inte kundens klocka. Allt före det här steget var bokföring. Här blir huvudboksposterna till saldon som går att spendera. Ett institut som är skyldigt netto betalar, ett som har till godo får – och eftersom det är netto är summorna som faktiskt flyttas mellan bankerna bara en bråkdel av dagens bruttovärde, vilket gör att ett schema med miljontals transaktioner kan nöja sig med ett hanterbart antal avvecklingsrörelser.

Utbetalning: från acquirer till ditt konto

Avvecklingen lägger pengarna hos acquirern, och utbetalningen flyttar dem till handlaren. Enligt ett schema – dagligen, veckovis eller på begäran – betalar acquirern ut handlarens upplupna saldo till dennes bankkonto, efter avdrag för processavgifter och eventuell reserv som hålls mot återbetalningar och tvister. Det är den siffra ett företag faktiskt ser, och den punkt där avstämningen antingen fungerar eller gör ont: utbetalningen är ett nettobelopp som täcker många transaktioner, så att matcha den mot enskilda ordrar är en egen uppgift. En gateway som för med sig varje ordersidentitet hela vägen gör det trivialt, och en som inte gör det förvandlar varje utbetalning till ett kalkylblad. Vårt gateway-flöde, /products/gateway, är byggt så att en utbetalning stäms av mot de ordrar den bestod av.

Där krypto lägger till en brygga

En krypto- eller stablecoin-betalning ersätter inte den här kedjan – den lägger till ett konverteringssteg i början av den. I stället för en utfärdares auktoriseringsreservation bekräftas betalningen on-chain: kunden signerar en överföring, och slutgiltighet nås när nätverket lägger till bekräftelser, inte när en bank godkänner en reservation. När betalningen är bekräftad omvandlar en off-ramp kryptot till fiat, och därifrån går pengarna in i samma clearing-, avvecklings- och utbetalningsväg som alla andra betalningar. Det nya stannar i det första steget, medan den bakre halvan medvetet förblir tråkig. Det är designregeln – håll avvecklingen vanlig och lägg de nya mekanismerna bara där de är oundvikliga – eftersom treasury, avstämning och revisor längre ned i kedjan inte ska kunna se hur betalningen började. Hur många bekräftelser som räknas som slutgiltiga är ett policyval, inte en naturlag i kedjan: en högre nivå byter snabbhet mot säkerhet mot en reorganisation, och off-ramp väntar på det djup som riskaptiten anger innan fiat släpps in i avvecklingsflödet.

Varför skarvarna spelar roll i driften

Återbetalningar, reverseringar och tvister hör alla till ett visst steg, och att hitta rätt steg är hela konsten. Avbryter du före capture återkallar du en auktorisering – inga pengar har någonsin flyttats och det finns inget att betala tillbaka. Avbryter du efter avveckling gör du en återbetalning – en ny betalning i motsatt riktning, med sin egen livscykel. En chargeback når bakåt genom clearing för att hämta tillbaka ett avvecklat belopp. Behandlar du dessa som ett enda odifferentierat ”avbryt” börjar huvudboken glida. Behandlar du dem som operationer på skilda steg får varje fall ett korrekt och spårbart tillvägagångssätt. Terminologin – auktorisering, capture, clearing, avveckling, valutadatum – finns samlad på /glossary.

Den enda tanke värd att ta med sig: en betalning är en kedja av tillstånd, inte en händelse. Auktorisering reserverar, capture kräver, clearing är överens, avveckling flyttar, utbetalning levererar – och ett kryptosteg skruvar bara fast en konvertering längst fram. Pengar är ett löfte fram till avvecklingen och ett faktum efter den, och ett företag som bokför dem före det räknar med pengar det ännu inte har. Vet du vilket tillstånd en betalning befinner sig i slutar resten av betalningsdriften att vara en gåta.