Wykrycie transakcji, potwierdzenie w łańcuchu, powiązanie z zamówieniem i realizacja usługi to osobne kroki. Zweryfikuj właściwy łańcuch, zasób, odbiorcę i kwotę; zastosuj udokumentowaną politykę akceptacji; i zapewnij idempotentne uzgodnienie. Sama referencja transakcji, zrzut ekranu lub przycisk w przeglądarce nie mogą ustalić, że konkretne zamówienie zostało opłacone.
Oddziel zdarzenie łańcucha od zdarzenia zamówienia
Informacja portfela o wysłaniu transferu jest dowodem jego własnego działania, a nie pełną decyzją o płatności. Backend odbierający musi zaobserwować zamierzoną sieć, zweryfikować rzeczywisty transfer i powiązać go z zamówieniem. Dopiero wtedy zamówienie może zastosować swoją politykę akceptacji. Realizacja infrastruktury to kolejny krok operacyjny po akceptacji płatności.
Utrzymuj te przejścia jako jawne zarówno w kodzie, jak i w języku obsługi klienta. Ekran może pokazywać oczekiwanie, wykrycie lub potwierdzanie bez nazywania zamówienia opłaconym. Nie pozwól przeglądarce dostarczać zaakceptowanej kwoty ani nadpisywać autorytatywnego statusu. Przechowuj wycenę utworzoną po stronie serwera i jej instrukcje, aby późniejsze uzgodnienie można było ocenić względem pierwotnego zamówienia, a nie zmieniającego się koszyka.
Stosuj zasady zaufania specyficzne dla łańcucha
Różne sieci opisują zaufanie do transakcji w różny sposób. Przewodnik dla programistów Bitcoin wyjaśnia, jak węzły wybierają łańcuch z największym skumulowanym dowodem pracy i jak mogą wystąpić konkurencyjne bloki. Transakcja widziana niedawno wymaga zatem polityki dotyczącej głębokości potwierdzeń i możliwych zmian łańcucha. Nie istnieje jedna liczba potwierdzeń odpowiednia dla każdego zasobu i ryzyka komercyjnego.
Dokumentacja Ethereum dotycząca proof-of-stake wyjaśnia finalność punktów kontrolnych, natomiast Solana dokumentuje stany zobowiązania processed, confirmed i finalized. Nie tłumacz tych terminów swobodnie na jedną uniwersalną liczbę bloków. Zapisz zasadę specyficzną dla sieci, źródło informacji i zachowanie w warunkach niepewności. Operator powinien określić progi akceptacji względem ryzyka płatności i dostawy, a nie kopiować liczby z niepowiązanego procesu realizacji zamówienia.
Zweryfikuj rzeczywisty ładunek transferu
Zidentyfikuj odbiorcę, zasób i kwotę w prawidłowym łańcuchu. Płatności tokenami wymagają zamierzonej tożsamości tokena, a nie tylko udanej transakcji na adres. Zweryfikuj powodzenie odpowiedniego wykonania i dowód transferu zgodnie z modelem łańcucha. Analizuj kwoty całkowite z właściwą precyzją zasobu, zamiast ufać sformatowanej liczbie dziesiętnej dostarczonej przez przeglądarkę.
Instrukcja płatności musi pozostać powiązana z pierwotną trasą. Transfer w innej sieci, inny token o tym samym symbolu lub niepowiązana referencja transakcji nie powinny jej spełniać. Rekord weryfikacji powinien wyjaśniać, co sprawdzono, i zachowywać dowody potrzebne do przeglądu decyzji. Ten przewodnik opisuje ogólne zasady uzgadniania płatności, a nie konkretną implementację usługi.
Zadbaj o jednoznaczne powiązanie z zamówieniem
Stałe adresy odbiorcze mogą otrzymywać kilka zamówień o podobnych kwotach. Istnienie pasującego transferu nie dowodzi, któremu klientowi lub zamówieniu należy przypisać uznanie. Zdefiniuj metodę powiązania przed przyjmowaniem płatności na żywo i uwzględnij obsługę kolizji. Referencja transakcji podana przez użytkownika nadal wymaga walidacji, że ten sam transfer nie został już przypisany gdzie indziej.
Wyobraź sobie dwie faktury na tę samą kwotę na tej samej trasie w nakładającym się okresie. Obserwator widzi jeden transfer. Automatyczne oznaczenie obu jako opłaconych jest błędne; wybranie jednej bez wystarczających dowodów jest również niebezpieczne. Pozostaw transfer nieprzypisany lub w przeglądzie, dopóki polityka operatora nie pozwoli ustalić ważnego powiązania. Niejednoznaczne dopasowanie to stan do obsłużenia, a nie powód do tworzenia fałszywej pewności.
Zdefiniuj stany tolerujące późne i zmieniające się dowody
Proces płatności zyskuje dzięki małemu zestawowi jasnych stanów, w których dowody z łańcucha są oddzielone od decyzji o akceptacji zamówienia. Ta przykładowa tabela wyjaśnia możliwe etapy, a nie opisuje nazw statusów konkretnej usługi. Każde przejście powinno mieć zweryfikowany powód, a akceptacja płatności powinna pozostać odrębna od realizacji infrastruktury.
Uwzględnij późne, częściowe i nadmiarowe transfery, wygaśnięcie wyceny oraz tymczasowo niedostępne dane łańcucha. Wygaśnięcie nie sprawia, że rzeczywisty transfer znika. Późna płatność może wymagać przeglądu, a nie automatycznej akceptacji lub odrzucenia. Jeśli wcześniej zaobserwowane zdarzenie łańcucha się zmieni, ponownie oceń stan zgodnie z udokumentowaną polityką, zamiast traktować każde powiadomienie obserwatora jako nieodwracalną prawdę.
| Przykładowy stan | Znaczenie | Następna decyzja |
|---|---|---|
| Oczekiwanie | Brak zweryfikowanego kwalifikującego się transferu | Kontynuuj obserwację ważnej faktury |
| Wykryto | Zaobserwowano istotny transfer | Sprawdź zaufanie łańcucha i powiązanie |
| Potwierdzanie | Reguła akceptacji jeszcze nie spełniona | Obserwuj, aż polityka pozwoli na decyzję |
| Przegląd | Późne, częściowe lub niejednoznaczne dowody | Rozstrzygnij zgodnie z polityką operatora |
| Zaakceptowano | Zweryfikowana i uzgodniona płatność | Przejdź do osobnego procesu realizacji |
Zadbaj o bezpieczne i obserwowalne ponowienia
Obserwatorzy i zadania uzgadniania będą ponawiać po przerwanych połączeniach lub restartach procesów. Użyj stabilnej tożsamości transferu, takiej jak łańcuch i odpowiedni identyfikator transakcji lub transferu, aby zapobiec podwójnym uznaniom. Utrwal postęp i decyzje, aby to samo zdarzenie można było przetworzyć ponownie bez udostępniania drugiej usługi lub zmiany zaakceptowanej wyceny.
Odróżnij nieznany wynik od nieudanej operacji. Jeśli żądanie podrzędne przekroczy limit czasu, sprawdź jego autorytatywny wynik przed ponownym przesłaniem. Prowadź trwałe rejestry zaakceptowanych i niepewnych działań. Ogranicz dostęp do tokenów zamówień i wewnętrznych dowodów, zachowując wystarczające informacje do zbadania zakwestionowanej płatności. Niezawodność w tym zakresie polega na powtarzalnych decyzjach, a nie na płynnej animacji w procesie realizacji zamówienia.
Wiedz, czego nadal wymaga zamówienie w stanie oczekiwania
Zamówienie może pozostać w stanie oczekiwania, ponieważ transfer nie został zaobserwowany, wymagane zaufanie łańcucha nie zostało osiągnięte lub jego powiązanie z fakturą wymaga przeglądu. Zachowaj fakturę i publiczną referencję transakcji, sprawdź podane zasady akceptacji i skorzystaj z zamierzonego procesu pomocy dla zamówienia. Opóźniona aktualizacja statusu sama w sobie nie jest powodem do wysłania kolejnej płatności.
Postępuj zgodnie z instrukcjami i zweryfikowanym statusem rzeczywistego zamówienia. Potwierdzenie płatności powinno wskazywać akceptację uzgodnionego transferu, natomiast realizacja usługi ma osobny status. Nie umieszczaj prywatnych tokenów dostępu ani sekretów portfela w prośbach o pomoc.
Twoja praktyczna lista kontrolna.
- Utrwal niezmienną wycenę utworzoną po stronie serwera.
- Zweryfikuj łańcuch, odbiorcę, zasób i kwotę całkowitą.
- Udokumentuj zasady akceptacji specyficzne dla łańcucha.
- Obsługuj kolizje stałych adresów bez zgadywania.
- Zapobiegaj podwójnym uznaniom i niebezpiecznym ponowieniom.
- Przetestuj przypadki późnych, częściowych, błędnie skierowanych i zmienionych dowodów.
Szczegóły, które mają znaczenie.
Czy hash transakcji wystarcza do potwierdzenia płatności?+
Nie. Zweryfikuj transfer w zamierzanym łańcuchu, jego ładunek i zaufanie, a następnie ustal, że należy do zamówienia i nie został już uznany.
Czy każda sieć może używać tego samego progu potwierdzenia?+
Nie. Sieci udostępniają różne modele zaufania i finalności. Operator musi zdefiniować i przetestować politykę akceptacji odpowiednią dla każdej trasy.
Czy potwierdzona płatność oznacza, że serwer jest udostępniony?+
Nie. Akceptacja płatności i dostarczenie usługi to odrębne zdarzenia w przepływie pracy. Status udostępnienia należy komunikować z jego własnego, autorytatywnego procesu.
Przejdź do źródła.
Te źródła wspierają koncepcje techniczne w tym przewodniku. Przed zmianą systemu produkcyjnego zapoznaj się z aktualną dokumentacją.
- Przewodnik dla programistów Bitcoin: zachowanie łańcucha bloków developer.bitcoin.org
- Ethereum: proof of stake i finalność ethereum.org
- Solana: zobowiązanie stanu RPC solana.com
Wskazówki redakcyjne SwissOctet. Przykłady są ilustracyjne. Specyfikacje usług, dostępne opcje i warunki umowne należy zweryfikować osobno.