vIBAN · Rapprochement

Un rapprochement par construction

Quand chaque payeur règle sur son propre IBAN, un paiement entrant ne peut signifier qu'une seule chose. Le problème de rapprochement n'est pas résolu : il cesse d'exister.

01

Un compte, des milliers d'adresses

En coulisses, il y a un seul compte principal. En surface, chaque payeur, locataire ou abonné reçoit un IBAN virtuel dédié. Dans les deux cas, l'argent arrive sur le compte principal — mais déjà étiqueté : qui l'a envoyé et pourquoi.

Écran des coordonnées bancaires affichant l'IBAN virtuel dédié d'un client, le BIC et l'adresse de la banque avec boutons de copie, un bouton Partager et des repères sur SEPA Instant et les délais des virements SEPA

La vue du payeur — un IBAN rien qu'à lui, à copier et partager.

02

Conçu pour les plateformes

L'émission se fait en masse, pas formulaire par formulaire — une marketplace qui intègre mille vendeurs crée mille IBAN en une seule opération. Les étiquettes d'usage séparent les flux : loyers d'un côté, abonnements de l'autre, versements marketplace dans leur propre couloir — chaque entité de la plateforme dispose ainsi de son propre numéro de compte rapprochable.

  1. 01Émission en masse via la console ou l'API
  2. 02IBAN étiquetés par usage pour une séparation nette des flux
  3. 03Historique par payeur sans moteur de matching
Parcours d'émission en masse avec un CSV validé de 2,400 payeurs, un IBAN prévisualisé sur chaque ligne et un panneau de configuration pour choisir la plage, l'étiquette d'usage et le préfixe de référence avant l'émission

Émission en masse — 2,400 lignes validées, IBAN réservés, une seule action pour émettre.

Intégration

De l'émission au relevé, en cinq étapes.

  1. 01

    ISSUE

    Créez un vIBAN par payeur — un seul via l'API, ou 2,400 par CSV avec une étape de revue.

  2. 02

    SHARE

    Chaque payeur règle sur son propre IBAN ; aucune référence à saisir de travers.

  3. 03

    MATCH

    Les crédits s'identifient d'eux-mêmes par construction — 99,6 % rapprochés automatiquement dans la démo.

  4. 04

    EXCEPT

    Le reste arrive dans une file d'exceptions comptabilisée, historique joint.

  5. 05

    REPORT

    Relevés par vIBAN, en CSV et PDF, envoyés par e-mail le 1er de chaque mois.

Fonctionnalités

Tout ce que Protocore vIBAN propose.

  1. 01La console opérateur
  2. 02Une vue claire pour le payeur
  3. 03Émission en masse avec étape de revue
  4. 04Des relevés que la finance ouvre volontiers
  5. 05Des webhooks avec accusés de livraison
  6. 06Les comptes derrière le programme
  7. 07Des IBAN par payeur
  8. 08Tags de finalité
  9. 09Un rapprochement par construction
  1. 10Un seul compte maître
  2. 11Plages d'IBAN dédiées
  3. 12Historique par payeur
  4. 13Conçu pour les plateformes
  5. 14Des retours comptabilisés
  6. 15Mettre en pause sans formalités
  7. 16Des brouillons avant les lots
  8. 17Des quotas sur lesquels planifier
  9. 18Des préfixes de référence par lot
  1. 19Vos identifiants voyagent avec les nôtres
  2. 20Console et API sont jumelles
  3. 21Testez les événements avant l'argent réel
  4. 22Des endpoints bien tenus
  5. 23Des exports en deux formats
  6. 24Des relevés planifiés
  7. 25Filtrer le flux
  8. 26Chaque modification a sa raison
Lire les 26 fonctionnalités en détail

01La console opérateur

Un seul écran couvre tout le programme : 12 480 vIBAN actifs, 2,4 M€ routés aujourd'hui, 8 912 crédits rapprochés automatiquement. Chaque ligne indique l'IBAN, son titulaire, son tag de finalité et les fonds reçus aujourd'hui. Recherchez par IBAN, client ou référence ; exportez le registre en CSV.

  • Recherche par IBAN, client et référence
  • Statut par IBAN — actif ou en pause, d'un coup d'œil
  • Export CSV du registre complet en un clic

02Une vue claire pour le payeur

Les clients voient les coordonnées de leur propre compte : l'IBAN dédié avec un bouton de copie, le BIC pour les virements hors SEPA, le nom et l'adresse de la banque, et un bouton de partage pour la personne qui les paie. Chaque virement vers cet IBAN arrive sur leur solde déjà rattaché à eux — le payeur n'a jamais de référence à saisir.

03Émission en masse avec étape de revue

