PEYELI — GUIDE D’ÉVALUATION PARTENAIRE Version 1.3 · revue le 11 octobre 2026. Document d’évaluation uniquement ; aucun accord, accès, approbation fournisseur ou certification de lancement. Votre place dans le réseau. ============================================================ Trouvez la relation adaptée à votre organisation : collecte, règlement, transferts, programmes de cartes ou logiciels connectés. La relation détermine le périmètre. Peyeli est responsable de l’expérience logicielle et de ses documents opérationnels. Les responsabilités du fournisseur financier dépendent du contrat approuvé : collecte, garde, règlement, transfert ou émission. Une connexion technique ne transfère pas automatiquement ces responsabilités. Modèle | Ce que nous évaluons | Ce qui nécessite un accord Collecte / prestataire financier | Demandes marchandes, résultats authentifiés, consultation et règlement. | Délégation marchande, actifs, frais, remboursements et autorité de règlement. Banque / règlement | Relevés, rapprochement des dépôts, exceptions et justificatifs. | Propriété des comptes, droits sur les données, formats et résolution. Transfert international | Parcours client hébergé, transmission d’identité et autorité du statut. | Corridors, plateformes, informations clients, conformité et modes de paiement. Émetteur / sponsor de cartes | Programme, financement, autorisation, compensation et remboursements. | Régions éligibles, exigences client, financement et contrôles du programme. Comptabilité / logiciel | Échange autorisé de documents, correspondances et reprise. | Objets, permissions de lecture/écriture, conservation et déconnexion. Transformer l’opportunité en relation de travail. Une évaluation nécessite une spécification technique autorisée et un accès de test. Il faut également établir qui peut agir pour chaque marchand, quels clients et pays sont éligibles, ce qui prouve un résultat et qui traite les litiges ou écarts de règlement. - Identifier l’entité contractante, le programme et l’environnement. - Confirmer consultation, doublons, annulations et justificatifs de règlement. - Définir contacts incidents, limites de test et critères de validation. Rendre le prochain échange concret. ============================================================ Transformez l’intérêt en séance de travail : définissez l’opportunité, choisissez un périmètre et convenez des résultats attendus du test. Commencer par un cas d’usage défini. Décrire l’opération à activer, son initiateur, son bénéficiaire et l’établissement faisant autorité. Identifier pays, résidence des clients, devises, modèle marchand et volumes attendus sans transmettre de données clients. - Identifier votre organisation, produit et rôle proposé. - Préciser l’opération et le périmètre client/marchand. - Fournir la documentation technique autorisée et les prérequis de test. Démontrer réussite et reprise. Définir une matrice écrite avant activation. Utiliser des identités synthétiques et des opérations de test autorisées et limitées. Séparer les observations fournisseur des tests sur données synthétiques. Un écran de retour ou une réponse HTTP réussie ne prouve pas la finalisation financière. - Réussite, refus, attente et délai dépassé après soumission. - Requête/événement en double, signature invalide et montant/compte incorrect. - Confirmation tardive, consultation indisponible, annulation et écart de règlement. - Refus entre tenants, expiration, révocation et capacité désactivée. - Compatibilité client/API/schéma déployés et reprise opérationnelle convenue. Conclure par une décision limitée. Le résultat doit préciser ce qui est validé, ce qui reste ouvert, l’environnement et les opérations permises, l’approbateur de l’étape suivante et les règles d’expiration ou de révocation. Une évaluation réussie n’autorise pas automatiquement la production. Utilisez le guide téléchargeable pour préparer la revue. Il s’agit d’une checklist, pas d’un accord ni d’une autorisation d’accès. Commencer public. Autoriser avec précision. ============================================================ Une politique d’évaluation progressive qui sépare accès documentaire, applicatif et financier. Quatre niveaux d’accès Il s’agit de niveaux de politique, pas de périmètres OAuth implémentés ni d’un service automatique. L’accès technique doit être examiné pour le déploiement choisi. Niveau | Évaluation permise | Limite Lecteur public | Documentation sélectionnée et exemples synthétiques. | Aucun accès aux comptes ou documents. Démonstration guidée | Utilisateurs nommés, tenant synthétique isolé ; lecture d’abord. | Actions simulées explicites ; aucun compte privilégié partagé. Test fournisseur approuvé | Organisation, opérations, actifs et volume définis. | Accès de test limité et révocable ; aucun fonds de production. Pilote / réel | Programme approuvé et lancement revu séparément. | Accord, validation et responsabilités opérationnelles requis. Définir l’autorisation avant de donner accès. Enregistrer utilisateurs et organisation, objectif, environnement, opérations permises, actifs/devises, limites marchand/fournisseur, durée, quotas, responsable, approbateur et révocation. Vérifier les refus aussi soigneusement que les permissions. - Aucun accès par défaut au code, à l’infrastructure ou à la production. - Aucun document d’un autre marchand, KYC client ou donnée brute de paiement. - La collecte n’implique aucune autorité d’émission, retrait, change, remboursement ou carte. - Faire expirer et révoquer l’accès par une procédure vérifiée. Étape suivante : utiliser la page contact de Peyeli pour une évaluation limitée. Ne pas envoyer d’identifiants ni de documents clients.