Console Try-it

➤ Principe

En vous connectant sur le portail, vous pouvez

  • faire appel à l'API "disponibilité des fonds" via un formulaire dans lequel vous sélectionnez votre application et le jeton d'authentification/d'accès

  • puis vous saisissez les paramètres de la méthode POST /funds-confirmations que vous souhaitez tester (soit headers, soit body) dont ceux mentionnés par une étoile sont obligatoires

Une fois les paramètres saisis, vous pouvez lancer l'exécution de la requête : vous obtiendrez soit un résultat, soit une erreur.

Les données utilisées pour faire le test en Try-It sont issues des personnas (voir la rubrique "Comment tester l'API" > "Tester nos personas").

L'utilisateur peut choisir un profil spécifique de client pour son test de façon à mieux appréhender les résultat obtenus. 

 

Version 1.4.2

A compter du 8 juillet 2020, le try-it ne sera possible que pour la version V1.4.2.

Si vous avez déjà effectué une demande de GoLive, vous devez alors créer une nouvelle application, puis sélectionner la nouvelle API STET V1.4.2.

Si vous n’avez PAS effectué de demande de GoLive, vous pouvez :

  • soit modifier votre application existante pour l’associer à la nouvelle API STET V1.4.2.
  • soit créer une nouvelle application, puis sélectionner la nouvelle API STET V1.4.2.

 

➤ Aperçu de l'écran permettant de récupérer le jeton Oauth2

Try it2

Cet écran est accessible lorsque l'on édite l'application (dsp2 dans notre cas) et il permet de générer ou éditer un jeton Oauth2 que l'on sélectionnera dans le formulaire d'exécution Try-It.

 

➤ Aperçu du formulaire d'exécution du Try-It

Try it3

 

➤ Paramètres du Try-It pour la méthode "POST/funds-confirmations"

Nb : pour les paramètres de type de données "body", il est possible de copier-coller les exemples (partie gauche de l'écran) dans le formulaire (à droite de l'écran) en changeant juste les valeurs spécifiques au client choisi.

ParamètreDescriptionType de donnéesType de paramètreObligatoire
Authorization Jeton d'accès devant être fourni comme header Chaîne de caractères Header Oui
PSU-IP-Address

Adresse IP utilisés par le client connecté sur votre application

(*) Donnée obligatoire si le client est connecté ou non renseignée en cas d'accès batch
Chaîne de caractères Header Non*
PSU-IP-Port Port IP du terminal utilisé par le client connecté sur votre application Chaîne de caractères Header Non
PSU-HTTP-Method Méthode http utilisée pour la requête du client Chaîne de caractères Header Non
PSU-Date Timestamp utilisé par la requête du client Chaîne de caractères Header Non
PSU-GEO-Location Localisation géographique que le client vous a fournie via son terminal si elle est disponible Chaîne de caractères Header Non
PSU-User-Agent Header "User-Agent" envoyé par le terminal du client connecté à votre application Chaîne de caractères Header Non
PSU-Referer Header "Referer" envoyée par le terminal du client connecté à votre application. Il est à noter que dans des spécifications antérieures des RFC 1945, on préconise le nom "referer" (mal orthographié). Le nom "referrer" peut être utilisé au risque de ne pas être compris. Chaîne de caractères Header Non
PSU-Accept Header "Accept" envoyé par le terminal du client connecté à votre application Chaîne de caractères Header Non
PSU-Accept-Charset Header "Accept-Charset" envoyé par le terminal du client connecté à votre application. Chaîne de caractères Header Non
PSU-Accept-Encoding Header "Accept-Encoding" envoyé par le terminal du client connecté à votre application. Chaîne de caractères Header Non
PSU-Accept-Language Header "Accept-Language" envoyé par le terminal du client connecté à votre application. Chaîne de caractères Header Non
Digest Synthèse du body Chaîne de caractères Header Non
Signature

Signature http de la requête (voir https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) La partie keyId du header devrait avoir le format suivant keiId="SN=XXX,CA=YYYYYYYYYYYYYYYY" où "XXX" est le numéro de série en hexadécimal sans aucun préfixe (comme 0x, du certificat QSEAL dont la clé privée a servi pour la signature de celui-ci

"YYYYYYYYYYYYYYYY" est l'émetteur DN,  nom complet de l'autorité de certification ayant émis ce certificat HTTP400 et qui sera renvoyé par le serveur dans le cas d'une signature invalide ou absente.
Chaîne de caractères Header Oui
X-Request-ID Header de corrélation à paramétrer dans la requête et devant être récupéré dans la réponse de celle-ci Chaîne de caractères Header Oui