Version de travail · contenus et exemples à affiner Voir les 95 pages ↗
Parlons de votre projet ↗
Commencer / P002

Activer l'accès à l'API

Adaptation éditoriale
Référence de travail. Les routes, schémas, limites et procédures hérités du référentiel sont à aligner avec l’API d’Éric. Ils ne prouvent pas une fonctionnalité livrée. Les hôtes .invalid sont des exemples inertes.

Ouvrir les capacités nécessaires

L’activation associe un marchand identifié, des personnes habilitées et les services effectivement autorisés dans le dispositif partenaire. Elle doit être distincte d’une simple inscription au portail.

Les informations du dossier

Préciser l’activité, la forme d’organisation, l’identité des représentants, les bénéficiaires effectifs lorsque requis, les coordonnées et les justificatifs applicables. La liste des pièces et les contrôles dépendent du cadre retenu et doivent être confirmés.

Une décision traçable

Le portail doit permettre de comprendre les informations attendues, le dossier en examen, les compléments demandés et les capacités ouvertes. Chaque changement de statut doit être attribué et journalisé.

Plafonds et périmètre

Les plafonds, moyens d’encaissement, destinations de sortie et restrictions sont associés au marchand. Il ne faut pas reprendre automatiquement les niveaux ni les seuils d’un fournisseur comme règles Kelyko.

Activation API

La possibilité de générer une clé ne prouve pas l’accès aux opérations réelles. L’équipe technique doit exposer les autorisations et erreurs correspondantes dans son contrat API. L’accès d’essai reste séparé du réel.

Cas plateformes

Un marchand créé ou rattaché par une plateforme conserve son individualisation. La conformité, les droits de l’intermédiaire et les opérations autorisées doivent être établis dans le périmètre dédié.