Chargement de vos clés API…

Enrôler des sous-marchands

Inviter un partenaire, suivre son dossier, et recetter le tout sans conséquence.

Ce que votre intégration doit traiter

Vous émettez une invitation, votre partenaire constitue son dossier, Mobupay l'instruit avec son partenaire bancaire, et un compte de paiement s'ouvre. Entre les deux bouts, l'enrôlement traverse une suite d'états, et votre application a besoin de les afficher, de relancer qui doit agir, et de réagir à l'ouverture du compte.

Ces états sont au nombre de onze, ils sont contractuels, et ils vous sont rendus dans le champ enrollmentStatus. Le champ actionRequired répond à la question suivante : qui doit agir. C'est celui sur lequel brancher vos relances.

Le tableau des onze états, leur signification et leur ordre sont documentés sur la référence de l'événement merchant.onboarding.updated. Ils ne changent pas de sens : la liste ne peut que s'allonger, et une valeur inconnue de votre code se traite comme IN_REVIEW.

Recetter sans conséquence

Avec une clé sk_test_, une invitation est simulée : elle vit dans votre environnement de test, aucun courriel ne part, aucun dossier de conformité ne naît, et rien n'est transmis à notre partenaire bancaire. En échange, vous pilotez vous-même son avancement, état par état, et chaque transition émet les vraies notifications vers vos serveurs de test.

Le corps de ces notifications est identique à celui de la production, à l'octet près. C'est délibéré : une intégration validée ici est celle qui tournera en réel. Il n'y a donc aucun indicateur de simulation dans la charge utile, et il ne faut pas en chercher un.

Un sous-marchand simulé ne peut pas recevoir de fonds : il n'a pas de compte chez notre teneur de compte. Un paiement qui le désigne dans order.platformConfig est refusé en 422 SIMULATED_SUB_MERCHANT, avant tout mouvement. Pour recetter une ventilation, employez un sous-marchand réel.

Simuler un enrôlement

Aucun courriel ne partira et aucun dossier réel ne naîtra.

L'invitation créée ici vit dans votre environnement de test. Elle produit de véritables notifications vers vos serveurs de test, et rien d'autre.

Clé employée

Le secret d'une clé n'est lisible qu'au moment de sa création : il est haché en base et ne se relit pas. Vous n'en avez pas besoin ici, la clé sélectionnée ci-dessus suffit. Ce champ ne sert qu'à recetter l'authentification par clé, celle qu'emploiera votre intégration.

Adresse du contact factice

Nom de l'enseigne

Référence externe

Les trois appels de la simulation

La console ci-dessus ne fait rien que votre propre outillage ne puisse faire. Elle appelle trois points d'accès, et n'en connaît aucun état par elle-même : c'est le serveur qui dit, à chaque instant, quelles transitions sont possibles.

# Les transitions possibles depuis l'état courant, et la frise
GET  /api/v1/platform/onboarding-sessions/{id}/simulation

# Faire avancer l'enrôlement d'un état
POST /api/v1/platform/onboarding-sessions/{id}/simulation
     { "transition": "submit" }

# Effacer une invitation simulée, et le sous-marchand factice qu'elle a produit
DELETE /api/v1/platform/onboarding-sessions/{id}

Une transition impossible depuis l'état courant est refusée en 409 ILLEGAL_TRANSITION, et le refus vous rend la liste de celles qui sont acceptées. Rejouer une transition déjà atteinte rend 200 sans rien réémettre : reprendre après une coupure est sans danger.

Le lien reçu par votre partenaire, en test