Alla Integration GuidesINTEGRATIONSGUIDE · API / BACKEND / MOBILEIntegrera kryptobetalningar med MochiPay API
Skapa och fråga beställningar från din ansökan. PHP Demo 1.2.0 stöder PHP 7.0-8.4 och ger order.php, callback.php, checkout.php med både presentationsgrenar, buntade lokala dialogtillgångar och en engelsk README. Använd på plats (standard) eller HPP med samma betalningsorder.
Demo walkthrough · illustrativ konfiguration · använda en liten riktig betalning för att verifiera din egen inställning.
Betalningsflöde illustration. På plats och HPP använder samma betalningsorder; din server verifierar sin slutliga status.Se hela betalningsresultatet
Demo illustration med provvärden. Kontrollera dessa resultat med hjälp av en riktig liten betalning i din egen inställning; utcheckningsbeloppet och bekräftelsekraven beror på ordern.
01 · Förbered ditt MochiPay-konto
- Skapa ett konto och aktivera ett abonnemang.
- Öppet Öppet Öppet PlånböckerVälj Add HD Wallet → Generate New, säkert säkerhetskopiera återställningsfrasen och spara plånboken. Aktivera tillgången/nätverket som du använder för testet.
- Ställ in ett igenkännligt kundanpassat Display Name i Profil.
- Öppet Öppet Öppet API-uppgifter kopiera din API-nyckel och sparade API-hemlighet. Om ingen hemlighet sparas, regenerera den för första gången installation och lagra den säkert. Regenerera en befintlig hemlighet ogiltigförklarar integrationer som använder den tidigare hemligheten.
Redo när: din prenumeration och mottagande plånbok är aktiva, och du har de referenser som behövs nedan.
Se den illustrerade kontoinställningenVälj på plats eller HPP
| Läge | Kundupplevelse | Serveransvar |
|---|
| På plats (standard) | Betalningsdialog på din egen domän, med exakt belopp, adress, nätverk, QR och status. | Skapa och lagra betalningsbindningen; fråga genom din egen backend och returnera endast en säker betalningsvy. |
|---|
| HPP | Omdirigera till den returnerade payment_url på MochiPay. | Lagra samma bindande och verifiera callbacks/returns server-till-server. |
|---|
Checkout läge är din integration preferens, inte ett API-fält. Båda länkarna använder en order. Skapa inte en annan order när du byter lägen. Classic SaaS stöder endast HPP.
Alla sex metoderna är tillgängliga: USDT_TRC20, USDC_ERC20, BTC_BITCOIN, ETH_ERC20, SOL_SOLANA och TRX_TRON. UPP är standardriktningen för unik mängd; DOWN stöds också. Aktivera en mottagande plånbok för varje erbjuden metod.
03 · Placera och betala en testorder
Öppna order.php. Skapa en liten demoorder med en unik handelsorderreferens och en konfigurerad betalningsmetod. Välj ON_SITE eller HPP; öppna den önskade länken som visas efter skapandet. Resultatet erbjuder även Embedded butiksutcheckning och PHP HPP omdirigeringslänkar; båda är implementerade i checkout.php. Den alternativa länken använder samma ordning.
- Matcha den valda tillgången och nätverket och skicka det exakta beloppet som visas på betalningssidan.
- Skicka exakt belopp på betalningssidan till den visade mottagande adressen. Runda inte eller återanvända en adress från en annan order.
- Vänta på de nödvändiga blockchain-bekräftelserna och MochiPay-ordern för att bli
PAID.
Stor-/API-exemplet kan prissätta produkten i USD. MochiPay låser omvandlingen när du skapar ordern; unika mängdjusteringar kan ändra det slutliga betalbara beloppet. Kassavärdet är det belopp som ska skickas.
Framgångskontroll: MochiPay-ordern visar PAID, med transaktionen registrerad. Att öppna webbläsarsidan ensam bevisar inte betalning.
04 · Verifiera resultatet och plånbokskvittot
Fråga beställningen av systemet order_id från din applikation. Acceptera betalning först efter att den autentiserade frågan är PAID och matchar ditt lagrade system-ID, säljarreferens, original belopp/valuta, vald tillgång/nätverk, mottagaradress, exakt betalningsbelopp och förväntat mottagen belopp. Uppfyll genom en atomär, idempotent lokal transaktion. callback.php demonstrerar denna verifiering för meddelanden och webbläsarreturer, med hjälp av privata demoposter. Den uppfyller inte order; ersätt temporära poster och återuppringningsTODO med din produktionsdatabas och fullgörandetransaktion. Läs den medföljande README.
Matcha betalningstransaktionen och ta emot adress med din MochiPay-order. Granska den mottagande plånboken eller blockchain explorer. Fonder är redan i din mottagande plånbok; det finns ingen plattform uttag begäran.
Använd en kompatibel plånbok och vänta på blockchain-bekräftelser när du flyttar pengar. Läs den mottagande Wallet Management Guide
Återhämtning och exakta mängder
Fortsätt försöket innan du skapar beställning. Den nuvarande PHP-demon sparar request_id och den exakta nyttolasten innan du skapar beställning. Efter en timeout utan ett sparat system-ID, försök igen med samma nyttolast och request_id; en känd order_id frågas istället. Handelsorderreferenser kan upprepas; använd systemets order-ID eller sparade begäran-ID för att identifiera en betalning. Bevara decimalsvarsvärden som strängar före PHP eller JavaScript flytande konvertering; visa pay_amount exakt. Den medföljande QR-koden kodar endast adressen, så kunder måste ange det visade beloppet.
När du bygger din egen API-klient
Användning X-Mochi-Key och X-Mochi-SignatureSkapa order tecknar den exakta JSON-kroppen med hjälp av Base64-kodade HMAC-SHA256. Query Order tecknar den exakta söksträngen utan det ledande frågetecknet. Håll signeringen hemlig server-side.
Om testet inte slutförs
Betalningsalternativet eller ordern kan inte skapas
Kontrollera prenumerationsstatus, en aktiv mottagande plånbok, betalningsmetodkod, referenser och växelkursparet för ordervalutan. För plugins, kontrollera också metoden är aktiverad för butikens omfattning / kund som används i testet.
Betalningen väntar fortfarande eller betalas
Jämför tillgången, nätverket, adressen och exakt betalbart belopp med transaktionen. Vänta på nödvändiga bekräftelser. Markera inte en butiksbeställning som endast betalas på en skärmdump eller webbläsaravkastning.
MochiPay betalas men min butik/applikation uppdateras inte
Kontrollera att meddelande/callback endpoints är allmänt tillgängliga över HTTPS och inte blockeras av autentisering eller brandvägg. Bekräfta integrationen kan fråga MochiPay och inspektera sina felloggar. Betalningslänkar ensam uppdaterar MochiPay, inte en extern butik.
Valfri begäran deduplikation
Befintliga integrationer fortsätter att fungera utan request_id. För att återanvända samma betalningsorder efter en timeout, lägg till en valfri request_id till den signerade JSON-kroppen innan du beräknar den befintliga HMAC-signaturen.
{"merchant_order_id":"STORE-1001","amount":25,"currency":"USD","payment_method":"USDT_TRC20","request_id":"STORE-1001:create:v1"}
Använd 1–64 ASCII-bokstäver, siffror, punkter, understreck, kolon eller bindestreck. En nyckel tillhör en handlare och en nyttolast. Återanvänd samma nyckel och nyttolast för nya försök; svar behåller de befintliga fälten och returnerar den ursprungliga beställningen i dess nuvarande tillstånd. Nycklar behålls utan automatisk utgång. För varje ny kassa, använd en ny request_id. merchant_order_id kan förbli densamma: 123, 124, 124 skapar tre oberoende systemordrar. En tidigare obetald order blockerar inte skapandet. Endast ett nytt försök av samma begäran återanvänder dess request_id och oförändrade nyttolast. WEB82.6 annonserar request-id-v1; fråga den sparade request_id för att lösa ett osäkert svar. Upprepade säljarreferenser är inte en återställningsnyckel. Distribuera WEB82.6 eller nyare före integrationspaketen; WEB82.7 lägger till HPP cancel/return.
HTTP 409 REQUEST_IN_PROGRESS: Försök med samma begäran igen efter Försök efter fördröjningen. HTTP 409 REQUEST_ID_CONFLICT: nyckeln återanvändes med en annan nyttolast. Generera inte en ny nyckel bara för att kringgå en timeout. ON_SITE och HPP kan båda använda de returnerade betalningsfälten eller payment_url som tidigare.