Un CSV de 2 400 payeurs est importé et validé — 2 400 valides, 0 erreur — puis prévisualise l'IBAN exact que recevra chaque ligne, réservé dans la plage à l'import et attribué à l'émission. Configurez la plage, le tag de finalité et le préfixe de référence, puis émettez tout le lot en une seule action. La même opération fonctionne via l'API.

  • Source, configuration, revue — avec un brouillon à sauvegarder entre les étapes
  • IBAN réservés en amont, donc aucune collision à l'émission
  • Un webhook par vIBAN émis, activable par lot

04Des relevés que la finance ouvre volontiers

La période affichée totalise 412 380,44 € sur 8 912 crédits, rapprochés automatiquement à 99,6 % — les 34 cas manuels et les 12 paiements retournés sont comptés, pas cachés. Chaque vIBAN exporte son propre relevé en CSV ou PDF, la période entière s'exporte en une action, et les relevés mensuels sont envoyés par e-mail à la boîte de la finance le 1er.

05Des webhooks avec accusés de livraison

Chaque crédit, retour, émission et pause est un événement, et chaque événement affiche sa livraison : code de statut, latence et état de retry pour chaque tentative. Les livraisons sont signées en HMAC-SHA256 et retentées 6 fois sur 24 heures avec un backoff exponentiel — et une livraison qui épuise ses tentatives obtient un bouton de relance manuelle, pas un haussement d'épaules.

  • payment.incoming, payment.returned, viban.* — abonnement par endpoint
  • Secrets propres à chaque endpoint ; les endpoints se mettent en pause sans être supprimés
  • 8 946 événements sur les dernières 24 h, 99,7 % livrés — affiché sur la page

06Les comptes derrière le programme

Dans la console opérateur, les comptes de réception derrière le programme sont des données, pas un savoir tacite : un compte actif par devise, et en retirer un promeut automatiquement le suivant. Chaque modification demande un motif écrit et est inscrite au journal d'audit.

07Des IBAN par payeur

Chaque payeur obtient un IBAN dédié : chaque paiement entrant nomme son émetteur avant même que quelqu'un le regarde. Pas de champ de référence à mal saisir, pas de file de rapprochement à traiter. L'identification est une propriété du numéro de compte, pas un processus.

08Tags de finalité

Chaque vIBAN porte un tag : rent-collection, subscriptions, marketplace-payouts, payroll. Les flux restent séparés au niveau du compte, si bien que le reporting par finalité est un filtre, pas un projet.

09Un rapprochement par construction

Quand chaque payeur règle sur son propre IBAN, un crédit entrant ne peut signifier qu'une chose. Sur la période de démo, 99,6 % des 8 912 crédits se rapprochent d'eux-mêmes — et le petit reste atterrit dans une file manuelle plutôt que dans le mystère.

10Un seul compte maître

Derrière chaque vIBAN se trouve un seul vrai compte. Les fonds se concentrent automatiquement — pas de soldes de sous-comptes à centraliser, pas de fragmentation à gérer. En surface, des milliers d'adresses ; dans le ledger, un seul compte.

11Plages d'IBAN dédiées

Les vIBAN sont émis depuis des plages dédiées — le programme de démo tourne sous RO49 PRCT, avec le nombre d'IBAN libres par plage affiché à l'émission. Les plages séparent proprement programmes, marques ou entités, tout en acheminant l'ensemble vers le compte maître.

12Historique par payeur

Chaque vIBAN accumule son propre historique de paiements : le dossier d'un payeur est donc complet par construction. Un litige ou un audit part d'une liste filtrée, pas d'une enquête.

13Conçu pour les plateformes

L'onboarding des vendeurs et des locataires peut créer un vIBAN comme une étape du parcours : ouvrir le compte, transmettre l'IBAN, commencer à encaisser. La vue client est livrée en whitelabel — la démo s'affiche en Powered by Protocore ; la vôtre sous votre marque.

14Des retours comptabilisés

Certains paiements sont rejetés — compte clos, coordonnées erronées. Les retours SEPA transportent leur code motif dans un événement payment.returned et ont leur propre compteur sur la page des relevés — des données avec une cause, pas des mystères. Le cas limite a sa ligne, pas un fil de support.

15Mettre en pause sans formalités

Un vIBAN se met en pause en une action, et le flux d'événements enregistre qui l'a fait et d'où. « En pause » apparaît comme un statut partout où l'IBAN figure — le registre, les relevés, le flux.

16Des brouillons avant les lots

Un lot configuré s'enregistre comme brouillon : source validée, plage choisie, rien d'émis. Le parcours suit source, configuration, revue — pour que le clic irréversible soit le dernier, volontairement.

17Des quotas sur lesquels planifier

L'émission s'exécute dans la limite d'un quota mensuel, compteur visible, et un lot indique ce qu'il ajoute avant son lancement — 1 204 utilisés sur 5 000, ce lot porte le total à 3 604. La capacité est de l'arithmétique, pas un message d'erreur.

18Des préfixes de référence par lot

