La verifica viene effettuata per assicurarsi che la fattura e il successivo pagamento possano essere correttamente elaborati dal lato del Progetto.

Con l'integrazione semplificata, l'ID utente e l'ordine vengono verificati due volte: quando si passa a un modulo di pagamento e quando si sceglie un metodo di pagamento.

Il progetto necessita di:

• ID utente o URL di verifica dell'ordine(specificare nelle Impostazioni Tecniche dell'Account Personale);
• Un handler in grado di accettare e riconoscere i parametri di una richiesta dal Sistema e rispondere come il Sistema si aspetta.

Se la verifica dell'identificatore dopo l'emissione della fattura si è conclusa con un errore, la fattura non verrà emessa e l'utente verrà reindirizzato alla pagina di errore di pagamento specificata dal progetto tramite il parametro return_url_fail oppure nelle Impostazioni tecniche (se la pagina non è specificata, viene utilizzata una pagina simile lato Sistema). Alla pagina di errore di pagamento utilizzando il metodo GET il parametro viene inviato automaticamente err_msg con il significato "Questo personaggio non esiste.".

Richiedi parametri dal Sistema al Progetto

Il sistema invia una richiesta al Progetto per l'URL per la verifica dell'identificatore o dell'ordine utente specificato nelle Impostazioni tecniche nell'Account personale.

• metodo di trasferimento - INVIARE;
• codifica - UTF-8.

Parametro	Descrizione del parametro	Formato dei parametri	Parametro obbligatorio
ID utente	Identificatore dell'utente o dell'ordine (uguale al valore del parametro soprannome v)	stringa (256)	sì
userid_extra	Informazioni aggiuntive necessarie per effettuare un pagamento o raccogliere statistiche lato Progetto (pari al valore del parametro nick_extra )	stringa (500)	No
chiave	Firma di verifica della richiesta. È formato come hash secondo l'algoritmo md5 dalla concatenazione dei seguenti parametri: valore del parametro ID utente, chiave segreta del progetto	md5 (segreto del progetto 0userid0)	sì
Quantità		0	sì
idpagamento	Controllo della richiesta di assegno. Accetta solo zero (importo = 0)	0	sì
ID ordine	ID pagamento nel sistema contabile del Progetto (uguale al valore del parametro ID ordine v)	varcar (64)	No

Parametri di risposta del progetto

Il Progetto dovrebbe ricevere una risposta alla richiesta del Sistema.

Le regole seguenti vengono utilizzate per passare i parametri di query:

• formato - XML;
• codifica - UTF-8.

Parametro	Descrizione del parametro	Formato dei parametri	Parametro obbligatorio
codice	Richiedi il codice di risposta. SÌ- l'identificatore esiste. NO- l'identificatore non esiste	(che tiene conto del maiuscolo o minuscolo)	sì
commento	Decodifica del codice di risposta alla richiesta. Esempi di testo: convalida per il parametro id utente non riuscita; convalida per il parametro orderid non riuscita; convalida per il parametro chiave non riuscita	stringa (400)	No

Esempio di risposta a una richiesta di verifica di un ID utente o di un ordine

SÌ

Un esempio di un gestore di richieste di sistema minimo durante il controllo di un utente o di un identificatore di ordine

// Genera una funzione di risposta sendResponse ($ status, $ message = "") ($ response = ""." \ n "; $ risposta. =" "." \ n "; $ risposta. =" ". $ stato.""." \ n "; $ risposta. =" ". $ messaggio.""." \ n "; $ risposta. =""; die ($ response);) // Controlla se esiste un ID utente o un ordine function checkUser ($ userID) ($ sql =" SELECT login FROM users WHERE usr_id = ".intval ($ userID); $ query = mysql_query ( $ sql ); if (mysql_error ()) (return FALSE;) if (mysql_num_rows ($ query) == 0) (return FALSE;) return TRUE;) $ secretKey = "IT \" S_A_PROJECT_SECRET_WORD "; $ projectHash = md5 ($ _ POST ["importo"]. $ _ POST ["userid"]. $ _ POST ["paymentid"]. $ secretKey); if ($ projectHash! = $ _POST ["key"]) (sendResponse ("NO", "La firma di verifica della richiesta non è valida.");) if (floatval ($ _ POST ["amount"]) == 0 && intval ($ _POST ["paymentid"]) == 0) (// Richiesta di controllo dell'ID utente o ordine se (checkUser ($ _ POST ["userid"])) (sendResponse ("YES", "ID esiste");) else ( sendResponse ("NO", "ID non trovato");))

