To decyzja o odpowiedzialności, nie o ideologii
Zespoły często opisują crypto payments jako wybór między „łatwym gatewayem” a „prawdziwym blockchainem”. To złe rozróżnienie. Oba modele mogą być produkcyjne. Prawdziwe pytanie brzmi: które odpowiedzialności powinny należeć do produktu, a które do wyspecjalizowanego providera.
Osiem granic do oceny
1. Customer payment UX
Jeżeli hosted checkout jest akceptowalny, provider znacząco zmniejsza zakres wdrożenia. Gdy payment ma zachowywać się jak natywny deposit do konta z trwałym lub per-intent adresem, custom wallet infrastructure staje się bardziej naturalna.
2. Generowanie adresów
Ustal, czy potrzebujesz adresu per płatność, per customer, per merchant, czy wystarczy invoice address wygenerowany przez providera. Address allocation wpływa na matching, privacy, treasury i recovery.
3. Keys i custody
Przy custom wallets trzeba jawnie ustalić, kto może autoryzować outgoing transactions, jak chronione są klucze, jak izolowane są signery i jak wygląda incident path. Managed provider przenosi znaczną część tej odpowiedzialności poza aplikację.
4. Obserwacja chaina
Provider udostępnia order status model. Custom system potrzebuje własnej strategii RPC/indexer, checkpointów, retry, finality policy i replay. Jeśli system nie potrafi bezpiecznie odtworzyć brakujących bloków albo zduplikowanych eventów, observer nie jest jeszcze produkcyjny.
5. Konwersja i settlement
Jeśli firma finalnie chce EUR lub USD, provider-native conversion i withdrawal mogą uprościć operacje. Jeśli firma chce trzymać, routować lub programowo używać stablecoinów, custom treasury daje większą elastyczność.
6. Product ledger
Ta odpowiedzialność zostaje po stronie produktu w obu modelach. Provider state i blockchain state są dowodem. Product ledger jest authoritative interpretacją biznesową tego dowodu.
7. Exceptions i support
Kto analizuje wrong network, unsupported token, late transfer, duplicate callback, refund mismatch lub settlement discrepancy? Odpowiedź musi istnieć w architekturze przed launch.
8. Reconciliation
Gateway daje provider reports; custom infrastructure daje raw chain evidence. Żadne z nich automatycznie nie uzgadnia invoice systemu, product ledgera, refundów, fee i bank records.
Macierz decyzji
| Pytanie | Managed provider, gdy… | Custom wallets, gdy… |
|---|---|---|
| Crypto to głównie checkout? | Tak | Nie — to core product behavior |
| Potrzebny fiat settlement? | Tak, funkcje providera pomagają | Niekoniecznie lub masz osobne rails |
| Dedykowane/trwałe adresy? | Nie są kluczowe | Tak |
| Direct treasury automation? | Ograniczona | Tak |
| Najszybszy launch? | Zwykle tak | Jeśli infrastruktura już istnieje |
| Zespół umie operować keys/chain? | Nie jest konieczne | Tak, bezpośrednio lub przez infra vendorów |
Nie porównuj wyłącznie transaction fee
Custom infrastructure może ominąć processing fee gatewaya, ale dodaje koszt engineeringu i operacji: wallet infrastructure, monitoring, RPC/indexing, incident response, reconciliation, security review i support. Porównuj total cost of ownership przy docelowym wolumenie i złożoności produktu.
Hybrid architecture
Wiele dojrzałych produktów używa obu modeli. Managed gateway obsługuje merchant checkout i fiat settlement, a product-owned wallets treasury, partner payouts lub native on-chain features. Internal ledger staje się granicą integracyjną między railami.
Prosta reguła rekomendacji
Jeżeli usunięcie blockchaina nie zmieni core modelu produktu, zacznij od managed gateway. Jeżeli bez blockchaina przestaje działać core account, deposit, settlement lub treasury behavior — projektuj custom wallet infrastructure.
Security i odpowiedzialność operacyjna
Custom model nie oznacza automatycznie przechowywania raw private keys na serwerach aplikacji. Nowoczesna wallet infrastructure może dostarczać MPC, policy controls, programmable signing lub user-controlled authorization. Zespół nadal musi jednak ustalić, kto może inicjować transakcje, które akcje wymagają review, jak separowane są uprawnienia i jak ograniczany jest incident blast radius.
W managed-provider model więcej kontroli znajduje się poza granicą produktu. To ogranicza bezpośrednią odpowiedzialność, ale tworzy dependency na provider availability, API contracts, account limits i provider compliance decisions. Dlatego architektura produkcyjna powinna zawierać provider-health monitoring oraz manual operational path.
Provider migration i portability
Częsty błąd to rozlewanie provider IDs i statusów po wszystkich tabelach biznesowych. Wtedy zmiana providera staje się nieproporcjonalnie droga. Utrzymuj provider adapter za product-owned payment intent i własnym state modelem. Provider powinien być wymienialny bez przebudowy invoices, entitlementów czy internal ledgera.
Skala zmienia decyzję
Przy małym i średnim wolumenie engineering simplicity często ma większe znaczenie niż marginalny transaction cost. Przy większej skali economics, routing control, treasury automation i liquidity strategy mogą uzasadniać przejęcie większej części infrastruktury. Decyzję należy więc oceniać na realistycznych założeniach volume i operations.
Capability zespołu jest częścią architektury
Technicznie elegancki custom wallet system nadal jest złą decyzją, jeśli nikt nie odpowiada za chain operations, key-policy review, incident response, reconciliation i security. Z kolei doświadczony zespół FinTech/blockchain może wybrać custom właśnie dlatego, że te kompetencje już posiada.
Co dalej
Zacznij od głównego przewodnika po architekturze USDC payments. Jeśli pasuje model managed, przejdź do integracji CoinGate. Jeśli custom wallets — zaprojektuj internal ledger i reconciliation przed startem.