Décrivez l'événement métier avant de choisir une API
Un paiement B2B peut impliquer des prix convenus, des bons de commande, des limites d'approbation et des conditions de paiement. Commencez par un seul flux de travail et nommez les systèmes concernés. Par exemple : un acheteur approuvé passe une commande, le système financier l'enregistre et l'entrepôt renvoie le statut d'exécution au portail client.
Cet article décrit un exemple de planification, et non un projet client achevé. La même préparation s'applique aux intégrations CRM, de paiement et de réservation : identifiez l'événement, les données faisant autorité et ce que signifie un transfert réussi.
Préparez un cahier des charges d'intégration
- Systèmes et accès : nommez la plateforme, le plan de compte, la version de l'API, la documentation et le bac à sable. Confirmez que les points de terminaison et les autorisations prévus sont disponibles.
- Propriété des données : décidez quel système détient l'identité client, le prix, le stock, le statut de commande et l'état de paiement. Fournissez des enregistrements représentatifs sans données personnelles.
- Correspondance : définissez les identifiants partagés, les champs obligatoires, la devise, la gestion des taxes et les fuseaux horaires. Notez ce qu'il faut faire d'un produit ou d'un client non associé.
- Exceptions : incluez l'annulation, l'exécution partielle, l'échec de paiement, un prix modifié et un système en aval indisponible.
- Opérations : décidez qui examine les échecs, peut rejouer un transfert et approuve une correction.
Partez du principe que les notifications peuvent se répéter ou arriver en retard
Le traitement des webhooks nécessite une politique claire de nouvelle tentative et de gestion des doublons. À titre d'exemple concret de plateforme, Stripe documente la vérification de signature, les événements en double et le traitement asynchrone dans son guide des webhooks. Une notification de paiement doit être authentifiée et traitée conformément au contrat du fournisseur. D'autres plateformes ont leurs propres règles de livraison et de nouvelle tentative ; vérifiez-les individuellement.
Exemple d'acceptation : soumettez une commande dans le bac à sable, livrez son événement deux fois, puis désactivez temporairement le système récepteur. Vérifiez que la commande est créée une seule fois, que le transfert échoué est visible et que la relecture peut le récupérer. Vérifiez également qu'un client ne peut pas consulter la tarification ou les commandes d'une autre entreprise.
Convenez de ce que comprend la première version
Un premier périmètre réaliste pourrait prendre en charge un type de commande, un entrepôt et un ensemble défini d'états. Séparez la migration des données historiques, l'intégration des fournisseurs et les règles de tarification inhabituelles si elles nécessitent une investigation supplémentaire. Convenez de ce qui est manuel au départ et de la manière dont l'équipe mesurera si l'intégration réduit la charge de travail.
Le transfert doit inclure les correspondances de champs, les instructions de configuration, la surveillance, une procédure de relecture et une propriété désignée des mises à niveau de la plateforme. Les conditions de maintenance dépendent des systèmes et de l'engagement convenu. Découvrez le développement et l'intégration d'API, l'automatisation des flux de travail et le développement e-commerce.