Informazione Generale

Descrizione dei parametri di ingresso

Dati in ingresso: Documento XML secondo lo schema WS_ULIPZAPRID_2_311_11_04_02 _01_01.XSD

1. Descrizione dei parametri di uscita

Produzione: Documento XML secondo lo schema WS_OTVVIPULXSD_2_311_14_04_02_01.XSD

o

Produzione: Documento XML secondo lo schema WS_ULIPOTVID_2_311_09_04_02_01.XSD

I parametri di tipo complesso sono descritti nell'Appendice "Descrizione delle strutture dati generali" (nei punti 10, 6, 9).

1. Codici di ritorno

№	Codice di ritorno	Descrizione del codice di ritorno	Condizioni di accadimento	Un commento
1	01	Le informazioni richieste non sono state trovate.	Si verifica a condizione che le informazioni sulla persona giuridica non si trovino nel registro delle persone giuridiche dello Stato unificato
2	51	Richiesta accettata per l'elaborazione	Si verifica quando una richiesta viene ricevuta con successo per l'elaborazione
3	52	La risposta non è pronta	Si verifica in caso di indisponibilità di risposta ad una richiesta accettata con successo per l'elaborazione	Utilizzato quando si effettua una richiesta asincrona
4	53	Le informazioni relative a una persona giuridica/imprenditore individuale non possono essere fornite a in formato elettronico	Si verifica quando è impossibile formare una risposta a una richiesta in forma elettronica
5	82	Errore di controllo logico del formato	Si verifica quando il documento (richiesta) non corrisponde allo schema xsd	Riserva, non utilizzabile
6	83	Nessuna richiesta con l'ID richiesta specificato e il tipo di informazioni richieste da questa autorità	Si verifica in una situazione in cui un identificatore di richiesta errato (sconosciuto) è indicato in una richiesta per ottenere un risultato per una dichiarazione di una dichiarazione di persona giuridica e (o) una richiesta con tale identificatore non è stata ricevuta da questa autorità	Utilizzato con una richiesta asincrona (quando si riceve il risultato di una richiesta di dichiarazione per una persona giuridica)
9	99	Errore di sistema	Si verifica quando ci sono errori interni nel software dell'IS FTS della Russia

1. Casi test

Richiesta per ottenere il risultato di una richiesta per ottenere una dichiarazione di persona giuridica

Risposta a una richiesta per ricevere il risultato di una richiesta di dichiarazione di persona giuridica, nel caso in cui la richiesta non sia stata ancora elaborata

Risposta a una richiesta per ricevere il risultato di una richiesta di una dichiarazione di persona giuridica con un codice di ritorno 53

Risposta ad una richiesta di ricevere l'esito di una richiesta di rendicontazione della persona giuridica con un errore (il cui codice di elaborazione non è riservato)
(i valori degli attributi cambiano e)

Nota: le condizioni per questo errore nell'ambiente di test sono state attivate artificialmente. Questo esempio descrive la logica generale e la struttura della risposta all'errore. Quando si esegue il test in un ambiente produttivo, non è possibile restituire esattamente la stessa risposta senza fornire le condizioni necessarie.

1. L'interfaccia deve accettare le richieste su HTTPS dagli indirizzi IP delle sottoreti:
   • 79.142.16.0, maschera 255.255.240.0 (20)
   • 91.232.230.0, maschera 255.255.254.0 (23)
2. L'interfaccia deve elaborare i parametri passati dal sistema utilizzando il metodo HTTP GET.
3. L'interfaccia deve formare una risposta al sistema in formato XML con codifica UTF-8.
4. Lo scambio di informazioni avviene in modalità "richiesta-risposta", mentre la velocità di risposta non deve superare i 60 secondi, altrimenti il ​​sistema interrompe la connessione per timeout.
5. Se si prevede che il numero previsto di pagamenti per i servizi del provider connesso sia intenso (fino a 10 pagamenti al minuto o più), è necessario che l'interfaccia supporti la comunicazione multi-thread fino a 10-15 connessioni simultanee.
6. L'interfaccia deve accettare richieste tramite HTTPS su una delle seguenti porte TCP: 80, 81, 443, 8008, 8080, 8081, 8090, 8443, 4433. Non è consentito l'utilizzo di altre porte.

