Les questions que posent les partenaires avant de signer.

omwio est un logiciel multi-tenant pour exploiter une plateforme de paiement sous votre propre marque. Chaque partenaire dispose d'un tenant isolé sur son propre domaine, avec un panneau gestionnaire, un panneau marchand, un paiement hébergé, une Processing API et une documentation marchand. Marchands, fournisseurs, routage, paiements, versements, portefeuilles, factures et litiges s'y configurent au lieu d'être développés.

Vous apportez la marque, les marchands et les relations fournisseurs. Nous fournissons et exploitons la couche technologique en dessous.

Non. omwio est un logiciel. Nous ne sommes ni acquéreur, ni établissement de paiement, ni établissement de monnaie électronique, ni entreprise de services monétaires, et nous ne sommes jamais le prestataire de services de paiement en titre de vos marchands.

Les relations d'acquisition et avec les PSP sont contractées directement par vous, et la plateforme s'y connecte sous forme de modules fournisseurs.

Non. L'argent circule entre les payeurs, vos fournisseurs et vos marchands selon vos contrats avec ces fournisseurs. omwio enregistre et orchestre les transactions — soldes, portefeuilles, réserves, versements — mais les fonds ne transitent jamais par un compte omwio.

Aux entreprises qui bâtissent leur propre activité de paiement : sociétés de paiement qui abordent un nouveau marché, plateformes qui internalisent les paiements et opérateurs qui ont dépassé une passerelle jamais conçue pour être revendue.

S'il vous faut un seul compte marchand pour votre propre boutique, un PSP vous conviendra mieux qu'une plateforme en marque blanche — et nous vous le dirons dès le premier appel.

C'est possible, mais ce qui prend des années, ce sont les parties ingrates : des registres qui concordent avec les exports, le routage, les flux de litige, le rapprochement, les permissions et l'isolation des tenants. Sur omwio, tout cela existe déjà et fonctionne déjà de concert.

Il reste à votre équipe la configuration — domaines, fournisseurs, tarifs et marchands — et les parties de votre produit qui vous appartiennent vraiment.

Un orchestrateur se place surtout devant des PSP pour le paiement d'une seule entreprise. omwio est une plateforme que vous revendez : en plus du routage entre fournisseurs, elle vous donne des tenants, l'intégration des marchands avec tarifs et commissions, un panneau marchand, des portefeuilles et soldes, des factures, des versements et des litiges — tout ce dont un partenaire a besoin pour gérer ses propres marchands.

Il n'y a pas de grille tarifaire publique. Les frais sont fixés dans votre bon de commande et dépendent du plan de facturation — Core plus les modules optionnels que vous choisissez — et de votre déploiement.

Le plan de facturation, l'ensemble de modules et le calendrier de déploiement sont mis par écrit avant toute signature : les conditions commerciales sont connues d'emblée.

Core n'est pas une version d'essai. Un tenant avec le seul Core peut intégrer des marchands avec tarifs et commissions, encaisser, verser, rembourser, traiter impayés et litiges, facturer via une page hébergée, gérer des portefeuilles multidevises et des échanges, router entre fournisseurs et MID, et consulter l'analytique de conversion et des fournisseurs — avec RBAC, 2FA et journal d'audit des actions d'administration.

Les modules optionnels ajoutent boîtes de support, supervision, rapprochement, antifraude, versements en masse, exports avancés et personnalisation de la marque.

Non. Un module désactivé est retiré de la navigation du panneau et fermé au niveau des routes de l'API : il est réellement éteint, et pas seulement hors de vue.

Non. Lorsqu'un plan est attribué, son ensemble de modules est figé dans l'instantané de droits du tenant. Modifier ensuite le modèle de plan ne touche pas aux tenants en production ; un plan est réappliqué délibérément — à un tenant, ou en masse aux tenants qui y sont liés.

Oui. Après un appel de trente minutes, nous montons un tenant de démonstration sur un domaine de démo avec votre logo et votre palette, connecté à un fournisseur sandbox, et parcourons tout le chemin en direct : intégration d'un marchand, un paiement, un versement, une facture et un litige.

Vient ensuite un pilote avec un marchand, un fournisseur et du trafic réel, pour voir la plateforme dans vos propres conditions.

À la résiliation, les données de votre tenant restent disponibles à l'export pendant la durée prévue dans votre bon de commande, puis sont supprimées conformément au calendrier de conservation. Vos contrats fournisseurs vous appartiennent du début à la fin : ils ne dépendent pas de nous non plus.

Peut-être — cela dépend de votre activité et de votre juridiction, pas du logiciel. omwio n'étant pas un établissement de paiement, toute licence, tout enregistrement ou toute autorisation qu'exige votre activité de paiement vous revient, ou est détenu par les fournisseurs agréés avec lesquels vous travaillez.

