Intégrations

Nous travaillons avec SAP S/4HANA et SAP Business One, Oracle NetSuite, Oracle Fusion Cloud ERP, Microsoft Dynamics 365 Finance and Supply Chain Management, Dynamics 365 Business Central, Odoo, Sage Intacct et Sage X3, ainsi qu’avec des systèmes sur mesure et plus anciens. Pour chacun, nous utilisons les interfaces prises en charge par l’éditeur, afin que les mises à niveau ne cassent pas l’intégration. La mention d’un produit ne signifie pas un partenariat avec son éditeur.

En savoir plus : Intégration ERPLien vers cette question

Pas toujours. Quelques flux stables entre deux systèmes peuvent reposer sur des appels d’API directs. Dès que plusieurs systèmes échangent des données, ou que vous avez besoin de centraliser la correspondance des données, les files d’attente et la supervision, un middleware comme MuleSoft, Boomi ou Azure Logic Apps est généralement rentabilisé. Si vous en possédez déjà un, nous nous appuyons dessus. Nous vous présentons les arbitrages, coûts de licence compris, avant que vous ne décidiez.

En savoir plus : Intégration ERPLien vers cette question

Nous travaillons avec les messages ISO 20022 que les banques utilisent pour les paiements et le reporting des entreprises : pain.001 pour les paiements, pain.002 pour les statuts, et camt.052, camt.053 et camt.054 pour les relevés de compte. Nous traitons aussi les relevés SWIFT MT940 et MT942 que de nombreuses banques envoient encore. Pour le transport, nous utilisons SFTP host-to-host, EBICS lorsque les banques le proposent, et les API bancaires. Chaque banque a sa propre variante de chaque format : nous développons donc à partir du guide de mise en œuvre de la banque, et non de la seule norme.

En savoir plus : Intégration bancaireLien vers cette question

Nous connectons les banques à SAP S/4HANA, Oracle NetSuite, Oracle Fusion Cloud ERP, Microsoft Dynamics 365, Odoo et Sage, ainsi qu’aux systèmes de trésorerie et aux systèmes sur mesure. Certains ERP disposent de leurs propres modules de communication bancaire. Dans ce cas, nous les configurons et les étendons plutôt que de les contourner. La mention d’un produit sur cette page ne signifie pas un partenariat avec son éditeur.

En savoir plus : Intégration bancaireLien vers cette question

Oui, lorsque l’acquéreur ou le processeur le propose. ISO 8583 est un cadre plutôt qu’un format unique : chaque acquéreur publie sa propre spécification des champs, des types de messages et de la gestion réseau. Nous développons à partir de cette spécification, traitons les autorisations, les annulations et les messages de notification (advice), et testons chaque code réponse. Lorsqu’une passerelle propose une API moderne devant l’acquéreur, nous recommandons souvent cette solution.

En savoir plus : Intégration des paiements et des points de venteLien vers cette question

Nous intégrons les terminaux EMV à puce et sans contact via le protocole fourni par leur prestataire, généralement une API locale ou cloud entre la caisse et le terminal. Le terminal et son application de paiement sont certifiés par le prestataire : nous nous y intégrons donc sans les modifier. Nous confirmons avec vous et le prestataire, dès le départ, les modèles et protocoles exacts.

En savoir plus : Intégration des paiements et des points de venteLien vers cette question

Cela dépend du nombre de liaisons et de l’équipe qui les exploitera. Une plateforme d’intégration comme MuleSoft, Boomi ou Azure Logic Apps réunit des connecteurs prêts à l’emploi, la correspondance des données et la supervision en un seul endroit, moyennant un coût de licence. Des services sur mesure vous donnent une maîtrise complète, sans licence, mais davantage de code à maintenir. Nous comparons les deux options pour votre cas et nous appuyons sur une plateforme que vous possédez déjà.

En savoir plus : Intégration d’API et de services tiersLien vers cette question

Nous étudions les limites publiées par chaque partenaire et concevons en conséquence : regroupement des requêtes lorsque l’API le permet, mise en cache des données qui changent rarement, étalement des tâches planifiées et ralentissement lorsque le partenaire signale qu’une limite est proche. La supervision indique l’écart entre chaque flux et sa limite, afin que la croissance ne se traduise pas en échecs.

En savoir plus : Intégration d’API et de services tiersLien vers cette question

C’est généralement la banque qui décide. SFTP host-to-host est le canal le plus largement proposé pour les fichiers de paiement des entreprises. EBICS est répandu auprès des banques en Allemagne, en France et dans les pays voisins. Les API bancaires conviennent aux soldes en temps réel et aux virements instantanés lorsque la banque les propose. De nombreuses entreprises en utilisent plusieurs, et la couche d’intégration masque ces différences à l’ERP.