Principi di base dell'interfaccia

Tutte le richieste vengono passate dal metodo GET, i parametri vengono passati nel percorso della richiesta.

Il trasferimento delle informazioni sul pagamento al provider viene effettuato dal sistema QIWI Wallet in due fasi: verifica dello stato dell'abbonato ed effettuazione diretta del pagamento. Può anche essere aggiunta una fase preliminare per ottenere parametri di pagamento aggiuntivi da un fornitore che fornisce all'abbonato diversi servizi per informare il pagatore e aggiungere parametri di pagamento a scelta del pagatore.

Il tipo di richiesta viene trasmesso dal sistema QIWI Wallet nella variabile di comando - una stringa che prende i valori check, pay o getInfo:

Parametri di query

Tutti i parametri sono obbligatori nelle query in cui vengono utilizzati.

Parametro	Formato	Descrizione	In quali query viene utilizzata
txn_id	Intero fino a 20 caratteri	Identificatore univoco del pagamento nel sistema QIWI. Questo identificatore viene utilizzato per risolvere questioni controverse.	controlla, paga
somma	Numero frazionario preciso al centesimo, usato come separatore. (punto). Se la somma rappresenta un numero intero, viene comunque completata con un punto e zeri, ad esempio - 152.00.	Ammontare del pagamento	controlla, paga
ccy	Codice valuta Alpha-3 ISO 4217	Valuta del pagamento	controlla, paga
txn_date	AAAAMMGGHMMSS	Data di pagamento (la data di pagamento nel sistema indica la data di ricezione della richiesta da parte del cliente). Entro tale data, viene effettuata un'ulteriore riconciliazione degli accordi tra QIWI Wallet e il provider. Ad esempio, un cliente ha inviato una richiesta al sistema QIWI Wallet il 31/12/2010 alle 23:59:59 e il sistema QIWI Wallet ha inviato la sua richiesta al provider il 01/01/2011 alle 00:00:05. Questo può portare a un problema di riconciliazione dei pagamenti se il sistema del provider inserisce la transazione nel periodo di fatturazione successivo. Per evitare tali problemi, QIWI Wallet fornisce al provider la data di pagamento originale.	pagare
account	Una stringa contenente lettere, numeri e caratteri speciali, lunga fino a 200 caratteri	ID abbonato. Il provider identifica il suo abbonato tramite un identificatore univoco (numero di conto personale, numero di telefono, login, ecc.). Prima di essere inviato al provider, l'identificatore viene convalidato rispetto all'espressione regolare che.	controlla, paga, ottieni informazioni
extra	Sono ammessi numeri (0-9), trattino basso (_) e lettere latine minuscole (a-z)	Ulteriori dettagli di pagamento (campi extra). Questi parametri possono essere utilizzati se il pagamento non può essere effettuato senza dati aggiuntivi (un ID utente nel sistema del provider non è sufficiente). Ad esempio, il tuo ID utente è il numero della tua carta di credito, ma devi anche specificare la data di scadenza della carta per effettuare un pagamento. L'elenco dei campi obbligatori per la trasmissione al provider deve essere specificato in.	controlla, paga
ID privato	Numero intero	ID servizio in sistema comune fornitore.	ottenere informazioni
nome_parametro	Il formato del nome e del valore dei parametri è specificato dal provider nel file.	Parametri aggiuntivi per l'identificazione dell'abbonato	ottenere informazioni

Per supportare l'estensibilità e mantenere la manutenibilità del fornitore di servizi durante il periodo in cui sono abilitate varie funzioni fornite dal protocollo (ad esempio, abilitando il trasferimento di nuovi dettagli di pagamento), si presume che il fornitore non impedisca la visualizzazione di nuovi parametri HTTP in la richiesta.

È garantito che la comparsa di nuovi parametri nella richiesta non comporti la necessità di modificare l'elaborazione delle richieste da parte del provider, a meno che tale cambiamento di logica non sia stato concordato con il provider.

Formato di risposta

Il provider deve restituire la risposta alle richieste al sistema in formato XML. La struttura generale della risposta è mostrata nella scheda a destra.

