Transaktionsregistrering, kædebekræftelse, ordreassociation og tjenestelevering er separate trin. Kontrollér den korrekte kæde, aktiv og modtager samt beløb; anvend en dokumenteret acceptpolitik; og gør afstemningen idempotent. En transaktionsreference, et skærmbillede eller en browserknap alene kan ikke fastslå, at en bestemt ordre er betalt.
Adskil kædehændelsen fra ordrehændelsen
En wallet, der rapporterer, at en overførsel er sendt, er bevis for dens egen handling, ikke en fuldstændig betalingsbeslutning. Den modtagende backend skal observere det tilsigtede netværk, verificere den faktiske overførsel og knytte den til en ordre. Først derefter kan ordren anvende sin acceptpolitik. Infrastrukturlevering er et andet operationelt trin efter betalingsaccept.
Hold disse overgange eksplicitte i både kode og kundesprog. En skærm kan vise afventer, registreret eller bekræfter uden at kalde ordren betalt. Lad ikke browseren levere det accepterede beløb eller overskrive en autoritativ status. Gem det serveroprettede tilbud og dets instruktioner, så senere afstemning kan vurderes mod den oprindelige ordre i stedet for en skiftende kurv.
Brug kædespecifikke konfidensregler
Forskellige netværk beskriver transaktionssikkerhed forskelligt. Bitcoins udviklervejledning forklarer, hvordan noder vælger den kæde med mest akkumuleret proof of work, og hvordan konkurrerende blokke kan opstå. En transaktion, der for nylig er set, kræver derfor en politik for bekræftelsesdybde og mulige kædeændringer. Der findes ikke et enkelt bekræftelsesantal, der passer til alle aktiver og kommercielle risici.
Ethereums proof-of-stake-dokumentation forklarer checkpoint-finalitet, mens Solana dokumenterer behandlede, bekræftede og endeligt fastlagte commitment-tilstande. Oversæt ikke disse begreber tilfældigt til et universelt blokantal. Registrér den netværksspecifikke regel, informationskilden og adfærden under usikkerhed. Operatøren bør fastlægge accepttærskler ud fra betalings- og leveringsrisikoen, ikke kopiere et tal fra en urelateret checkout.
Bekræft den faktiske overførselsnyttelast
Identificér modtager, aktiv og beløb på den korrekte kæde. Tokenbetalinger kræver den tilsigtede token-identitet, ikke blot en vellykket transaktion til en adresse. Verificér relevant eksekveringssucces og overførselsbevis i overensstemmelse med kædens model. Fortolk heltalsbeløb med aktivets korrekte præcision i stedet for at stole på en formateret decimal leveret af browseren.
En betalingsinstruktion skal forblive bundet til sin oprindelige rute. En overførsel på et andet netværk, et andet token med samme symbol eller en urelateret transaktionsreference bør ikke opfylde den. Verifikationsregistreringen bør forklare, hvad der blev kontrolleret, og bevare det bevis, der er nødvendigt for at gennemgå beslutningen. Denne vejledning beskriver generelle principper for betalingsafstemning frem for en bestemt tjenesteimplementering.
Gør ordretilknytningen entydig
Faste modtageradresser kan modtage flere ordrer med lignende beløb. Eksistensen af en matchende overførsel beviser ikke, hvilken kunde eller ordre der skal krediteres. Definer associationsmetoden, før du accepterer livebetalinger, og medtag håndtering af kollisioner. En brugerspecificeret transaktionsreference kræver stadig validering af, at den samme overførsel ikke allerede er tildelt et andet sted.
Forestil dig to fakturaer for samme beløb på samme rute i et overlappende tidsrum. En watcher ser én overførsel. Automatisk at markere begge som betalt er forkert; at vælge én uden tilstrækkeligt bevis er også usikkert. Hold overførslen uallokeret eller til gennemgang, indtil operatørens politik kan fastslå en gyldig association. Et tvetydigt match er en tilstand, der skal håndteres, ikke en grund til at opfinde sikkerhed.
Definér tilstande, der tåler sen og skiftende evidens
En betalingsproces drager fordel af et lille sæt klare tilstande, hvor kædebevis er adskilt fra beslutningen om at acceptere en ordre. Denne illustrative tabel forklarer mulige faser frem for at beskrive en bestemt tjenestes statusnavne. Hver overgang bør have en verificeret årsag, og betalingsaccept bør forblive adskilt fra infrastrukturlevering.
Medtag sene, delvise og overskydende overførsler, tilbudsudløb og midlertidigt utilgængelige kædedata. Udløb får ikke en rigtig overførsel til at forsvinde. En sen betaling kan kræve gennemgang i stedet for automatisk accept eller afvisning. Hvis en tidligere observeret kædehændelse ændrer sig, skal tilstanden revurderes under den dokumenterede politik i stedet for at behandle hver watcher-notifikation som uigenkaldelig sandhed.
| Illustrativ tilstand | Betydning | Næste beslutning |
|---|---|---|
| Afventer | Ingen verificeret kvalificerende overførsel | Fortsæt med at observere gyldig faktura |
| Registreret | Relevant overførsel observeret | Kontrollér kædesikkerhed og association |
| Bekræfter | Acceptregel endnu ikke opfyldt | Observer, indtil politikken tillader beslutning |
| Gennemgang | Sent, delvist eller tvetydigt bevis | Afklar under operatørens politik |
| Accepteret | Verificeret og afstemt betaling | Fortsæt til separat leveringsworkflow |
Gør gentagelser sikre og observerbare
Watchers og afstemningsjob vil prøve igen efter afbrudte forbindelser eller procesgenstarter. Brug en stabil overførselsidentitet, såsom kæden og den relevante transaktions- eller overførselsidentifikator, for at forhindre dobbelte krediteringer. Bevar fremdrift og beslutninger, så den samme hændelse kan behandles igen uden at klargøre en anden tjeneste eller ændre et accepteret tilbud.
Skeln mellem et ukendt resultat og en mislykket handling. Hvis en nedstrøms anmodning får timeout, skal du undersøge dens autoritative resultat, før du sender igen. Bevar holdbare registreringer af accepterede og usikre handlinger. Begræns adgangen til ordretokens og internt bevis, mens der bevares tilstrækkelig information til at undersøge en omtvistet betaling. Pålidelighed her handler om repeterbare beslutninger, ikke en glidende animation i checkouten.
Ved, hvad en afventende ordre stadig har brug for
En ordre kan forblive afventende, fordi overførslen ikke er observeret, den krævede kædesikkerhed ikke er nået, eller dens association med fakturaen kræver gennemgang. Bevar fakturaen og den offentlige transaktionsreference, kontrollér de angivne acceptregler, og brug ordrens tilsigtede assistanceproces. En forsinket statusopdatering er ikke i sig selv en grund til at sende endnu en betaling.
Følg instruktionerne og den verificerede status for den faktiske ordre. Betalingsbekræftelse bør identificere accept af den afstemte overførsel, mens tjenestelevering har en separat status. Hold private adgangstokens og wallet-hemmeligheder ude af anmodninger om hjælp.
Din praktiske tjekliste.
- Bevar et uforanderligt serveroprettet tilbud.
- Verificér kæde, modtager, aktiv og heltalsbeløb.
- Dokumentér kædespecifikke acceptregler.
- Håndter kollisioner med faste adresser uden at gætte.
- Forhindr dobbelte krediteringer og usikre gentagne indsendelser.
- Test sene, delvise, forkerte ruter og ændrede beviser.
De detaljer, der betyder noget.
Er en transaktionshash nok til at bekræfte betaling?+
Nej. Verificér overførslen på den tilsigtede kæde, dens payload og sikkerhed, og fastslå derefter, at den tilhører ordren, og at den ikke allerede er krediteret.
Kan alle netværk bruge samme bekræftelsestærskel?+
Nej. Netværk eksponerer forskellige sikkerheds- og finalitetsmodeller. Operatøren skal definere og teste en acceptpolitik, der passer til hver rute.
Betyder bekræftet betaling, at serveren er klargjort?+
Nej. Betalingsaccept og levering er separate workflowhændelser. Kommunikér klargøringsstatus fra dens egen autoritative proces.
Gå til kilden.
Disse referencer understøtter de tekniske begreber i denne guide. Følg den aktuelle dokumentation, før du ændrer et produktionssystem.
- Bitcoin udviklervejledning: Blockchain-adfærd developer.bitcoin.org
- Ethereum: Proof of stake og finalitet ethereum.org
- Solana: RPC-tilstandscommitment solana.com
Redaktionel vejledning af SwissOctet. Eksempler er illustrative. Servicespecifikationer, tilgængelige valgmuligheder og kontraktvilkår skal verificeres separat.