Jak przetestować bramkę płatności kryptowalutowych przed uruchomieniem

Nie możesz przetestować bramki płatności kryptowalutowych w piaskownicy na Payora, ponieważ Payora jej nie ma: brak trybu testnet, brak kluczy API w trybie testowym, brak fałszywych faktur. Zamiast tego sprawdzasz prawdziwe zrealizowane zakupy na /demo, odtwarzasz webhook, który sam podpisałeś, w swoim własnym handlerze, a następnie wysyłasz jedną prawdziwą płatność w wysokości około dolara na swoją własną fakturę w taniej sieci. Ten ostatni krok kosztuje grosze i udowadnia jedną rzecz, której piaskownica nigdy nie mogła udowodnić.

Dlaczego nie ma piaskownicy i dlaczego to nie jest problem, który myślisz, że jest

Piaskownica to symulator. Pozwala ci ćwiczyć twój kod w odniesieniu do fikcji, którą napisała bramka. To jest naprawdę przydatne dla procesorów kart, gdzie nabywca, silnik ryzyka i tory rozliczeniowe są całkowicie nieprzezroczyste i nie masz innej drogi.

Kryptowaluty są inne. Część, która psuje się w produkcji, prawie nigdy nie jest wywołaniem API. To jest łańcuch: płatność, która trafia na niewłaściwą sieć, zablokowanie kursu, które wygasło, podczas gdy kupujący kopiował adres, polityka potwierdzenia, której nikt nie przeczytał, adres, który serwer wyprowadził z niewłaściwego klucza. Piaskownica tworzy opłaconą fakturę z niczego. Nie mówi ci nic o tym wszystkim. Co gorsza, mówi ci, że wszystko jest w porządku, co jest najdroższym kłamstwem, jakie może wyprodukować test.

Więc uczciwy sposób na przetestowanie bramki płatności kryptowalutowych to drabina: wszystko, co możesz zweryfikować za darmo najpierw, a potem jedna mała rzeczywista płatność, która uruchamia cały proces od początku do końca. Oto kolejność, w jakiej bym to przeprowadził.

1. Spójrz na prawdziwe zakupy, zanim napiszesz linię kodu

Otwórz /demo. Generuje on aktywną fakturę na prawdziwym hostowanym checkout, na tej samej stronie, którą zobaczą Twoi nabywcy. Żadnego konta, żadnego kodu. Obserwuj, co się naprawdę dzieje: jak działa wybór monet, jak wygląda okno blokady kursu, co widzi nabywca, gdy transakcja jest jeszcze niepotwierdzona, co się dzieje, gdy czas się kończy.

Pięć minut tutaj oszczędza kłótnię później, ponieważ większość błędów integracyjnych zaczyna życie jako błędny model mentalny przepływu. Przeczytaj /docs obok i dopasuj każdy ekran do pól faktury za nim. Następnie utwórz swoje konto na /register i zdobądź swój klucz API i api_secret.

2. Ćwicz swój handler webhooka bez wydawania czegokolwiek

To jest to. Twój handler to kod, który zamienia "pieniądze dotarły" na "klient otrzymał swoją rzecz", i to jest element, który możesz testować wyczerpująco za darmo, ponieważ posiadasz sekret, który podpisuje webhook. Cokolwiek Payora może podpisać, ty też możesz podpisać.

Schemat to zwykły HMAC. Podpis to hex(hmac_sha256(timestamp . '.' . rawBody, api_secret)), wysłany w X-Payora-Signature, z tym samym znacznikiem czasu w X-Payora-Timestamp. Znacznik czasu musi być w granicach ±120 sekund od teraz, a każda dostawa zawiera nagłówek Idempotency-Key który pozostaje stabilny podczas ponownych prób tego samego zdarzenia. Podpisz surowybajty ciała, a nie ponownie zakodowana tablica — ponowne kodowanie to klasyczny powód, dla którego poprawny podpis nie działa.

