Une plateforme a besoin d'un socle
omwio a publié une mise à jour produit sur Core, la partie de la plateforme sur laquelle repose chaque compte, quel que soit son plan de facturation. L'entreprise décrit Core comme l'élément qui doit exister avant qu'un module optionnel ait un quelconque sens : une plateforme de paiement n'est utile que lorsque l'argent peut circuler, être attribué à un marchand, et être visible par tous ceux qui doivent agir sur lui. Core couvre le Tenant manager, le Merchant panel, le Hosted checkout et la Processing API.
Marchands, transactions et portefeuilles dans un seul modèle
Chaque tenant intègre ses propres marchands avec leurs tarifs, commissions, méthodes assignées et dérogations propres à chaque marchand, et la fiche marchand est le point d'ancrage sur lequel tout le reste repose. Paiements, retraits, échanges, remboursements et rétrofacturations sont tous modélisés comme des transactions, partageant un même modèle de statuts, un jeton public et une correspondance de statuts unique et simplifiée que les marchands consultent. Les portefeuilles sont multidevises par marchand, avec un historique des soldes et une visibilité sur les réserves, afin qu'un gestionnaire puisse déterminer d'où provient un montant et ce qui est actuellement bloqué.
Routage, paiement et facturation
Les prestataires sont rattachés en tant que modules, les MID sont enregistrés auprès d'eux, et chaque devise dispose de son propre ensemble de méthodes activées. La résolution de routage peut être prévisualisée pour un marchand et une méthode donnés avant que le moindre trafic ne l'atteigne. Le Hosted checkout offre aux marchands une page de paiement à leur image sur le propre domaine de paiement du tenant, et la Processing API est une API signée unique pour créer et consulter des transactions, les particularités de chaque prestataire étant normalisées en instructions de paiement canoniques. Les marchands peuvent également émettre des factures et les envoyer par courrier à leur marque, dans la langue du destinataire, les payeurs réglant sur une page publique ; un annuaire client propre à chaque tenant stocke les coordonnées des payeurs de manière chiffrée, avec une recherche par index aveugle afin que la recherche n'ait jamais besoin de données en clair.
Remboursements, rétrofacturations et litiges
L'ensemble du parcours post-paiement fait partie du socle, et non d'une option : remboursements, gestion des rétrofacturations et un processus de litige structuré. Un gestionnaire peut autoriser un marchand à ouvrir des litiges sur ses propres paiements et retraits, depuis le Merchant panel ou via la Processing API, avec un motif et jusqu'à cinq pièces justificatives. Le gestionnaire résout les litiges, et les soldes sont automatiquement annulés puis réimputés.
Analyses, devises et contrôle des accès
Core inclut des analyses de conversion et de prestataires : taux de réussite, motifs d'échec et volumes dans le temps pour les paiements et les retraits, classés par marchand, prestataire et MID, et filtrables par devise, statut et période. Les marchands disposent de leur propre tableau de bord limité à leurs seules données. Les paires de devises sont associées à des sources de taux et à des verrouillages de taux, les échanges entre marchands s'effectuent sur des cotations en temps réel, et les règles d'arrondi sont appliquées côté serveur afin que les exports et les écrans concordent toujours. L'accès est régi par un RBAC descendant jusqu'aux actions individuelles du panel, avec une authentification à deux facteurs propre à chaque tenant, des réinitialisations de mot de passe, des contrôles de session et un historique enregistré de l'activité administrative.
Toujours actif, dans chaque plan
Core est présent dans chaque plan de facturation et ne peut pas être désactivé. Un tenant ne disposant que de Core peut déjà intégrer des marchands, encaisser des paiements, effectuer des retraits, facturer, échanger des devises et résoudre des litiges — les modules optionnels ajoutent une portée supplémentaire, pas la capacité d'opérer.
