Acceptați fonduri de plată - documentație

Starea procesului de comandă. Poate conține următoarele valori:
creat - comanda a fost creată, dar clientul nu a introdus încă detalii de plată; Trebuie să continuați să consultați starea comenzii






procesarea - comanda este încă în curs de procesare de către gateway-ul de plată; Trebuie să continuați să consultați starea comenzii
a respins - comanda a fost respinsă de gateway-ul de plată FONDY, de un sistem de plată extern sau de o bancă achizitoare
aprobat - comanda este finalizată cu succes, fondurile sunt blocate în contul plătitorului și vor fi în curând creditate comerciantului; comerciantul poate furniza un serviciu sau "navă" bunuri
expirat - durata de viață a ordinului specificată în parametrul de viață. expirat.
inversat - tranzacția de succes anterior a fost anulată total sau parțial. În acest caz, parametrul reversal_amount are o valoare nonzero

Starea procesării cererii. Dacă a apărut o eroare în timpul validării parametrilor transmiși, atunci eșecul este returnat. altfel succes

Formarea semnăturii cererii și a răspunsului (semnătură de parametru)

Semnătura este formată prin aplicarea funcției SHA1 la un șir de caractere constând dintr-o parolă comerciant și toate setările, prikonkatenirovannyh la el și separate printr-o bară verticală, în ordine alfabetică |

Cerere de la comerciant:

șir utilizat pentru a genera semnătura:

Dacă parametrul este gol și nu conține date, atunci nu este necesar să atașați o linie verticală.

Exemplu de semnătură de verificare a codului pe paginile specificate în parametrii answer_url sau server_callback_url utilizând SDK-ul PHP:

Un fișier helper cu exemple de funcții pentru lucrul cu Signature.php

Semnătură de verificare folosind clasa Semnătura

Rezolvarea problemelor legate de generarea și validarea semnăturii

Există două situații tipice când apare o eroare de verificare a semnăturii parametrilor.

  1. Dacă cererea de cumpărare / recurență / inversare / stare sau orice altă solicitare cu parametrul de semnătură este trimisă la API-ul Fondy și răspunsul este returnat: Semnătura nevalidă.
  2. Dacă răspunsul de la serverul Fondy la server_callback_url sau response_url este returnat, răspunsul POST, dar când încercați să generați o semnătură și să îl comparați cu parametrul de semnătură din răspunsul POST, semnăturile nu se potrivesc

Să luăm în considerare ambele cazuri:

  1. Dacă cererea este trimisă la API-ul Fondy și răspunsul este returnat ca "Semnătura semnăturii nevalide:" 6bd069be8a6e2f2bbe176df00ba63cc681ca38aa`; response_signature_string: `********** | 125 | USD | 1396424 | Demo ordine 789 | Demo123456`“, verificați următoarele:
  • verificați dacă ați utilizat parola corectă din Setările tehnice ale comerciantului în Portalul comerciantului:
Acceptați fonduri de plată - documentație

  • dacă cererea conține caractere chirilice sau alte litere care nu sunt latine, atunci este trimisă în codare UTF-8
  • asigurați-vă că parametrul cu valoarea 0 nu este setat de limba dvs. de programare la o valoare goală
  • Înregistrați codul în codul în care aplicați SHA1 în timpul formării parametrului de semnătură. Comparați-l cu un șir de caractere, care este returnat în textul erorii (roșu): „semnătură semnătură invalidă:` 6bd069be8a6e2f2bbe176df00ba63cc681ca38aa`; response_signature_string: `********** | 125 | USD | 1396424 | Demo ordine 789 | Demo123456`“. Rețineți că în textul erorii parola de parolă a comerciantului va fi mascată cu *
  • Verificați dacă treceți parametrii goi în solicitarea API. Dacă da, în linia însăși, care participă la semnătura, caracterul separator | Pentru fiecare parametru gol nu este necesar să se includă
  • Dacă vă dezvoltați în limbajul de programare PHP, utilizați funcția example getSignature:
  • asigurați-vă că rezultatul SHA1 este redus la litere mici. Așa e. 6bd069be8a6e2f2bbe176df00ba63cc681ca38aa. Nu este corect. 6BD069BE8A6E2F2BBE176DF00BA63CC681CA38AA
  • asigurați-vă că parametrul de semnătură nu este inclus în calculul semnăturii
  • asigurați-vă că dacă utilizați punctul API / api / recurent. atunci numai parametrii necesari sunt incluși în semnătură
  • Dacă Fondy de la server la pagina specificată în parametrii server_callback_url sau response_url returnat POST răspuns, dar atunci când încercați să creați o semnătură și se compară cu parametrul semnătură în semnăturile de răspuns POST nu se potrivesc






  • Exemplu de răspuns de la Fondy (JSON):

    Pentru a diagnostica cauza nepotrivirii semnăturii, urmați acești pași:

    • asigurați-vă că parametrul cu valoarea 0 nu este setat de limba dvs. de programare la o valoare goală
    • Asigurați-vă că parametrii response_signature_string semnătură și nu sunt incluse în calculul semnăturii (parametrul response_signature_string returnează numai în cazul în care comerciantul este în modul de testare și conține un indiciu, ca o semnătură în răspunsul a fost format)
    • dacă cererea conține caractere chirilice sau alte litere care nu sunt latine, atunci este trimisă în codificare UTF-8
    • Înregistrați codul în codul în care aplicați SHA1 în timpul formării parametrului de semnătură. Comparați-l cu șirul care a revenit în answer_signature_string
    • Verificați dacă parametrii goi s-au întors ca răspuns. Dacă da, în linia însăși, care participă la semnătura, caracterul separator | Pentru fiecare astfel de parametru gol nu este necesar să se includă
    • Dacă vă dezvoltați în limbajul de programare PHP, utilizați funcția getSignature:
    • asigurați-vă că rezultatul SHA1 este redus la litere mici. Așa e. 6bd069be8a6e2f2bbe176df00ba63cc681ca38aa. Nu este corect. 6BD069BE8A6E2F2BBE176DF00BA63CC681CA38AA

    Formarea solicitărilor

    Puteți trimite solicitări către serverul FONDY în 2 moduri

    API-ul B acceptă următoarele formate de interogare text: HTML FORM, XML, JSON. Această opțiune este utilă pentru:

    În contextul unei interogări, răspunsul este întotdeauna returnat în același format ca și interogarea. Ie dacă cererea a fost în format JSON, atunci răspunsul va reveni în format JSON. Răspunsul la o astfel de solicitare este intermediar și conține adresa URL la care clientul trebuie redirecționat pentru a introduce detaliile de plată.

    Trimiterea unei cereri utilizând schema de interacțiune A nu implică un răspuns intermediar în contextul solicitării. Răspunsul final va fi returnat la adresa URL a comerciantului specificată în parametrii answer_url și server_callback_url.

    Exemplu pentru schema de interacțiune A

    Exemplu de gazdă-gazdă pentru schema de interacțiune B (JSON)

    Răspuns normal intermediar

    Răspundeți în caz de eroare

    Exemplu de host-to-host pentru B (XML)







    Trimiteți-le prietenilor: