Betalningsbegrepp

En engångsbetalning debiterar ett fast belopp en gång: för en kurs, ett kred paket eller en upplåsning utan tidsbegränsning. En prenumeration debiteras enligt ett återkommande schema och måste hantera förnyelser, uppgraderingar och uppsägningar.

De här betalningstyperna kräver olika datamodeller. Att blanda ihop dem är ett klassiskt nybörjarmisstag – prenumerationer har ett tillstånd som förändras över tid, medan engångsbetalningar inte har det.

Varje debitering följer en väg: kunden godkänner, leverantören genomför debiteringen, pengarna sätts in på ert konto flera dagar senare och avgifter dras av på vägen.

Godkännande är inte samma sak som avräkning. En debitering kan godkännas men ändå misslyckas med att avräknas. Att utforma systemet för det här mellanläget – väntande, lyckad, misslyckad – är centralt för en korrekt integration.

PCI DSS är säkerhetsstandarden för hantering av kortuppgifter. Om ni hanterar råa kortnummer hamnar ni inom ett omfattande efterlevnadsområde som ni inte vill behöva hantera.

Utvägen är att aldrig låta kortuppgifter nå er server. Använd leverantörens hostade checkout-sida eller tokeniserande fält på klientsidan. Kortet blir en token; det enda ni någonsin sparar är tokenen.

När ett kort har angetts returnerar leverantören en token eller ett sparat ID för betalningsmetoden. Den här ogenomskinliga referensen kan debiteras igen utan att kortnumret någonsin behöver hanteras på nytt.

Genom att spara token kan ni fakturera prenumerationer och erbjuda återköp med ett enda klick, samtidigt som det faktiska PAN-numret stannar i leverantörens valv.

Pengar är aldrig ett flyttal. 19,99 USD sparas som heltalet 1999 i den minsta valutaenheten (cent). Flyttal leder till avrundningsfel som förstör totalsummor.

Koppla alltid ihop ett belopp med en valutakod. ”1999” betyder ingenting förrän ni vet om det är cent i USD eller JPY (som inte har någon underenhet alls).

Nätverk försöker igen. En användare dubbelklickar, en begäran tar för lång tid och försöker igen eller en webhook levereras på nytt. Utan skydd debiterar ni kunden två gånger.

En idempotensnyckel är ett unikt värde som ni kopplar till en debiteringsbegäran, så att leverantören känner igen ett nytt försök och returnerar det ursprungliga resultatet i stället för att skapa en ny debitering. Behandla den som obligatorisk, inte valfri.

Användarens webbläsare är inget tillförlitligt vittne. Användaren kan stänga fliken direkt efter betalningen. Leverantören berättar vad som faktiskt hände genom webhooks — händelser mellan servrar, som payment_succeeded.

Ge aldrig åtkomst enbart baserat på en omdirigering från klienten. Webhooken är er sanningskälla för leveransen.

Alla seriösa leverantörer har ett testläge med påhittade kortnummer och separata API-nycklar. Ni kan simulera lyckade debiteringar, nekade betalningar, tvister och utgångna kort utan att flytta ett enda öre.

Bygg och verifiera hela flödet i testläge först. Byt till produktionsnycklar först när webhooks, återbetalningar och kantfall fungerar som de ska.

Innan ni skriver någon kod ska ni beskriva hela resan för AI-assistenten: vem som betalar, vad betalningen gäller, hur åtkomst beviljas och vad som händer när betalningen misslyckas.

En tydlig specifikation ger en sammanhängande integration. En vag prompt ger en demo som bara fungerar i idealfallet och går sönder vid det första nekade kortet.

Betalningar skiljer sig från vanlig kod eftersom riktiga pengar och reglering är inblandade. Ni samordnar en leverantör, sparar token i stället för kort och håller kortuppgifter borta från servern för att begränsa PCI-omfattningen.

Pengar representeras av heltal i cent plus en valutakod. Idempotensnycklar förhindrar dubbla debiteringar, och webhooks — inte webbläsaren — är sanningen om vad som betalades. Specificera hela flödet, inklusive fel, innan ni börjar koda.