<?php
// Sign a webhook exactly the way Payora signs one, and POST it at your own endpoint.
$secret = 'YOUR_API_SECRET';                          // the secret your handler verifies with
$url    = 'https://yoursite.com/payora-webhook.php';  // your endpoint, on your dev host

$body = json_encode([
    'event'      => 'invoice.paid',
    'invoice_id' => 'inv_local_1',
    'order_id'   => '1001',
    'status'     => 'paid',
    'amount'     => '1.00',
    'currency'   => 'USD',
    'asset'      => 'USDT',
    'network'    => 'tron',
], JSON_UNESCAPED_SLASHES);

$ts  = (string) time();
$sig = hash_hmac('sha256', $ts . '.' . $body, $secret);   // lowercase hex

$ch = curl_init($url);
curl_setopt_array($ch, [
    CURLOPT_POST           => true,
    CURLOPT_POSTFIELDS     => $body,          // send the RAW body you signed
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_HTTPHEADER     => [
        'Content-Type: application/json',
        'X-Payora-Timestamp: ' . $ts,
        'X-Payora-Signature: ' . $sig,
        'Idempotency-Key: whk_local_1',
    ],
]);
$out  = curl_exec($ch);
$code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
echo "$code\n$out\n";

Wskaź to na swój własny punkt końcowy dewelopera, a masz generator webhooków, który nic nie kosztuje i działa w pętli. Strona weryfikacyjna — porównanie w stałym czasie, kontrole okna, dlaczego musisz odczytać surowy strumień wejściowy — jest szczegółowo omówiona w weryfikacji podpisu webhooka z HMAC-SHA256.

3. Testy, które rzeczywiście wychwytują błędy

Uruchom każdy z nich przeciwko swojemu handlerowi i sprawdź bazę danych, a nie tylko status HTTP. Oczekiwane wyniki to nie przypisy; to jest test.

• Poprawny podpis → 200, zamówienie oznaczone jako opłacone, dokładnie raz.
• Ten sam webhook dostarczony dwa razy (ten sam Idempotency-Key) → nadal dokładnie jedno opłacone zamówienie. Brak podwójnego kredytu, brak drugiego klucza licencyjnego, brak drugiej etykiety wysyłkowej. To najczęstszy rzeczywisty błąd w integracjach płatności, a ponowne próby są normalne, a nie wyjątkowe.
• Zmodyfikowane ciało z dawnym podpisem — zmień amount z 1.00 na 1000.00, zachowaj podpis → odrzucone, zamówienie NIE opłacone.
• Błędny lub brakujący podpis → odrzucone. Pusty X-Payora-Signature musi zakończyć się niepowodzeniem dokładnie tak jak błędny.
• Nieaktualny znacznik czasu — ustaw go na dziesięć minut temu → odrzucony w oknie, mimo że HMAC jest ważny.
• Nieznany lub obcy identyfikator faktury → odrzucony bezbłędnie. Brak błędu krytycznego, brak 500, brak półnapisanego wiersza.
• Twój punkt końcowy zwraca 500 → ponowne próby, które następują, nie mogą być podwójnie stosowane. Zakończ połączenie z bazą danych w trakcie obsługi, jeśli chcesz być pewny.
• Porównanie w stałym czasie — użyj hash_equals(), nigdy ==. I nigdy nie loguj api_secret, nie na poziomie debugowania, nie skrócone, nie raz.

Jeśli wszystkie osiem przejdzie, twój handler jest w lepszej formie niż większość integracji na żywo. Zauważ teraz, czego żaden z nich nie udowodnił: że pieniądze mogą faktycznie do ciebie dotrzeć.

4. Jedna mała rzeczywista płatność do siebie

Teraz wydaj dolara. Utwórz fakturę przez API lub link do płatności z /accept-payments, otwórz kasę i zapłać z własnego portfela, na własną fakturę, z około 1 dolarem.