123323498 12369Bdkjh9 100.00 643 2012-04-05T12: 00: 07 0

Se una delle richieste al provider fallisce, il provider restituisce un codice di errore in conformità con.

Il sistema informativo del provider non deve contenere due pagamenti andati a buon fine con lo stesso numero txn_id. Se il sistema invia nuovamente una richiesta con l'identificatore txn_id già esistente nel sistema informativo del provider, il provider deve restituire il risultato dell'elaborazione della richiesta precedente.

Nella risposta possono essere presenti i seguenti tag:

Ad esempio, c'è una situazione: il cliente ha inviato una richiesta al sistema il 31/12/2010 alle 23:59:59. Tenuto conto del ritardo nell'elaborazione dei dati e nell'invio delle informazioni attraverso i canali di comunicazione, il pagamento sarà ricevuto dal fornitore il 01.01.2011 00:00:05 e, di conseguenza, sarà registrato nel sistema del fornitore in un altro periodo di rendicontazione. Per evitare problemi con periodi di rendicontazione diversi durante la riconciliazione, è necessario che il fornitore restituisca la data in cui viene effettuata la contabilità nel suo sistema.

Un esempio di richiesta per verificare lo stato dell'account di un abbonato e registrare un pagamento

Condizioni di esempio:

L'applicazione di pagamento del provider payment_app si trova su yourservice.prv.ru, il server supporta le connessioni HTTPS sulla porta 8443.

Per verificare lo stato dell'abbonato, il sistema QIWI Wallet genera una richiesta (vedi scheda a destra).

OTTENERE / payment_app? comando = assegno & txn_id = 1234567 & conto = 4957835959 & somma = 10,45 & ccy = RUB 1234567 2016AB 10.45 STROFINARE 0 ok

La richiesta contiene parametri:

• command = check - identificativo della richiesta per il controllo dello stato dell'abbonato;

Risposta positiva dal provider (vedi scheda a destra).

Restituire risultato = 0 alla richiesta di controllo indica che il conto personale dell'abbonato con il numero corrispondente nel campo conto può essere rifornito con l'importo specificato nella richiesta nel campo somma. Dopo aver verificato con esito positivo lo stato del conto dell'abbonato, il sistema procede alla formazione e all'invio di una richiesta di reintegro del saldo (richiesta di pagamento).

Esempio di richiesta di ricostituzione di un account personale

Condizioni di esempio:

Per confermare il pagamento, il sistema QIWI Wallet genera una richiesta (vedi scheda a destra).

OTTENERE / payment_app? comando = paga & txn_id = 1234567 & txn_date = 20110815120133 & conto = 4957835959 & somma = 10,45 & ccy = RUB Host HTTP/1.1: yourservice.prv.ru:8443 Risposta del provider 1234567 2016AB 10.45 STROFINARE 0 ok 2011-08-15T12: 06: 45

La richiesta contiene parametri:

• comando = paga - identificativo della richiesta per il rifornimento del saldo dell'abbonato;
• txn_id = 1234567 - numero di pagamento interno nel sistema QIWI;
• txn_date = 20090815120133 - data di registrazione del pagamento nel sistema QIWI;
• account = 4957835959 - identificativo dell'abbonato nel sistema informativo del provider;
• somma = 10,45 - importo da accreditare sul conto personale dell'iscritto;
• ccy = RUB - la valuta dell'importo accreditato sul conto personale dell'abbonato.

Restituendo risultato = 0 sulla richiesta di pagamento, il provider informa sul completamento con successo dell'operazione di rifornimento del saldo. Il sistema completa completamente l'elaborazione di questa transazione.

Il campo commento facoltativo contiene un commento sul servizio.

Esempio di richiesta per ricevere ulteriori dati di pagamento

Condizioni di esempio:

L'applicazione di pagamento del provider payment_app si trova su yourservice.prv.ru, il server supporta le connessioni HTTPS sulla porta 8443.

Per ottenere ulteriori dati di pagamento, il sistema QIWI Wallet genera una richiesta (vedi scheda a destra).

OTTENERE / payment_app? comando = getInfo & prvId = 12345 & account = 4957835959 & name1 =% 26% 30AB & name2 = 0 Host HTTP/1.1: yourservice.prv.ru:8443 Risposta del provider conto1 termine2 0 ok

