Tests

L'environnement beta de Twikey permet de simuler de vrais flux de paiement et de signature sans toucher a de l'argent ou des donnees reels. Ce guide couvre tout ce qu'il faut savoir pour tester une integration de bout en bout avant la mise en production.

Résultats des transactions

Toutes les 30 minutes, une tache s'execute pour simuler le retour bancaire sur les transactions en attente. Le resultat est determine par le montant de la transaction, ce qui facilite le declenchement d'etats specifiques dans la configuration de relance.

Pour imiter le comportement bancaire reel, le premier retour est toujours PAID. Le resultat reel est retourne lors de la deuxieme execution de la tache.

Ces montants permettent de verifier les flux de paiement echoues et les etapes de relance.

Relances

Les periodes de grace definies dans les etapes de relance sont compressees dans l'environnement beta : chaque jour devient une minute. Cela permet de verifier la sequence complete de relance sans attendre des jours entre les etapes. Plus la periode de grace configuree est courte, plus l'etape de relance suivante est declenchee rapidement.

Virements

Il est possible de simuler un virement pour tester la correspondance automatique et manuelle des paiements. L'IBAN dans l'en-tete doit etre remplace par un compte reel provenant d'une des passerelles bancaires, puis un fichier CSV doit etre cree avec le format suivant :

twikey:BE123456789123 name;iban;bic;msg;amount John Doe;BE31798258915655;GKCCBEBB;My product;100

Note : les montants sont en centimes.

Le fichier doit etre charge via Reconciliation - Upload account info. Le nom du fichier doit etre unique pour chaque chargement.

Pour la correspondance automatique des factures, le champ msg doit correspondre a la reference de paiement d'une facture existante, et le amount doit correspondre exactement. Lorsque les deux conditions sont remplies, la facture est marquee comme payee, refletant les regles reelles de rapprochement.

Acceptation des mandats B2B

Une tache s'execute toutes les 30 minutes pour simuler l'acceptation ou le rejet des mandats B2B par la banque. Le resultat depend du dernier chiffre de l'IBAN :

• Dernier chiffre pair : mandat accepte
• Dernier chiffre impair : mandat rejete

Cela ne s'applique pas aux comptes Belfius (BIC : GKCCBEBB) et BNP (BIC : GEBABEBB), qui suivent un flux different.

Pour les tests automatises, ces IBAN donnent des resultats previsibles :

Banques connectees uniquement. Pour la signature B2B neerlandaise, les resultats peuvent etre simules via iDEAL/eMachtiging (voir ci-dessous). Pour les banques non connectees, seuls les flux d'impression et de marquage comme signe sont disponibles.

Validation B2B pour les banques non connectees

Tout compte B2B non connecte peut etre utilise - le comportement est toujours determine par le dernier chiffre de l'IBAN.

Simulation du retour

La tache doit s'executer deux fois pour produire un resultat final, imitant le comportement bancaire reel. Pour les validations reussies, une tache de suivi est programmee pour s'executer apres 4 heures afin de marquer le mandat comme accepte. L'utilisation d'un IBAN se terminant par 00 ignore le delai et signe le mandat immediatement apres la deuxieme execution de la tache.

Note : En raison de la tache de validation programmee, un webhook supplementaire peut etre recu pour le meme mandat. Ce comportement est attendu en beta et ne se produit pas en production.

Méthodes de signature

iDEAL, eMachtiging et iDIN

Il est necessaire de contacter l'agent de succes client pour lier le template a une banque de test. L'identifiant du template et la methode de signature a tester doivent etre fournis.

Lors de l'utilisation d'iDIN pour la signature ou l'identification, les donnees du client sont automatiquement ecrasees pour simuler les donnees retournees par iDIN telles qu'elles le seraient en production. Ce comportement peut etre desactive ou personnalise par l'agent de succes client.

Un delai peut egalement etre configure pour ces methodes. Le delai est applique cote backend - cote frontend, le client passe immediatement a la page de verification, et le resultat de la transaction est confirme lors de la prochaine execution periodique.

Autres methodes de signature

eID : il suffit d'utiliser une carte eID personnelle.

Cartes bancaires (Maestro) : n'importe quel numero de carte valide peut etre utilise, par exemple 4111111111111111. Le resultat depend du mois d'expiration :

SMS : lors de l'invitation d'un client a signer par SMS, un email fictif est envoye a l'adresse configuree sous Settings - Company information. Il suffit d'ouvrir le lien dans cet email, puis :

• Entrer OK pour un resultat reussi
• Entrer toute autre valeur pour simuler un echec

Liens de paiement et codes QR

Lors de l'utilisation de l'en-tete X-Purpose dans l'environnement beta, les codes QR generes a partir des liens de paiement ne peuvent pas etre scannes par les applications bancaires. Seuls les liens de l'environnement de production produisent des codes QR valides pour les applications bancaires.

L'URL du lien de paiement elle-meme fonctionne normalement en beta - seul le rendu du code QR est affecte.

iDEAL 2.0

Pour tester les paiements ponctuels iDEAL 2.0, il faut ajouter un fournisseur de test via Payment Hub - Add - Payment Provider - iDEAL 2.0 :

• Merchant ID : n'importe quel nombre
• SubId : laisser vide
• Selectionner Test bank
• Optionnellement le lier directement a un profil, ou le configurer sur un profil par la suite

Le mock iDEAL peut etre utilise pour le paiement direct de factures et de liens de paiement. Pour l'utiliser comme methode de signature avec premier paiement, il est necessaire de contacter le support pour l'activer comme methode de signature.

Dans le flux de paiement mock iDEAL, differents resultats peuvent etre selectionnes directement.

Webhooks

La livraison des webhooks peut etre testee pour verifier que l'endpoint gere correctement les evenements et que la validation de la signature fonctionne. Lors de l'activation des webhooks via les parametres API, aucun parametre de requete n'est necessaire dans l'URL - Twikey ajoute les parametres appropries lors de l'envoi de chaque requete, et ils varient selon le type d'evenement.

Consulter la reference des webhooks pour une liste complete des types d'evenements et de leurs charges utiles.

Agence de recouvrement

Apres qu'une transaction est envoyee a l'agence de recouvrement, un retour est simule toutes les 15 minutes jusqu'a la cloture du dossier. Les montants suivants permettent de declencher des resultats specifiques :

Lettres

Aucune lettre reelle n'est envoyee dans l'environnement beta. A la place, une copie de la lettre est envoyee par email a l'utilisateur qui a declenche l'action, permettant de verifier le contenu avant la mise en production.

Les lettres WIK doivent etre liberees par l'agent de succes client. Une fois liberees, un fichier zip contenant les PDF est recu a l'adresse email configuree sous Settings - Company information.