En savoir plus : ERP et banquesLien vers cette question

Lorsque la banque propose les deux, camt.053 transporte des informations de remise plus riches et structurées, ce qui fiabilise le rapprochement automatique. MT940 reste très utilisé et convient bien à de nombreux cas. Nous pouvons recevoir les deux, les convertir dans un même modèle interne, et faire passer chaque banque de MT940 à camt.053 au moment qui vous convient, à vous et à la banque.

En savoir plus : ERP et banquesLien vers cette question

Généralement sous forme d’événements en quasi temps réel, car les chiffres de stock et de ventes sont alors à jour en cours de journée. Certains ERP ou certaines licences rendent les comptabilisations fréquentes coûteuses : la couche peut donc aussi regrouper les événements en synthèses par magasin et par période. Nous choisissons avec vous en fonction des décisions qui exigent des données à jour et de ce que l’ERP traite bien.

En savoir plus : Points de vente et ERPLien vers cette question

L’architecture fonctionne avec tout système de caisse capable d’exporter ses transactions via une API, des événements ou des fichiers, et avec des ERP comme SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central et Odoo. Nous confirmons dès le départ les interfaces de votre système de caisse et de votre ERP. La mention d’un produit ne signifie pas un partenariat avec son éditeur.

En savoir plus : Points de vente et ERPLien vers cette question

L’acquéreur est la banque ou l’établissement agréé qui traite les paiements par carte pour votre compte et vous reverse les fonds. La passerelle est le service technique placé en amont, qui reçoit les demandes des terminaux et des pages de paiement, tokenise les cartes et les achemine. Certains prestataires assurent les deux rôles. L’architecture fonctionne dans les deux cas et maintient une séparation claire entre ces rôles.

En savoir plus : Paiements par carteLien vers cette question

Non. ISO 8583 définit une structure, et chaque acquéreur ou réseau publie sa propre spécification des champs, des types de messages et des codes. C’est pourquoi nous développons à partir de la spécification de l’acquéreur et exécutons ses tests de certification. Une API de passerelle placée devant l’acquéreur masque ces différences, ce qui est souvent plus simple pour les commerçants.

En savoir plus : Paiements par carteLien vers cette question

Un agrégateur vous donne accès à de nombreuses banques via une seule API et gère les particularités de chacune, moyennant un coût par appel ou par connexion. Les connexions directes offrent davantage de maîtrise et peuvent convenir pour un petit nombre de banques importantes. De nombreux produits démarrent avec un agrégateur et ajoutent ensuite des connexions directes. Nous comparons les options au regard des banques et des pays dont vous avez besoin.

En savoir plus : API d’open bankingLien vers cette question

La couverture dépend des règles de la région et des API des banques. L’Union européenne et le Royaume-Uni bénéficient d’une large couverture au titre de la DSP2 et du UK Open Banking Standard. Ailleurs, la couverture varie, et les agrégateurs comblent une partie des lacunes. Nous vérifions la couverture des banques utilisées par vos clients avant que vous ne vous engagiez sur une architecture.

En savoir plus : API d’open bankingLien vers cette question

Pas pour la plupart des activités de trésorerie d’entreprise. Les canaux host-to-host traitent les fichiers de paiement en masse et les relevés complets de vos propres comptes. L’open banking convient aux produits destinés aux clients, aux soldes en temps réel et aux paiements unitaires. De nombreuses entreprises utilisent les deux : le host-to-host pour leurs propres campagnes de paiements et l’open banking pour leurs clients.

En savoir plus : API d’open bankingLien vers cette question

Tout service doté d’une API ou d’une interface de fichiers documentée. Exemples courants : plateformes CRM, transporteurs et prestataires logistiques, places de marché, plateformes de facturation électronique et de fiscalité, paie, prestataires de KYC et d’identité, et partenaires commerciaux qui échangent des documents EDI sur AS2. Nous examinons l’API, les limites et l’environnement de test de chaque partenaire avant de nous engager sur un plan.

En savoir plus : ERP et services tiersLien vers cette question

Dès que plusieurs partenaires sont connectés à un même ERP, une plateforme telle que MuleSoft, Boomi ou Azure Logic Apps, ou un ensemble de services spécifiques construits sur une file de messages, regroupe la transformation des données, les nouvelles tentatives et la supervision en un seul endroit. Avec un ou deux partenaires, des connexions directes peuvent suffire. Nous présentons les compromis, y compris le coût des licences, adaptés à votre situation.

En savoir plus : ERP et services tiersLien vers cette question