Adres portfela to nie system płatności. To cel, nic więcej. Każdy, kto posiada ten ciąg znaków, może w dowolnym momencie wysłać na niego cokolwiek. W przypadku jednorazowej transakcji między dwiema osobami, które sobie ufają, może to wystarczyć. Ale jeśli prowadzisz produkt SaaS, marketplace lub sklep internetowy, wklejenie statycznego adresu na stronie kasy to przepis na operacyjny chaos. Będziesz spędzać dni na dopasowywaniu tajemniczych transakcji do prawdziwych klientów, zgadywaniu, kto i ile zapłacił, oraz sprzątaniu bałaganu, gdy ktoś wyśle niewłaściwy token w niewłaściwej sieci.

Aby zbudować coś, co się skaluje, musisz przestać myśleć jak puszka na datki, a zacząć myśleć jak ustrukturyzowany system płatności.

Dlaczego adres portfela zawodzi w dużej skali

Problemem jest kontekst, a raczej jego brak. Gdy klient kopiuje Twój adres portfela i wysyła kryptowaluty z giełdy lub portfela typu self-custody, blockchain rejestruje tylko to, co zostało przemieszczone: kwotę, znacznik czasu i dwa publiczne adresy. Nie rejestruje numeru Twojej faktury. Nie zawiera identyfikatora klienta. Nie mówi, czy przelew to odnowienie subskrypcji, proporcjonalna aktualizacja (pro-rated upgrade), czy zupełnie nowy zakup.

Rozważ firmę SaaS rozliczającą co miesiąc pięciuset klientów w stablecoinach. Jeśli każdy klient wysyła USDT na ten sam statyczny adres, Twój zespół księgowy staje przed koszmarem w arkuszu kalkulacyjnym. Jeden przelew wygląda identycznie jak drugi. Nie możesz stwierdzić, czy dwadzieścia dolarów, które wpłynęło o 2 rano, to odnowienie planu przez Klienta A, czy aktualizacja planu przez Klienta B w trakcie cyklu. Blockchain widzi liczbę. Twoje przedsiębiorstwo potrzebuje historii.

Platformy typu marketplace odczuwają ten ból po obu stronach transakcji. Musisz wiedzieć, że kupujący wpłacił środki, zatrzymać je, dopóki sprzedawca nie wyśle towaru, i zwolnić je dopiero po potwierdzeniu dostawy. Surowy adres nie daje programowej możliwości oddzielenia depozytu kupującego od przypadkowego przelewu przychodzącego lub środków samego dostawcy. E-commerce jest równie chaotyczny. Bez powiązania transakcji z konkretnym zamówieniem nie możesz wyzwolić procesu realizacji (fulfillment). Ktoś musi ręcznie przeszukiwać łańcuch, znaleźć przelew i zaktualizować Twoją bazę danych. Rób to dziesięć razy dziennie, a będziesz pomijać dopasowania. Rób to tysiąc razy, a będziesz tracić pieniądze.

Zmiana jest prosta, ale krytyczna. Przestań pytać, czy środki dotarły na adres. Zacznij pytać, czy konkretne żądanie płatności osiągnęło właściwy stan.

Buduj wokół żądania płatności

Niezawodny przepływ płatności kryptowalutowych traktuje żądanie płatności jako centralny obiekt. Adres portfela staje się tymczasowym kontenerem, który istnieje w służbie tego żądania. Żądanie niesie ze sobą metadane, które zmieniają transfer na blockchainie w rozpoznawalne zdarzenie biznesowe.

Zanim zaprezentujesz opcję płatności, zdefiniuj punkty danych, które czynią płatność identyfikowalną:

  • Identyfikator zakupu lub subskrypcji, abyś dokładnie wiedział, dlaczego środki są przesyłane.
  • Oczekiwana kwota, określona z dokładnością do części dziesiętnej.
  • Precyzyjny typ aktywa i sieci, ponieważ wysłanie USDT na Ethereum nie jest zamienne z wysłaniem go na Tron lub Polygon.
  • Odniesienie do klienta lub wewnętrznego konta.
  • Czas wygaśnięcia, aby oferta z częściową płatnością z marca przypadkowo nie zamknęła zamówienia w czerwcu.

Gdy klient kliknie „zapłać”, Twój system generuje żądanie zawierające te pola. Klient płaci następnie zgodnie z tym konkretnym żądaniem, a nie tylko na adres. Transakcja on-chain ma teraz tożsamość off-chain. Twój system wie, czego dotyczy płatność, zanim jeszcze zapyta eksplorator bloków.

Modeluj statusy w sposób rzetelny

Pieniądze na blockchainie przemieszczają się w etapach. Twój wewnętrzny system potrzebuje słownictwa, które odpowiada tym etapom, w przeciwnym razie Twoje zespoły inżynieryjne, wsparcia i operacyjne będą mówić obok siebie.

Zachowaj płaski i opisowy model. Nietechniczny agent wsparcia powinien móc odczytać status i wiedzieć, co przekazać klientowi.

  • Created: Żądanie istnieje, ale blockchain jeszcze nic nie pokazuje. Klient nie rozesłał jeszcze transakcji.
  • Detected: Twój monitoring wykrył odpowiednią transakcję w mempoolu lub w niedawnym bloku, ale nie posiada ona jeszcze ostateczności (finality). Nie wysyłaj produktu.
  • Confirming: Transakcja znajduje się w łańcuchu i gromadzi potwierdzenia. Łańcuchy poruszają się z różną prędkością. Bitcoin może wymagać sześciu bloków. Ethereum może wymagać dwunastu lub więcej, w zależności od Twojej tolerancji ryzyka. Twój system powinien respektować naturalne zachowanie sieci.
  • Completed: Płatność zgadza się z oczekiwaną kwotą, aktywem, siecią i kontekstem. Każdy zdefiniowany przez Ciebie warunek został spełniony. Teraz możesz zrealizować zamówienie, aktywować subskrypcję lub zwolnić środki z depozytu (escrow).
  • Expired: Klient przegapił okno płatności. Żądanie nie powinno przyjmować przyszłych płatności, chyba że zostanie ono wyraźnie reaktywowane.
  • Mismatch: Klient przesłał środki, ale coś jest nie tak. Kwota jest za niska, sieć się różni lub aktywo jest niezgodne. Przekaż to do wsparcia. Nie pozwól, aby Twój system realizacji zamówień próbował zgadywać.

Ten potok (pipeline) przekształca chaotyczny strumień danych z łańcucha w proces, który cała Twoja firma może zrozumieć i przeanalizować.

Przestań odpytywać. Zacznij słuchać.

Jednym z najszybszych sposobów na przepalenie budżetu infrastrukturalnego jest sprawianie, by Twój backend co kilka sekund pytał dostawcę, czy pieniądze już dotarły. Marnuje to zasoby po obu stronach i wprowadza niepotrzebne opóźnienia (latency).

Lepsza architektura wykorzystuje model powiadomień o statusie. Twój dostawca płatności lub infrastruktura węzłów powinien przesłać zdarzenie (event) do Twojego systemu w momencie zmiany statusu. Otrzymujesz webhook, gdy transakcja zostanie wykryta, kolejny, gdy jest potwierdzana, i ostatni, gdy zostanie ukończona lub zakończy się niepowodzeniem.

Dzięki temu Twój system pozostaje responsywny bez niepotrzebnego zużywania cykli procesora (CPU).