L'infrastructure de paiement, à votre marque

Lancez votre propre
passerelle de paiement.

omwio est la plateforme multi-tenant derrière votre marque. Chaque partenaire dispose d'un tenant isolé, de ses propres domaines, de ses propres marchands et de ses propres rails de traitement — sans construire les registres, le routage ni la conformité.

Multi-tenantMarque blancheConscient PCITemps réel
Un tenant · cinq surfacesyourbrand.com

manager.yourbrand

Panneau gestionnaire du tenant

merchant.yourbrand

Panneau marchand

pay.yourbrand

Paiement hébergé

api.yourbrand

API de traitement

docs.yourbrand

Documentation marchand

5hôtes

Hôtes à votre marque par tenant

manager · merchant · pay · api · docs

2panneaux

Panneaux partenaires isolés

Aucun ne lit au-delà de la frontière

8modules

Modules optionnels packagés

Ouverts par formule, appliqués dans l'API

1contrat

Format d'erreur d'API canonique

Une seule enveloppe pour chaque échec

Capacités

Tout ce qu'une passerelle exige, déjà construit.

Les parties qui demandent des années à bien faire — registres, routage, litiges, rapprochement — arrivent avec la plateforme au lieu d'entrer dans votre feuille de route.

Mouvement des fonds

  • Paiements, versements et échanges entre marchands
  • Remboursements, impayés et flux de litige structurés
  • Versements en masse avec étapes de contrôle et validation
  • Factures avec pages de paiement publiques hébergées

Registre et soldes

  • Portefeuilles multidevises par marchand dans le tenant
  • Historique des soldes avec visibilité des réserves et retenues
  • Paires de devises, sources de taux et verrouillage de taux
  • Règles d'arrondi appliquées côté serveur, pas dans l'interface

Routage et fournisseurs

  • Modules fournisseurs avec instructions de paiement typées
  • MID fournisseurs avec surcharge de méthode par marchand
  • Aperçu de la résolution de route avant toute mise en production
  • Reprises et gestion des états fournisseur d'origine

Contrôle et confiance

  • RBAC jusqu'aux permissions individuelles du panneau
  • 2FA, sessions et réinitialisations de mot de passe par tenant
  • Données personnelles chiffrées avec index aveugles
  • Modules de rapprochement, supervision et antifraude

Pourquoi bâtir dessus

L'avantage, c'est ce que vous n'avez pas à construire.

Tout ce qui suit est soit de la configuration, soit déjà en service. Rien de tout cela ne devient une ligne héritée de votre feuille de route.

Mise sur le marché en semaines

Traitement, registres, routage, litiges et rapprochement sont les parties d'une passerelle qui prennent des années. Elles sont construites, testées et cohérentes entre elles.

Votre marque sur chaque surface

Panneaux, paiement hébergé, documentation marchand et e-mails sortants lisent votre identité de tenant depuis une seule configuration. Les marchands ne voient jamais la plateforme dessous.

Une isolation que l'on peut vendre

Les frontières entre tenants s'appliquent à la résolution de chaque requête, pas via un filtre que quelqu'un peut oublier. C'est la réponse à la question de due diligence que poseront vos partenaires.

Des conditions que vous maîtrisez

Tarifs, commissions et routage se définissent marchand par marchand, et le packaging partenaire par partenaire via les formules.

pay.yourbrand.com/payments/TX-8H2QK…
yourbrand

Montant dû

€149.00

Numéro de carte
4242 4242 4242 4242
Expiration
09 / 29
CVV
•••
Payer €149.00

Sécurisé par yourbrand · TX-8H2QK-4LMPD-91XRT

Le paiement hébergé porte votre identité tandis que la logique de paiement reste sur le chemin éprouvé de la plateforme. Voir ce qui est personnalisable →

API de traitement

Un contrat marchand qui reste stable.

Vos marchands intègrent une fois. Changements de fournisseur, nouvelles voies et nouvelles méthodes atterrissent derrière les mêmes formes publiques.

Requête
POST /v1/transactions HTTP/1.1
Host: api.yourbrand.com
X-Signature: 9f2c…            # HMAC over body + timestamp + nonce
X-Timestamp: 1756310400
Content-Type: application/json

{
  "type": "payment",
  "merchant_order_id": "ORD-10482",
  "amount": "149.00",
  "currency": "EUR",
  "method": "card",
  "customer": { "email": "buyer@example.com" }
}
Réponse
{
  "ok": true,
  "data": {
    "token": "TX-8H2QK-4LMPD-91XRT",
    "status": "pending",
    "amount": "149.00",
    "currency": "EUR",
    "payment_instructions": [
      {
        "type": "redirect",
        "title": "Continue to payment page",
        "payload": { "url": "https://pay.yourbrand.com/…" }
      }
    ]
  }
}

Requêtes signées

Chaque appel de traitement est authentifié par signature HMAC, horodatage et nonce — les requêtes rejouées sont refusées.

Une seule enveloppe d'erreur

Les échecs de validation, d'authentification, de signature et de conflit renvoient la même forme ok / error.code / error.message / error.details.

Commandes idempotentes

