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:

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)