Nous ne donnons pas de conseil juridique, mais nous verrons avec vous comment la plateforme s'inscrit dans le modèle que vous ou vos conseils envisagez.

Les données de carte sont saisies sur le paiement hébergé de votre hôte pay et transmises aux fournisseurs par des canaux de saisie sécurisés. Elles ne sont jamais stockées sur les domaines des panneaux, et les marchands ne manipulent jamais de numéros de carte en clair dans leur propre intégration.

Vos obligations PCI DSS exactes dépendent de vos fournisseurs et de votre mode d'exploitation : validez le périmètre avec votre évaluateur ; nous lui fournirons ce dont il a besoin côté plateforme.

Vous. L'intégration, la vérification et le suivi de vos marchands, ainsi que les obligations KYC ou KYB qui s'y rattachent, vous incombent en tant qu'opérateur du tenant, ainsi qu'à vos fournisseurs agréés. La plateforme vous donne les outils pour le faire : réglages par marchand, étapes de revue soumises à permission, filtrage antifraude et supervision.

Dans votre tenant, vous êtes responsable du traitement et nous agissons en tant que sous-traitant, selon nos conditions de traitement des données. Les fiches clients sont stockées chiffrées, avec recherche par index aveugle : rechercher par référence, e-mail ou téléphone ne nécessite jamais de texte en clair.

Les transferts hors de l'EEE reposent sur une décision d'adéquation ou sur des clauses contractuelles types. La liste à jour des sous-traitants ultérieurs est communiquée aux partenaires sur demande.

Oui. Avant de provisionner un tenant, nous vérifions l'entité juridique, ses propriétaires et dirigeants, les licences sur lesquelles elle s'appuie, et la confrontons aux listes de sanctions, de PPE et aux sources d'informations défavorables — de manière continue. La profondeur dépend du risque.

Oui. Le panneau gestionnaire, le panneau marchand, le paiement hébergé, la documentation marchand et les e-mails sortants tirent tous votre identité d'une seule configuration de tenant. Les marchands s'inscrivent chez vous, se connectent chez vous et reçoivent vos e-mails ; la plateforme en dessous n'apparaît jamais.

Oui. Vous faites pointer votre domaine vers la plateforme et cinq hôtes s'activent, à votre marque et isolés : manager, merchant, pay, api et docs — par exemple merchant.yourbrand.com et api.yourbrand.com. Les cookies sont limités à chaque hôte : une session sur le domaine d'un tenant n'est jamais valable sur un autre.

Le paiement hébergé porte votre logo, vos couleurs, vos textes et votre présentation des moyens de paiement, tandis que la logique de paiement derrière reste sur le chemin éprouvé de la plateforme. Une personnalisation plus poussée des panneaux, du paiement et des e-mails, c'est ce qu'apporte le module Custom branding.

Oui. Chaque marque ou partenaire est un tenant distinct sur son propre domaine, avec ses marchands, son identité et ses données, isolé des autres. En ajouter un relève de la configuration, pas d'un nouveau déploiement.

Les e-mails sortants — factures, notifications, alertes et réinitialisations de mot de passe — sont rédigés dans la langue du destinataire et non dans celle du panneau de l'expéditeur, et chaque tenant a sa propre langue par défaut.

Oui. Vous contractez directement avec les acquéreurs et les PSP ; la plateforme les rattache sous forme de modules fournisseurs, vous y enregistrez vos MID et vous décidez quelles méthodes chaque devise accepte. Nous n'émettons ni comptes marchands ni MID.

Dites-nous lequel. Un nouveau fournisseur est ajouté sous forme de module qui traduit ses réponses dans les quatre types d'instruction de la plateforme : les intégrations des marchands ne changent pas à son arrivée. La faisabilité et le délai dépendent de l'API du fournisseur, c'est pourquoi nous posons la question tôt.

Le routage décide entre les MID. Les méthodes sont activées par devise, les règles définies par méthode, et les surcharges par marchand s'ajoutent par-dessus sans dupliquer la définition système. Avant toute mise en production, vous pouvez prévisualiser la route vers laquelle se résoudrait un marchand et une méthode donnés.

Les reprises et la gestion des états fournisseur font partie de la plateforme, et l'analytique fournisseurs montre les taux de réussite et les motifs d'échec par fournisseur et par MID. Le module Monitoring ajoute des signaux de santé pour les fournisseurs, les MID et les routes, afin que les problèmes apparaissent avant que les marchands ne les signalent.

