← Wszystkie wskazówki integracjiWYTYCZNE DOTYCZĄCE INTEGRACJI · API / BACKEND / MOBILEZintegruj płatności krypto z API MochiPay
Tworzenie i zapytanie zleceń płatniczych z aplikacji. PHP Demo 1.2.0 obsługuje PHP 7.0- 8.4 i zapewnia order.php, callback.php, checkout.php z obiema gałęziami prezentacji, połączone lokalne aktywa dialogowe i angielski README. Użyj na miejscu (domyślnie) lub HPP z tym samym zleceniem płatności.
Demo przejść · Ilustracyjna konfiguracja · Użyj małej prawdziwej płatności, aby zweryfikować własną konfigurację.
Ilustracja przepływu zapłaty. Na stronie internetowej i HPP używają tego samego zlecenia płatności; serwer weryfikuje swój status końcowy.Zob. całkowity wynik płatności
Demo ilustracja z wartościami próbki. Weryfikacja tych wyników przy użyciu naprawdę małej płatności w konfiguracji własnej; kwota checkout i wymagania potwierdzenia zależy od zamówienia.
01 · Przygotuj konto MochiPay
- Utwórz konto oraz aktywować subskrypcję.
- Otwórz Portfele, wybierz Dodaj HD Portfel → Generuj nowy, bezpiecznie kopię zapasową zwrotu i zapisać portfel. Włącz asset / network, którego użyjesz do testu.
- Ustaw rozpoznawalną nazwę wyświetlanego użytkownika Profil.
- Otwórz Kredyty API i skopiować klucz API i zapisać sekret API. Jeśli żaden sekret nie jest zapisany, zregeneruj go do ustawienia pierwszego czasu i przechowywać go bezpiecznie. Regeneracja istniejącego sekretu unieważnia integracje, które używają poprzedniego sekretu.
Gotowy, kiedy: Twój subskrypcja i otrzymujący portfel są aktywne, i masz referencje wymagane poniżej.
Zobacz ilustrowaną konfigurację konta →Wybierz miejsce lub HPP
| Tryb | Doświadczenie klienta | Odpowiedzialność za serwer |
|---|
| Na miejscu (domyślnie) | Okno płatności na własną domenę, z dokładną kwotą, adres, sieć, QR i status. | Utwórz i zapisz powiązanie płatności; zapytanie poprzez własne tło i zwróć tylko bezpieczny widok płatności. |
|---|
| HPP | Przekieruj do zwróconego payment_url na MochiPay. | Przechowuj to samo powiązanie i weryfikuj zwroty / server- to- serwer. |
|---|
Tryb checkout to preferencja integracyjna, a nie pole API. Oba linki używają jednego zamówienia. Nie tworzyć innego zamówienia podczas przełączania trybów. Classic SaaS obsługuje tylko HPP.
Dostępnych jest wszystkie sześć metod: USDT_TRC20, USDC_ERC20, BTC_BITCOIN, ETH_ERC20, SOL_SOLANA i TRX_TRON. W GÓRĘ jest domyślnym, unikalnym kierunkiem kwoty; DÓŁ jest również obsługiwany. Włącz portfel odbiorczy dla każdej oferowanej metody.
03 · Umieścić i zapłacić za wykonanie testu
Otwórz order.php. Utwórz małe zamówienie demonstracyjne, korzystając z unikalnego numeru zamówienia sprzedawcy i skonfigurowanej metody płatności. Wybierz ON_SITE lub HPP; otwórz preferowany link pokazany po utworzeniu. W rezultacie dostępna jest również wbudowana realizacja transakcji w sklepie i linki przekierowujące PHP HPP; oba są zaimplementowane w checkout.php. Alternatywne łącze wykorzystuje tę samą kolejność.
- Dopasuj wybrane aktywa i sieć i wyślij dokładną kwotę wyświetlaną na stronie płatności.
- Wyślij dokładna kwota na stronie płatności do wyświetlanego adresu odbioru. Nie należy zaokrąglać ani ponownie używać adresu z innej kolejności.
- Czekać na wymagane potwierdzenia blockchain i MochiPay zlecenie stać
PAID.
Przykład sklepu / API może wycenić produkt w USD. MochiPay blokuje konwersję przy tworzeniu zamówienia; unikalne korekty kwoty mogą zmienić ostateczną należną kwotę. Wartość checkout jest kwotą do wysłania.
Kontrola sukcesu: zamówienie MochiPay wyświetla PAID, z zapisaną transakcją. Otwarcie tylko strony zwrotnej przeglądarki nie dowodzi płatności.
04 · Sprawdzić wynik i pokwitowanie portfela
Zapytaj o zamówienie przez system order_id ze swojej aplikacji. Zaakceptuj płatność dopiero wtedy, gdy uwierzytelnione zapytanie to PAID i jest zgodne z przechowywanym identyfikatorem systemu, numerem referencyjnym sprzedawcy, oryginalnym kwota/waluta, wybranym aktywo/sieć, adresem odbiorcy, dokładną kwotą do zapłaty i oczekiwaną kwotą otrzymaną. Realizacja poprzez niepodzielną, idempotentną transakcję lokalną. callback.php demonstruje tę weryfikację powiadomień i zwrotów przeglądarki, korzystając z prywatnych rekordów demonstracyjnych. Nie realizuje zamówień; zamień tymczasowe rekordy i wywołanie zwrotne TODO na produkcyjną bazę danych i transakcję realizacji. Przeczytaj dołączony plik README.
Dopasuj transakcję płatniczą i adres do polecenia MochiPay. Przejrzyj otrzymujący portfel lub blockchain explorer. Fundusze są już w odbieranym portfelu; nie ma prośby o wycofanie platformy.
Użyj kompatybilnego portfela i czekaj na potwierdzenie blokady podczas przenoszenia funduszy. Przeczytaj poradnik zarządzania portfelem receiving- →
Odzyskiwanie i dokładne kwoty
Kontynuuj próbę przed utworzeniem zamówienia. Bieżąca wersja demonstracyjna PHP zapisuje request_id i dokładny ładunek przed utworzeniem zamówienia. Po upływie limitu czasu bez zapisanego identyfikatora systemu spróbuj ponownie użyć tego samego ładunku i request_id; Zamiast tego odpytywane jest znane order_id. Odniesienia do zamówień sprzedawcy mogą się powtarzać; użyj identyfikatora zamówienia systemowego lub zapisanego identyfikatora żądania, aby zidentyfikować płatność. Zachowaj dziesiętne wartości odpowiedzi jako ciągi znaków przed konwersją typu float PHP lub JavaScript; wyświetl dokładnie pay_amount. Dołączony kod QR koduje tylko adres, więc klienci muszą wpisać wyświetlaną kwotę.
Podczas budowania własnego klienta API
Stosowanie X-Mochi-Key oraz X-Mochi-Signature. Tworzenie porządku oznacza dokładne ciało JSON przy użyciu Base64- zakodowanego HMAC- SHA256. Zapytanie Zamówienie podpisuje dokładny ciąg zapytań bez głównego znaku zapytania. Zachowaj to w tajemnicy.
Jeżeli badanie nie zostało zakończone
Nie można utworzyć opcji płatności lub zlecenia
Sprawdź status subskrypcji, aktywny portfel otrzymujący, kod metody płatności, referencje i pary wymiany kursu dla waluty zamówienia. W przypadku wtyczek należy również sprawdzić, czy metoda jest włączona dla zakresu przechowywania / klienta używanego w teście.
Płatność nadal czeka lub niedopłacona
Porównaj składnik aktywów, sieć, adres i dokładną kwotę do zapłaty z transakcją. Poczekać na wymagane potwierdzenie. Nie należy oznaczać zlecenia sklepu wypłaconego wyłącznie na podstawie zrzutu ekranu lub zwrotu przeglądarki.
MochiPay jest płatny, ale mój sklep / aplikacja nie jest aktualizowana
Sprawdź, czy punkty końcowe powiadomień / połączeń zwrotnych są publicznie dostępne przez HTTPS i nie blokowane przez uwierzytelnianie lub firewall. Potwierdź integrację można zapytania MochiPay i sprawdzić jego dzienniki błędów. Linki płatności tylko zaktualizować MochiPay, a nie sklep zewnętrzny.
Opcjonalne odpowielanie wniosku
Istniejące integracje będą nadal działać bez request_id. Aby ponownie wykorzystać to samo zlecenie płatnicze po upływie limitu czasu, dodaj opcjonalny request_id do podpisanej treści JSON przed obliczeniem istniejącego podpisu HMAC.
{"merchant_order_id":"STORE-1001","amount":25,"currency":"USD","payment_method":"USDT_TRC20","request_id":"STORE-1001:create:v1"}
Użyj 1–64 liter, cyfr, kropek, podkreśleń, dwukropków i łączników ASCII ASCII. Klucz należy do jednego sprzedawcy i jednego ładunku żądania. Ponownie użyj tego samego klucza i ładunku przy ponownych próbach; odpowiedzi zachowują istniejące pola i zwracają pierwotne zamówienie w jego bieżącym stanie. Klucze przechowywane są bez automatycznego wygaśnięcia. Do każdej nowej transakcji użyj nowego request_id. merchant_order_id może pozostać taki sam: 123, 124, 124 tworzy trzy niezależne rozkazy systemowe. Wcześniejsze nieopłacone zamówienie nie blokuje tworzenia. Tylko ponowna próba tego samego żądania powoduje ponowne wykorzystanie jego request_id i niezmienionego ładunku. WEB82.6 ogłasza identyfikator żądania-v1; zapytaj zapisany request_id, aby rozwiązać niepewną odpowiedź. Powtarzające się referencje sprzedawcy nie stanowią klucza odzyskiwania. Wdróż WEB82.6 lub nowszy przed pakietami integracyjnymi; WEB82.7 dodaje HPP cancel/return.
HTTP 409 REQUEST_IN_PROGRESS: ponów próbę tego samego żądania po opóźnieniu Retry-After. HTTP 409 REQUEST_ID_CONFLICT: klucz został ponownie użyty z innym ładunkiem. Nie generuj nowego klucza tylko po to, aby ominąć limit czasu. Zarówno ON_SITE, jak i HPP mogą korzystać ze zwróconych pól płatności lub payment_url jak poprzednio.