‡ Alle integrationsvejledningerINTEGRATIONSVEJLEDNING · API / BACKEND / MOBILEIntegrer Crypto betalinger med MochiPay API
Opret og spørg om betalingsordrer fra din ansøgning. PHP Demo 1.2.0 understøtter PHP 7.0- 8.4 og giver order.php, callback.php, checkout.php med både præsentationsgrene, bundtede lokale dialogaktiver og en engelsk README. Brug on- site (standard) eller HPP med samme betalingsordre.
Demo walkthrough · illustrativ konfiguration · bruge en lille reel betaling til at bekræfte din egen opsætning.
Udbetaling- flow illustration. On- site og HPP bruger den samme betalingsordre; din server kontrollerer sin endelige status.Se hele betalingsresultatet
Demo illustration med prøveværdier. Verificer disse resultater ved hjælp af en reel lille betaling i din egen setup; checkout beløb og bekræftelseskrav afhænger af ordren.
01 · Forbered din MochiPay-konto
- Opret en konto og aktivere et abonnement.
- Åbn Tegnebøger, vælge Tilføj HD tegnebog → Generér ny, sikkert sikkerhedskopiere opsving sætning og gemme tegnebogen. Aktivér det aktiv / netværk du vil bruge til testen.
- Sæt en genkendelig bruger- vender Display Navn i Profil.
- Åbn API-afstemning og kopiere din API-nøgle og gemt API hemmelighed. Hvis ingen hemmelighed er gemt, regenerere det for første gang setup og gemme det sikkert. Regenererer en eksisterende hemmelig ugyldiggør integration, der bruger den tidligere hemmelighed.
Klar når: dit abonnement og modtager tegnebog er aktive, og du har de nødvendige legitimationer nedenfor.
Se den illustrerede konto setup →Vælg on- site eller HPP
| Tilstand | Kundeoplevelse | Serveransvar |
|---|
| On- site (standard) | Betalingsdialog på dit eget domæne med præcis beløb, adresse, netværk, QR og status. | Opret og gem betalingsbindingen; forespørgsel gennem din egen motor og returnér kun en sikker betalingsvisning. |
|---|
| HPP | Omdiriger til den returnerede payment_url på MochiPay. | Gem den samme binding og verificer callbacks / returnerer server- to- server. |
|---|
Checkout tilstand er din integration præference, ikke et API-felt. Begge links bruger én ordre. Opret ikke en anden rækkefølge når du skifter tilstand. Classic SaaS understøtter kun HPP.
Alle seks metoder er tilgængelige: USDT_TRC20, USDC_ERC20, BTC_BITCOIN, ETH_ERC20, SOL_SOLANA og TRX_TRON. OP er standardretningen for det unikke beløb; DOWN er også understøttet. Aktiver en modtagende tegnebog for hver tilbudt metode.
03 · Placer og betal en testordre
Åbn order.php. Opret en lille demoordre ved hjælp af en unik handelsordrereference og en konfigureret betalingsmetode. Vælg ON_SITE eller HPP; åbne det foretrukne link, der vises efter oprettelsen. Resultatet tilbyder også Embedded butiksudtjekning og PHP HPP omdirigeringslinks; begge er implementeret i checkout.php. Det alternative link bruger samme rækkefølge.
- Match det valgte aktiv og netværk, og send det nøjagtige beløb, der vises på betalingssiden.
- Send det nøjagtige beløb på betalingssiden til den viste modtagelsesadresse. Må ikke runde eller genbruge en adresse fra en anden ordre.
- Vent på de nødvendige blokkæden bekræftelser og MochiPay ordre til at blive
PAID.
Den butik / API eksempel kan pris produktet i USD. MochiPay låser konverteringen, når du opretter ordren; unikke beløb justeringer kan ændre det endelige skyldige beløb. Checkout værdien er det beløb, der skal sendes.
Succescheck: MochiPay ordren viser betaling, med transaktionen registreret. Åbning af browser retursiden alene beviser ikke betaling.
04 · Bekræft resultatet og kvittering for tegnebogen
Forespørg på ordren fra systemet order_id fra din ansøgning. Accepter først betaling, efter at den godkendte forespørgsel er PAID og matcher dit lagrede system-id, forhandlerreference, originale beløb/valuta, valgte aktiv/netværk, modtagende adresse, nøjagtigt betalbar beløb og forventet modtaget beløb. Opfyld gennem en atomær, idempotent lokal transaktion. callback.php demonstrerer denne verifikation for meddelelser og browserreturneringer ved hjælp af private demo-poster. Det opfylder ikke ordrer; erstatte midlertidige poster og callback TODO med din produktionsdatabase og opfyldelsestransaktion. Læs den medfølgende README.
Match betalingstransaktionen og modtage adresse med din MochiPay ordre. Gennemgå den modtagende tegnebog eller blokkæden undersøge. Midler er allerede i din modtagelse tegnebog; der er ingen platform tilbagetrækning anmodning.
Brug en kompatibel tegnebog og vente på blokkæden bekræftelser, når du flytter midler. Læs regler- tegnebog management guide →
Inddrivelse og nøjagtige beløb
Fortsæt forsøget før oprette ordre. Den nuværende PHP-demo gemmer request_id og den nøjagtige nyttelast før Opret ordre. Efter en timeout uden et gemt system-id, prøv igen den samme nyttelast og request_id; en kendt order_id forespørges i stedet. Købmandsordrereferencer kan gentages; bruge systemets ordre-id eller det gemte anmodnings-id til at identificere en betaling. Bevar decimalsvarværdier som strenge før PHP eller JavaScript float-konvertering; vise pay_amount nøjagtigt. Den medfølgende QR koder kun adressen, så kunder skal indtaste det viste beløb.
Når du bygger din egen API-klient
Anvendelse X-Mochi-Key og X-Mochi-Signature. Opret Order tegn på den nøjagtige JSON krop ved hjælp af Base64- kodet HMAC- SHA256. Forespørgsel Order signerer den nøjagtige forespørgsel streng uden det ledende spørgsmålstegn. Hold underskriften hemmelig serverside.
Hvis prøvningen ikke er afsluttet
Betalingsmuligheden eller ordren kan ikke oprettes
Kontroller abonnementsstatus, en aktiv modtager tegnebog, betalingsmetode kode, legitimation og ombytningsrate par for ordren valuta. For plugins, også kontrollere metoden er aktiveret for den butik scope / kunde, der anvendes i testen.
Betalingen er stadig venter eller underbetalt
Sammenlign aktivet, netværket, adressen og det nøjagtige skyldige beløb med transaktionen. Vent på nødvendige bekræftelser. Markér ikke en butiksordre, der er betalt kun baseret på et skærmbillede eller browserafkast.
MochiPay er betalt, men min butik / ansøgning er ikke opdateret
Kontrollér, at anmeldelses- / callback-endepunkter er offentligt tilgængelige over HTTPS og ikke blokeret af godkendelse eller en firewall. Bekræft integrationen kan spørge MochiPay og inspicere dens fejl logs. Betaling links alene opdatere MochiPay, ikke en ekstern butik.
Fakultativ anmodning om slettelse
Eksisterende integrationer fortsætter med at fungere uden request_id. For at genbruge den samme betalingsordre efter en timeout, skal du tilføje en valgfri request_id til den signerede JSON krop, før du beregner den eksisterende HMAC-signatur.
{"merchant_order_id":"STORE-1001","amount":25,"currency":"USD","payment_method":"USDT_TRC20","request_id":"STORE-1001:create:v1"}
Brug 1–64 ASCII-bogstaver, cifre, prikker, understregninger, koloner eller bindestreger. En nøgle tilhører én forhandler og én forespørgselsnyttelast. Genbrug den samme nøgle og nyttelast til genforsøg; svar beholder de eksisterende felter og returnerer den oprindelige ordre i dens nuværende tilstand. Nøgler opbevares uden automatisk udløb. For hver ny kasse, brug en ny request_id. merchant_order_id kan forblive den samme: 123, 124, 124 opretter tre uafhængige systemordrer. En tidligere ubetalt ordre blokerer ikke for oprettelse. Kun et forsøg igen af den samme anmodning genbruger dens request_id og uændrede nyttelast. WEB82.6 annoncerer request-id-v1; forespørg på den gemte request_id for at løse et usikkert svar. Gentagne sælgerreferencer er ikke en gendannelsesnøgle. Implementer WEB82.6 eller nyere før integrationspakkerne; WEB82.7 tilføjer HPP cancel/return.
HTTP 409 REQUEST_IN_PROGRESS: Prøv den samme anmodning igen efter forsinkelsen igen. HTTP 409 REQUEST_ID_CONFLICT: nøglen blev genbrugt med en anden nyttelast. Generer ikke en ny nøgle bare for at omgå en timeout. ON_SITE og HPP kan begge bruge de returnerede betalingsfelter eller payment_url som før.