Chaque lot marque ses crédits d'un préfixe de référence — ARC-PAYOUT- dans la démo — pour que les systèmes en aval reconnaissent leurs flux au premier coup d'œil.

19Vos identifiants voyagent avec les nôtres

Chaque ligne de payeur porte une référence externe issue de votre système — EXT-00311 dans la démo — qui reste rattachée au vIBAN. Les recherches fonctionnent sur vos identifiants, pas seulement les nôtres.

20Console et API sont jumelles

Tout ce que fait la console, l'API le fait — émettre, mettre en pause, interroger, exporter. L'import CSV et l'appel API déclenchent la même opération ; la console est un client, pas un chemin à part.

21Testez les événements avant l'argent réel

Envoyez un événement de test vers n'importe quel endpoint, directement depuis la console. L'intégration fait ses preuves sur des livraisons synthétiques avant l'arrivée du premier vrai crédit.

22Des endpoints bien tenus

Chaque endpoint a ses propres secrets de signature et ses propres abonnements, et peut être mis en pause sans être supprimé — la démo garde un endpoint de staging en pause juste à côté de celui de production, actif.

23Des exports en deux formats

CSV pour les machines, PDF pour les humains — par vIBAN ou pour toute la période. L'export est conçu pour être importé, pas ressaisi.

24Des relevés planifiés

Les relevés mensuels s'envoient d'eux-mêmes par e-mail à l'adresse de la finance le 1er du mois. Le rapport de routine devient un abonnement, plus une tâche récurrente sur la liste de quelqu'un.

25Filtrer le flux

Les événements se filtrent par type, vIBAN ou référence ; le registre de la console se recherche par IBAN, client ou référence. Retrouver un paiement parmi des milliers, c'est une requête avec trois points d'entrée.

26Chaque modification a sa raison

Les modifications du programme faites par les opérateurs — comptes, mises en pause, retraits — exigent un motif et sont inscrites dans le journal d'audit. L'historique du programme s'explique par écrit.

Écrans

Le produit de l'intérieur.

Interface réelle du produit, avec des données de démo.

Relevés — €412,380.44 encaissés, 99.6% rapprochés automatiquement, CSV ou PDF par vIBAN.
Événements et webhooks — chaque crédit livré avec signature, nouvelles tentatives en toute transparence.
Derrière le programme — les comptes de réception, un seul actif par devise.

FAQ

Les IBAN virtuels : vos questions.

  • Ce sont des IBAN adressables, émis depuis des plages dédiées et routés vers un compte principal unique. Un paiement vers un vIBAN arrive comme n'importe quel crédit SEPA ; les fonds se concentrent automatiquement sur le compte principal — sans traitement de sweeping.

  • Le retour transmet son code motif dans un événement payment.returned et dispose de son propre décompte dans les relevés. Les retours sont des données avec une cause associée, pas des mystères à élucider.

  • Il vous faut un processus d'exceptions, pas une équipe de matching. Avec un payeur par IBAN, les crédits s'identifient d'eux-mêmes — 99.6% rapprochés automatiquement dans la démo — et le reste part en revue avec tout l'historique du payeur joint.

  • Émettez en masse — un CSV de 2,400 payeurs est validé, prévisualisé et émis en une seule action — et étiquetez chaque vIBAN par usage. Chaque vendeur, locataire ou entité obtient son propre numéro de compte rapprochable ; le reporting par usage devient un simple filtre, pas un projet.

Évaluer

Émettez un IBAN virtuel et regardez-le se rapprocher.

01

Démo guidée

Nous déroulons toute la boucle avec vous — émettre, partager, rapprocher, traiter les exceptions, reporter — sur les mêmes données de démo, y compris l'émission en masse de 2,400 payeurs.

02

Tenant sandbox

Un programme de test avec compte principal et émission activée, pour que votre équipe puisse créer des vIBAN, envoyer des crédits de test et les voir s'identifier d'eux-mêmes.

03

Accès API, webhooks et documentation

L'API d'émission, les webhooks de paiement et de cycle de vie, et la documentation d'intégration — de quoi brancher le rapprochement sur votre propre back-office.

04

Autonome ou whitelabel

Évaluez sous la marque Protocore ou émettez sous la vôtre — dans les deux cas, le compte principal reste la source de vérité unique.

Pour aller plus loin

Disponibilité

Disponible en solution autonome ou en whitelabel — émettez sous votre marque.

Dans l'écosystème

les commandes en paiement par virement de Gateway portent des références vIBAN, les versements PoS arrivent sur les mêmes rails IBAN, et Center traite les exceptions que le matching de vIBAN laisse de côté.

Choisissez un produit. Ou prenez le cœur.

Tout ce qui précède tourne dans des démos en production que nous pouvons vous présenter — en standalone, en whitelabel ou en plateforme unique. Dites-nous ce que vous construisez et nous vous montrerons le chemin le plus court.