La richiesta contiene parametri:

• command = getInfo - identificatore della richiesta di ricevere dati di pagamento aggiuntivi per l'abbonato;
• prvId = 12345 - identificatore per identificare il fornitore del servizio;
• account = 4957835959 - identificativo dell'abbonato nel sistema informativo del provider;
• nome1, nome2 - identificatori abbonati aggiuntivi.

Vedi la scheda a destra per la risposta del provider.

La restituzione di risultato = 0 alla richiesta getInfo indica che la richiesta è stata completata con successo e che sono stati ricevuti dati aggiuntivi da visualizzare per l'abbonato.

Il campo commento facoltativo contiene un commento sul servizio.

Riconciliazione quotidiana

Fino alle 10:00, ora di Mosca, il sistema genera e invia all'indirizzo specificato un registro elettronico dei pagamenti ricevuti il ​​giorno precedente.

Il registro ha la seguente struttura:

Data della transazione (Mosca); Data del rapporto; Tipo; Numero della transazione; ID valuta della transazione; Importo della transazione; Commento del commerciante; Numero della transazione/fattura del commerciante; Data di emissione della fattura; ID QW; Conto; ID rimborso

;;Pagamento; ;;;;;;;;

;;Pagamento; ;;;;;;;;

I campi sono separati da un segno; , la parte frazionaria della somma è separata da un punto, data / ora - Mosca, l'avanzamento riga può essere costituito da entrambi i caratteri x0D x0A e semplicemente da x0D.

Per esempio:

31.02.2005 00:04:00;31.02.2005

00: 00: 00; Pagamento; 3464968222; USD; 5.00 ;;;;; 0957835959 ;;

31/02/2005 00: 04: 00; 31/02/2005 00: 00: 00; Pagamento; 3464968912; RUB; 10.34 ;;;;; [e-mail protetta];;

31/02/2005 00: 11: 00; 31/02/2005 00: 00: 00; Pagamento; 3464974548; EUR; 4.72 ;;;;; ABC-12345 ;;

Il sistema include solo i pagamenti andati a buon fine nel registro.

I pagamenti confermati sono considerati pagamenti che sono pervenuti sia durante la messaggistica online che nel registro.

Se il registro non contiene pagamenti che sono stati effettuati nel database del provider, o contiene pagamenti che non sono nel database del provider, o se il registro non viene ricevuto, è necessario contattare il referente QIWI specificato nel contratto entro le 12:00 chiarire la situazione e prendere una decisione.

Opzioni aggiuntive per l'autorizzazione delle richieste

Nella domanda di connessione, il provider può impostare un identificatore (login) e una password segreta, che vengono utilizzati per l'autorizzazione quando si effettuano richieste da QIWI.

Questi dati di autorizzazione sono trasmessi da regole standard autenticazione di base per le richieste HTTP (S). L'intestazione HTTP di autorizzazione viene aggiunta alla richiesta. L'intestazione contiene la riga Basic (con uno spazio alla fine) e la coppia “login: password”, codificata in BASE64:

Autorizzazione: Base ***

BASE64 ("Accesso: Password") = "***"

Applicazione di connessione (campione)

Elenco dei codici di completamento

Durante l'elaborazione delle richieste dal sistema, il provider deve abbinare tutti gli errori che si verificano nella sua domanda con l'elenco sottostante e restituire i codici corrispondenti nell'elemento.

Il segno + nella colonna fatale indica un segno di errore fatale. Per il sistema QIWI Wallet, un errore fatale significa che il reinvio di una richiesta con gli stessi parametri comporterà una ripetizione del 100% dello stesso errore, pertanto il sistema interrompe l'elaborazione della richiesta del client e la termina con un errore.

Un errore non fatale significa per il sistema che la ripetizione di una richiesta con gli stessi parametri dopo un certo periodo di tempo porterà eventualmente al successo. Il sistema riproverà le richieste che falliscono con un errore non irreversibile, aumentando continuamente l'intervallo fino a quando l'operazione non riesce o fallisce, o fino alla scadenza della richiesta - 24 ore.

La mancata comunicazione con il server del provider è un errore non fatale.

Anche la mancanza di un elemento nella risposta (XML non valido, pagina del servizio temporaneamente non disponibile e così via) è un errore non irreversibile.

Codice