Ne saisissez pas deux fois le même montant et ne marquez pas une commande comme payée sans confirmation. OmEs pay vérifie quelles interfaces locales ou API cloud sont prises en charge par votre caisse, votre terminal et votre partenaire de paiement, et organise le flux de paiement autour de statuts clairs et d'un accès sécurisé.
Le montant de la vente est automatiquement transmis depuis la caisse vers le terminal, lorsque l'interface le permet.
La caisse ou l'application reçoit un résultat et peut mettre à jour correctement la vente ou la commande.
Nous choisissons le protocole pris en charge qui correspond à votre réseau, à votre matériel et à votre architecture logicielle.
Les clés API et les identifiants sont limités, protégés et renouvelés périodiquement, dans la mesure des possibilités offertes par le fournisseur.
Dans le cadre d'un paiement couplé classique, la caisse génère un ordre de paiement indiquant le montant et la référence. Le terminal effectue le paiement et renvoie un résultat. La caisse traite ensuite le paiement comme « réussi », « refusé », « annulé » ou « inconnu », selon la logique d'intégration.
Cela semble simple, mais ce sont les exceptions qui déterminent la qualité. Que se passe-t-il en cas de time-out, d'interruption du réseau ou de redémarrage ? L'application peut-elle demander à nouveau le statut définitif ? Comment éviter qu'une même vente soit payée deux fois ? Ces scénarios font partie intégrante de la mise en service.
Une interface locale communique au sein du réseau ou directement avec le terminal. De nombreux systèmes de caisse utilisent des protocoles reconnus ou des connecteurs propres au fournisseur. Une API cloud permet à une application de lancer des transactions et de recevoir des informations d'état via l'environnement de paiement, ce qui peut également convenir au commerce électronique, aux applications ou aux plateformes centrales.
Le meilleur choix dépend du support officiel. Une connexion développée en interne autour d'une application grand public ou d'un système d'automatisation d'écran ne constitue pas une architecture de paiement fiable.
Une clé API permet d'identifier ou d'authentifier une application auprès d'un service. Vous aurez également besoin de points de terminaison, de droits d'accès, de références, de codes d'erreur, de webhooks, d'un environnement de test et d'une gestion du cycle de vie. Certains fournisseurs utilisent d'autres identifiants ou un flux OAuth à la place d'une clé statique unique.
Les clés ne doivent jamais être intégrées de manière fixe dans le code d'un site web accessible au public, dans des documents partagés ou dans des e-mails. Conservez-les dans un gestionnaire de secrets ou dans une configuration de serveur sécurisée, limitez les droits d'accès et renouvelez-les lorsqu'un collaborateur ou un fournisseur quitte l'entreprise.
Les clients peuvent payer via Bancontact, mais l'interfaçage technique s'effectue généralement par l'intermédiaire de votre fournisseur de terminaux, de votre acquéreur, de votre prestataire de services de paiement ou de votre passerelle de paiement. Une même intégration peut prendre en charge plusieurs modes de paiement activés. Les modes de paiement disponibles sont déterminés par votre contrat et par la configuration de votre terminal ou de votre site en ligne.
Ne présentez donc pas le site web comme si OmEs pay fournissait une “ clé API Bancontact ” générale. OmEs pay aide à configurer l'intégration des prestataires pris en charge et détermine les modes de paiement qui seront activés.
Renseignez-vous sur les modèles de terminaux pris en charge, les versions de caisse, les pays, les modes de paiement et les certifications. Tenez compte des versions du micrologiciel et des API. Une combinaison qui fonctionne aujourd’hui doit également disposer d’un plan de maintenance et de mise à jour.
OmEs pay recense les parties concernées et définit les responsabilités. Dans le cadre d'une solution sur mesure, le développeur de logiciels reste responsable de son code ; OmEs pay prend en charge la configuration des terminaux et des opérateurs proposée, ainsi que le test d'intégration convenu.
La caisse, le terminal, le fournisseur d'accès, le réseau et le développeur sont répertoriés avec leurs versions actuelles.
Nous utilisons uniquement des protocoles, connecteurs, plugins ou API pris en charge.
L'accès est restreint et les transactions de test restent distinctes de l'environnement de production.
Les étapes « réussite », « erreur », « time-out », « remboursement » et « rétablissement » sont passées en revue de manière pratique.
Confiez à OmEs pay l'évaluation de votre intégration existante ou prévue. Nous regroupons la compatibilité, le partenaire de paiement, la sécurité et le traitement des statuts au sein d'une approche technique concrète.
Une connexion entre la caisse et le terminal de paiement permet à la caisse d'envoyer un montant et une référence au terminal de paiement, puis de recevoir un statut de paiement. Ainsi, le vendeur n'a pas besoin de saisir à nouveau le montant et la vente peut être finalisée correctement.
Non. Le logiciel de caisse, le terminal, le prestataire de paiement, le protocole et les versions doivent être compatibles. N'utilisez que des combinaisons officiellement prises en charge. OmEs pay vérifie la documentation technique avant de s'engager à établir une connexion.
Une connexion locale communique au sein de l'entreprise ou directement avec l'appareil. Une API cloud passe par l'infrastructure du fournisseur et peut convenir à des applications centralisées ou en ligne. Les deux présentent des exigences spécifiques en matière de réseau, de sécurité et de maintenance.
Une clé API est un identifiant qui permet à une application d'accéder à une API. Elle peut être associée à des droits, à un environnement ou à un compte marchand. Une clé seule ne suffit pas ; il faut également disposer de points de terminaison corrects, d'un traitement des statuts, d'une sécurité adéquate et de tests.
Non. Bancontact est un moyen de paiement. Les identifiants techniques sont délivrés par le fournisseur, la passerelle ou la plateforme d'intégration concerné(e) et sont liés à un compte et à un environnement spécifiques. Les moyens de paiement disponibles dépendent de l'activation et du contrat.
Ni dans le code du navigateur, ni dans les paquets d'applications mobiles, ni dans les référentiels publics, ni dans les e-mails, ni dans les documents courants. Conservez les secrets côté serveur dans un gestionnaire de secrets ou une configuration sécurisée, limitez l'accès, consignez l'utilisation et renouvelez les clés en cas de risque ou de changement de personnel.
La caisse doit recevoir un statut valide de terminal ou de fournisseur, ou pouvoir le récupérer. Le simple fait qu'un client revienne vers un écran ou un ticket imprimé ne suffit pas lorsque l'état du réseau est incertain.
L'application ne doit pas effectuer un nouveau paiement « à l'aveugle ». Elle doit identifier la transaction d'origine à l'aide d'une référence unique et demander son statut définitif. La procédure exacte de récupération dépend de l'interface et doit être testée au préalable.
Certaines interfaces prennent en charge les remboursements totaux ou partiels, tandis que d'autres nécessitent l'utilisation du portail du prestataire ou la manipulation du terminal. Limitez les autorisations, utilisez les références de transaction d'origine et vérifiez comment la caisse et la comptabilité sont mises à jour.
Le développeur assure la maintenance du code de l'application. L'opérateur assure la maintenance de son API et OmEs pay prend en charge la configuration convenue des terminaux et de l'opérateur. Définissez contractuellement les responsabilités en matière de mises à jour de version, de surveillance, d'incidents et de tests.
