Zjištění transakce, potvrzení v řetězci, přiřazení k objednávce a doručení služby jsou samostatné kroky. Ověřte správný řetězec, aktivum, příjemce a částku; použijte zdokumentovanou zásadu přijetí; a vyrovnání proveďte idempotentně. Reference transakce, snímek obrazovky nebo tlačítko v prohlížeči samy o sobě nemohou prokázat, že konkrétní objednávka byla zaplacena.
Oddělte událost řetězce od události objednávky
Informace peněženky, že převod byl odeslán, je důkazem o její vlastní akci, nikoli úplným rozhodnutím o platbě. Přijímající backend musí sledovat zamýšlenou síť, ověřit skutečný převod a přiřadit jej k objednávce. Teprve poté může objednávka použít svou zásadu přijetí. Doručení infrastruktury je dalším provozním krokem po přijetí platby.
Udržujte tyto přechody výslovné v kódu i v jazyce pro zákazníka. Obrazovka může zobrazovat čekání, zjištěno nebo potvrzování, aniž by objednávku označila za zaplacenou. Nedovolte prohlížeči dodávat přijatou částku nebo přepisovat autoritativní stav. Uložte serverem vytvořenou nabídku a její pokyny, aby pozdější vyrovnání mohlo být posuzováno proti původní objednávce, nikoli proti měnícímu se košíku.
Použijte pravidla důvěry specifická pro daný řetězec
Různé sítě popisují důvěru v transakci odlišně. Vývojářská příručka Bitcoin vysvětluje, jak uzly vybírají řetězec s největším nahromaděným důkazem práce a jak mohou vznikat konkurenční bloky. Nedávno zjištěná transakce proto potřebuje zásadu pro hloubku potvrzení a možné změny řetězce. Neexistuje jediný počet potvrzení vhodný pro každé aktivum a obchodní riziko.
Dokumentace Ethereum k proof-of-stake vysvětluje finalitu kontrolních bodů, zatímco Solana dokumentuje stavy závazku processed, confirmed a finalized. Nepřekládejte tyto termíny ledabyle na jeden univerzální počet bloků. Zaznamenejte pravidlo specifické pro síť, zdroj informací a chování během nejistoty. Provozovatel by měl určit prahové hodnoty přijetí podle rizika platby a doručení, nikoli opsat číslo z nesouvisející pokladny.
Ověřte skutečný obsah převodu
Identifikujte příjemce, aktivum a částku ve správném řetězci. Platby tokeny vyžadují zamýšlenou identitu tokenu, nejen úspěšnou transakci na adresu. Ověřte příslušný úspěch provedení a důkaz převodu podle modelu daného řetězce. Parsujte celočíselné částky se správnou přesností aktiva, místo abyste důvěřovali formátovanému desetinnému číslu dodanému prohlížečem.
Platební pokyn musí zůstat vázán na svou původní trasu. Převod na jiné síti, jiný token se stejným symbolem nebo nesouvisející reference transakce by jej neměly splnit. Záznam o ověření by měl vysvětlit, co bylo zkontrolováno, a uchovat důkazy potřebné k přezkoumání rozhodnutí. Tato příručka popisuje obecné zásady vyrovnávání plateb, nikoli konkrétní implementaci služby.
Učiňte přiřazení k objednávce jednoznačným
Pevné přijímací adresy mohou přijmout několik objednávek s podobnými částkami. Existence odpovídajícího převodu neprokazuje, kterému zákazníkovi nebo objednávce má být připsán. Před přijímáním živých plateb definujte metodu přiřazení a zahrňte řešení kolizí. Uživatelem dodaná reference transakce stále vyžaduje ověření, že stejný převod již nebyl přiřazen jinam.
Představte si dvě faktury na stejnou částku na stejné trase v překrývajícím se časovém okně. Sledovací proces vidí jeden převod. Automaticky označit obě jako zaplacené je chybné; vybrat jednu bez dostatečných důkazů je také nebezpečné. Ponechte převod nepřiřazený nebo v kontrole, dokud zásada provozovatele nemůže stanovit platné přiřazení. Nejednoznačná shoda je stav, který je třeba řešit, nikoli důvod k vymýšlení jistoty.
Definujte stavy, které tolerují pozdní a měnící se důkazy
Platebnímu procesu prospívá malá sada jasných stavů, přičemž důkazy z řetězce jsou oddělené od rozhodnutí přijmout objednávku. Tato ilustrativní tabulka vysvětluje možné fáze, nejde o popis názvů stavů konkrétní služby. Každý přechod by měl mít ověřený důvod a přijetí platby by mělo zůstat oddělené od doručení infrastruktury.
Zahrňte pozdní, částečné a nadbytečné převody, vypršení nabídky a dočasně nedostupná data řetězce. Vypršení nezpůsobí, že skutečný převod zmizí. Pozdní platba může vyžadovat kontrolu, nikoli automatické přijetí nebo odmítnutí. Pokud se dříve zjištěná událost řetězce změní, přehodnoťte stav podle zdokumentované zásady, místo abyste každé oznámení sledovacího procesu považovali za nezvratnou pravdu.
| Ilustrativní stav | Význam | Další rozhodnutí |
|---|---|---|
| Čeká se | Žádný ověřený kvalifikovaný převod | Pokračujte ve sledování platné faktury |
| Zjištěno | Byl zjištěn relevantní převod | Zkontrolujte důvěru řetězce a přiřazení |
| Potvrzuje se | Pravidlo přijetí ještě není splněno | Sledujte, dokud zásada nedovolí rozhodnutí |
| Kontrola | Pozdní, částečné nebo nejednoznačné důkazy | Vyřešte podle zásady provozovatele |
| Přijato | Ověřená a vyrovnaná platba | Pokračujte k samostatnému pracovnímu postupu doručení |
Učiňte opakování bezpečná a pozorovatelná
Sledovací a vyrovnávací úlohy budou po přerušených připojeních nebo restartech procesů opakovat pokusy. Použijte stabilní identitu převodu, například řetězec a příslušný identifikátor transakce nebo převodu, abyste zabránili duplicitním připsáním. Uchovávejte průběh a rozhodnutí, aby stejná událost mohla být zpracována znovu bez zřízení druhé služby nebo změny přijaté nabídky.
Odlište neznámý výsledek od neúspěšné operace. Pokud požadavek na navazující systém vyprší, před opětovným odesláním prozkoumejte jeho autoritativní výsledek. Uchovávejte trvalé záznamy o přijatých a nejistých akcích. Omezte přístup k tokenům objednávek a interním důkazům, ale zachovejte dostatek informací pro vyšetření sporné platby. Spolehlivost zde znamená opakovatelná rozhodnutí, nikoli plynulou animaci v pokladně.
Vězte, co čekající objednávka ještě potřebuje
Objednávka může zůstat čekající, protože převod nebyl zjištěn, nebylo dosaženo požadované důvěry řetězce nebo je třeba zkontrolovat její přiřazení k faktuře. Uchovejte fakturu a veřejnou referenci transakce, zkontrolujte uvedená pravidla přijetí a použijte zamýšlený proces pomoci pro objednávku. Zpožděná aktualizace stavu sama o sobě není důvodem k odeslání další platby.
Postupujte podle pokynů a ověřeného stavu skutečné objednávky. Potvrzení platby by mělo označovat přijetí vyrovnaného převodu, zatímco doručení služby má samostatný stav. V žádostech o pomoc neuvádějte soukromé přístupové tokeny ani tajemství peněženky.
Váš praktický kontrolní seznam.
- Uložte neměnnou serverem vytvořenou nabídku.
- Ověřte řetězec, příjemce, aktivum a celočíselnou částku.
- Zdokumentujte pravidla přijetí specifická pro daný řetězec.
- Řešte kolize pevných adres bez hádání.
- Zabraňte duplicitním připsáním a nebezpečnému opakovanému odesílání.
- Otestujte případy pozdních, částečných, špatně směrovaných a změněných důkazů.
Podrobnosti, na kterých záleží.
Stačí k potvrzení platby hash transakce?+
Ne. Ověřte převod v zamýšleném řetězci, jeho obsah a důvěru, poté prokažte, že patří k objednávce a nebyl již připsán.
Může každá síť používat stejný práh potvrzení?+
Ne. Sítě vystavují různé modely důvěry a finality. Provozovatel musí definovat a otestovat zásadu přijetí vhodnou pro každou trasu.
Znamená potvrzená platba, že server je zřízen?+
Ne. Přijetí platby a doručení jsou samostatné události pracovního postupu. Stav zřizování sdělujte z jeho vlastního autoritativního procesu.
Jděte ke zdroji.
Tyto zdroje podporují technické koncepty v tomto průvodci. Před změnou produkčního systému se řiďte aktuální dokumentací.
- Vývojářská příručka Bitcoin: Chování blockchainu developer.bitcoin.org
- Ethereum: Proof of stake a finalita ethereum.org
- Solana: Závazek stavu RPC solana.com
Redakční vedení od SwissOctet. Příklady jsou ilustrativní. Specifikace služeb, dostupné možnosti a smluvní podmínky je nutné ověřit samostatně.