Wybierz tanią, szybką sieć, aby to kosztowało centy, a nie dolary: TON (Gram), Tron i Solana wszystkie potwierdzają w kilka sekund za ułamek centa. Nie uruchamiaj tego na głównym łańcuchu Bitcoin, chyba że Bitcoin jest tym, co faktycznie wysyłasz — będziesz czekać dziesięć minut na próbę i płacić za to przywilej.

Ta pojedyncza płatność jest jedynym testem, który sprawdza cały łańcuch: blokada kursu, wykrywanie on-chain, potwierdzenie dla polityki tego aktywa (zobacz ile potwierdzeń jest bezpiecznych), podpisany webhook, twoja baza danych. Jeśli działa, twoja integracja działa. Jeśli nie, awaria jest rzeczywista i konkretna — co dokładnie chcesz odkryć w cichy wtorek, a nie podczas uruchomienia.

5. Udowodnij, że możesz wypłacić pieniądze

Wszyscy to pomijają. To krok, który boli.

Zanim weźmiesz płatność od jednego klienta, wypłać dolara z powrotem do portfela, który kontrolujesz. Sprawdź /balance, zrób wypłatę lub transfer, obserwuj, jak ląduje. Jeśli planujesz płacić dostawcom lub partnerom, przeprowadź jedną partię przez /mass-payouts z dwiema liniami i trywialnymi kwotami, i potwierdź, że krok offline podpisywania działa na twojej rzeczywistej maszynie z twoim rzeczywistym materiałem klucza — nie w teorii, na maszynie.

Bramka, do której możesz otrzymywać, ale nie możesz wypłacać, nie jest bramką. To pułapka z ładną stroną kasy. Odkrycie tego z zablokowanym 1 dolarem to historia, którą opowiesz później. Odkrycie tego z zablokowanymi 40 000 dolarami to zupełnie inny popołudnie.

6. Zweryfikuj, czy pochodne adresy są naprawdę twoje

To jest specyficzne dla ustawień non-custodial i jest niepodlegające negocjacjom. Payora generuje adresy do odbioru tylko z materiału klucza publicznego — twojego xPub lub głównego klucza publicznego. Klucze prywatne nigdy nie dotykają serwera. To jest cały model bezpieczeństwa i niesie ze sobą jeden twardy wymóg: xPub, który wkleiłeś, musi być tym, który rzeczywiście należy do twojego portfela.

Więc zweryfikuj to niezależnie. Weź adres, który serwer wygenerował dla faktury, samodzielnie wygeneruj ten sam indeks z twojego xPub — w oprogramowaniu portfela lub z dowolnej offline'owej biblioteki HD-portfela — i porównaj ciągi znak po znaku. Jeśli się zgadzają, każda płatność trafia gdzieś, z czego możesz skorzystać. Jeśli nie, każda płatność jest utracona, w milczeniu, z zielonym potwierdzeniem i opłaconą zamówieniem, aby ci towarzyszyć. Wyjaśnienie xPub i HD portfelaprzechodzi przez proces generacji.

Zrób to przed uruchomieniem. Nie po pierwszej skardze.

Wymiana, powiedziana szczerze

Brak piaskownicy oznacza, że twój pierwszy prawdziwy test kosztuje trochę pieniędzy i trochę uwagi. To jest rzeczywisty koszt i nie będę udawać inaczej. To, co otrzymujesz w zamian, to test, który był prawdziwy. Piaskownica dałaby ci zielony znacznik za wywołanie API i nic by ci nie powiedziała o zablokowaniu kursu, polityce potwierdzeń, ścieżce wypłaty, ani czy adresy były twoje — cztery rzeczy, które naprawdę decydują o tym, czy otrzymasz zapłatę.

Dolar, popołudnie i lista kontrolna pokonują symulator, który się z tobą zgadza.

Gotowy do uruchomienia? Utwórz darmowe konto w /register, wyemituj swoją pierwszą fakturę z /accept-payments, i pracuj nad listą. Cała drabina zajmuje około godziny i kosztuje około dolara.