L'acquisition carte (saisie de carte hébergée ou directe), le P2P de carte à carte avec dépôt de justificatif, les virements bancaires sur les réseaux locaux, les portefeuilles crypto, les redirections hébergées et les méthodes locales propres à chaque région. Ce qui est disponible en pratique dépend des fournisseurs que vous connectez.

Quel que soit le fournisseur, l'étape suivante du payeur revient sous l'un des quatre types d'instruction : saisie de carte, coordonnées de carte pour le P2P, adresse de portefeuille crypto ou redirection.

Les marchands disposent de portefeuilles par devise avec historique des soldes et visibilité des réserves. Les paires de devises ont leurs propres sources de taux et verrouillages de taux, les marchands peuvent échanger entre portefeuilles avec une cotation en direct, et les règles d'arrondi sont appliquées côté serveur : écrans et exports concordent.

Oui. Les versements unitaires et par lots sont dans Core, avec une étape de libération. Le module Mass payouts ajoute l'import de lots avec étapes de contrôle et de validation, pour qu'un gros lot soit vérifié par les bonnes personnes avant que l'argent ne bouge.

Les remboursements, les impayés et un flux de litige structuré sont dans Core. Un gestionnaire peut permettre à un marchand d'ouvrir des litiges sur ses propres paiements et versements — depuis le panneau ou par l'API — avec un motif et jusqu'à cinq pièces justificatives. Le gestionnaire les tranche, et les soldes sont annulés puis recomptabilisés automatiquement.

Oui, avec le module Accounting & reconciliation : trésorerie, P&L quotidien, fonds fournisseurs et rapprochement des règlements avec écarts explicites, pour qu'une différence soit une ligne listée et non une surprise en fin de mois.

Oui, avec le module Antifraud : filtrage par règles et par vélocité dès la création de la transaction, avant que quoi que ce soit n'atteigne un fournisseur. Il s'active par plan de facturation.

Core comprend l'analytique de conversion et des fournisseurs — taux de réussite, motifs d'échec et volume dans le temps par marchand, fournisseur et MID — et les marchands ont leur propre tableau de bord. Les relevés téléchargeables suivent les mêmes arrondis que l'écran. Le module Advanced exports ajoute les exports planifiés et à grande échelle.

Via une seule Processing API sur votre hôte api, avec le paiement hébergé sur votre hôte pay pour le payeur. Les marchands gèrent leurs clés d'API et callbacks dans leur panneau et s'intègrent à partir de la documentation de votre propre hôte docs.

Comme les particularités des fournisseurs sont normalisées avant d'atteindre l'API, une intégration continue de fonctionner quand vous ajoutez un fournisseur, une méthode ou une devise.

Chaque appel de traitement est signé : une signature HMAC sur le corps, un horodatage et un nonce. Les requêtes rejouées sont refusées. Chaque échec — validation, authentification, signature, conflit — renvoie la même forme d'erreur : ok, error.code, error.message, error.details.

merchant_order_id est unique par tenant et par marchand. Renvoyer le même produit un conflit 409 contrôlé au lieu d'un second paiement : les reprises sur un réseau instable sont sans risque.

Oui. Les marchands configurent les callbacks dans la section développeurs de leur panneau. Les statuts suivent un vocabulaire unique et condensé : les marchands voient les mêmes états quel que soit le fournisseur qui a traité le paiement.

Oui, sur votre propre hôte docs : votre identité, une référence choisie de la Processing API et les détails de votre environnement. L'intégration ne renvoie jamais un marchand vers une marque tierce.

Côté plateforme, aucun code de traitement à écrire : revendiquer le domaine, connecter les fournisseurs, définir tarifs et routage, intégrer les marchands. En pratique, le rythme dépend de vos contrats fournisseurs et de l'intégration des marchands ; c'est pourquoi nous convenons du calendrier par écrit avec vous avant la signature.

Oui — la migration depuis une passerelle existante fait partie de ce que prend en charge notre équipe technique. Le chemin habituel : faire venir d'abord les fournisseurs, puis basculer les marchands par étapes, en commençant par un marchand pilote sur du trafic réel.

Les canaux de support, les horaires et les éventuels niveaux de service figurent dans votre bon de commande. Les questions techniques vont à tech@omwio.com, et les demandes reçoivent une réponse sous un jour ouvré.

Vous — ce sont vos marchands, sous votre marque. Le module Support inbox permet à votre équipe de traiter les tickets marchands dans le panneau, à côté des données de transaction, et Support inbox AI ajoute des suggestions de réponse et le tri.

Non. Chaque requête est rattachée à son tenant par le domaine avant toute autre exécution : l'isolation fait partie de l'architecture et n'est pas un filtre de requête que quelqu'un pourrait oublier. Au sein d'un tenant, le RBAC décide de ce que chaque rôle peut voir et faire, et l'activité d'administration est enregistrée.