merchant_order_id est unique par tenant et marchand ; les doublons renvoient un 409 maîtrisé plutôt qu'une erreur de base isolée.

Instructions canoniques

Les particularités fournisseur sont normalisées en card_input, card_p2p_requisites, crypto_wallet_address et redirect — aucune formulation fournisseur ne parvient au marchand.

Mise en service

Du domaine à la première transaction.

Aucun code de traitement à écrire. Le travail est de la configuration, et il est réversible.

01

Prenez votre domaine

Pointez votre domaine vers la plateforme. Les hôtes gestionnaire, marchand, paiement, API et documentation se lèvent à votre marque et isolés.

02

Branchez les fournisseurs

Ajoutez acquéreurs et PSP comme modules fournisseurs, enregistrez les MID et définissez les méthodes prises en charge par devise.

03

Fixez les conditions

Réglez tarifs, commissions et routage par marchand. Prévisualisez la résolution de route avant qu'une seule transaction ne passe.

04

Intégrez les marchands

Invitez les marchands dans leur propre panneau, avec clés d'API, callbacks et documentation déjà générés à votre marque.

Formules

Core reste constant. Les modules vous appartiennent.

Chaque tenant tourne sur le même contrat de base. Les modules optionnels sont attribués par formule et figés dans l'instantané de droits du tenant — modifier une formule ne change jamais en silence un partenaire en production.

Toujours inclus

Core

Ce n'est pas une version d'essai. Un tenant avec le seul Core peut intégrer des marchands, encaisser, verser, facturer et résoudre des litiges. Présent dans chaque formule, sur chaque tenant, dès le premier jour.

  • Marchands, tarifs et commissions
  • Paiements, versements, remboursements et impayés
  • Portefeuilles multidevises et historique des soldes
  • Factures et paiement hébergé
  • Fournisseurs, MID et routage
  • Litiges avec dépôt de preuves
  • Paires de devises, taux et échanges
  • RBAC, 2FA et journal d'audit
Ce que couvre Core

Voies

Ajoutez un fournisseur, pas une réécriture.

Les modules fournisseurs renvoient des objets d'instruction typés. La plateforme les normalise en quatre formes canoniques — saisie de carte, coordonnées card P2P, adresse de portefeuille crypto, redirection — les stocke et affiche la bonne étape de paiement. Les nouvelles voies ne se répercutent pas sur les intégrations marchands.

Argent entrant

  • Acquisition carteSaisie de carte hébergée ou directe
  • Coordonnées card P2PCarte à carte avec dépôt de preuve
  • Virements bancairesVoies locales et crédit de type SEPA
  • Portefeuilles cryptoÉmission d'adresse et confirmation

Argent sortant

  • VersementsÀ l'unité et par lot, avec étape de libération
  • ChangeCotations par paire avec verrouillage de taux

Ce que voit le payeur

  • Redirection hébergéePage du fournisseur, votre jeton de paiement
  • Méthodes localesPropres à la région, même forme d'instruction
Types d'instruction canoniquescard_inputcard_p2p_requisitescrypto_wallet_addressredirect

Confiance

L'isolation est l'architecture, pas un réglage.

tenant.hierarchy.live
platform.omwiomanager.partner-amanager.partner-bmerchantmerchantmerchantmerchant
isolation par domaineRBAC · 2FA · journal d'audit

Isolation du tenant par domaine

La résolution du tenant se fait au bord de chaque requête. Les cookies sont liés à l'hôte, et lire au-delà de la frontière est impossible par construction, non par convention.

Traitement des cartes pensé PCI

Les données de carte sensibles sont saisies sur la surface de paiement hébergée et transmises aux fournisseurs par des chemins sécurisés, sans être conservées dans le domaine du panneau.

Données clients chiffrées

Les fiches clients sont stockées chiffrées, avec des index aveugles pour la recherche par référence, e-mail et téléphone — la recherche fonctionne sans exposer de données personnelles en clair.

RBAC fin et audit

Les rôles portent des permissions individuelles par action du panneau. L'activité d'administration est journalisée, et la 2FA d'un marchand peut être réinitialisée depuis le panneau gestionnaire si besoin.

À propos d'omwio

Nous construisons la partie que personne ne voit.

Nous sommes une infrastructure, pas un acquéreur. Nous ne détenons jamais vos fonds et ne sommes jamais le prestataire de paiement déclaré de vos marchands — nous exploitons la couche de contrôle multi-tenant au-dessus de vos propres relations fournisseurs.

L'isolation relève de l'architecture

Pas d'un filtre de requête que l'on peut oublier. La résolution du tenant se fait au bord de chaque requête.

Un contrat stable vaut mieux qu'un contrat riche

Les particularités fournisseur sont normalisées avant d'atteindre vos marchands : leur intégration survit à notre feuille de route.

La marque blanche, c'est toute la surface

Panneaux, paiement et e-mails sortants. Si l'un d'eux se lit comme le produit d'un autre, l'illusion tombe.

Étape suivante

Voyez-la tourner sous votre marque.

Nous montons un tenant sur un domaine de démonstration, connectons un fournisseur de test et parcourons tout le chemin — intégration d'un marchand, un paiement réel, un versement et un litige.