SEPA Request to Pay

Cette distinction tranche toutes les questions de conception qui suivent. Le SRTP transporte une demande et une réponse. Le paiement qui suit passe par un virement SEPA, le plus souvent instantané, et c'est ce virement qui porte l'argent et le caractère définitif. Si le client accepte un message SRTP et que le virement échoue, la demande a bien été remise et la facture reste ouverte.

D'où l'association naturelle du schéma avec les virements instantanés en Europe. La demande apporte au bénéficiaire les données de facture et la certitude que la bonne personne l'a vue, le virement instantané lui apporte l'argent en dix secondes avec une confirmation. Ensemble, ils font ce que fait une carte en caisse, mais de compte bancaire à compte bancaire, sujet des paiements de compte à compte.

L'EPC publie le recueil de règles du schéma SRTP et, à côté, les guides de mise en œuvre et une spécification d'API. Pour un développeur, la répartition compte: le recueil dit ce que les participants se doivent et ce que signifient les messages, les guides disent comment remplir chaque champ, et la spécification d'API dit comment passer l'appel. Un participant qui ne lit que le recueil construit un système qui n’est pas interopérable.

Le schéma décrit quatre rôles. Le bénéficiaire et le payeur sont les entreprises ou personnes liées par la facture. Chacun a un prestataire SRTP, qui convertit ses données au format du schéma et les échange avec l'autre prestataire. Un commerçant en ligne transmet à son prestataire le nom de l'acheteur, l'IBAN, le montant et l'article, ce prestataire construit la demande au format du recueil, et le prestataire de l'acheteur la livre dans son application.

Toute entreprise peut devenir prestataire SRTP si elle exploite l'infrastructure technique et adhère aux règles du schéma, comme le note PayTechLaw. Banques et établissements de paiement sont donc bien placés, sans exclusivité. La demande rejoint le payeur là où il se trouve déjà: application bancaire, notification push, e-mail ou messagerie. Ce choix revient au prestataire et décide si le client voit la demande à temps pour payer à l'échéance.

En pratique, les deux cas se présentent de façon très différente. En caisse en ligne, la demande est immédiate: l'acheteur choisit le moyen de paiement, la demande arrive en quelques secondes dans son application bancaire, il l'approuve avec l'authentification que sa banque exige déjà, et le virement instantané se règle avant que la page ne se recharge. Face à la carte, le commerçant gagne un coût plus bas et l'absence de rétrofacturation; il perd la voie de contestation de la carte.

Sur facture, la demande est différée, cas plus intéressant pour une entreprise allemande. Un message SRTP peut porter une échéance, si bien que le client le reçoit à l'envoi de la facture et paie le jour dit. La référence voyage avec le paiement, et le rapprochement cesse d'être un exercice de correspondance. Les paiements e-commerce en Allemagne traitent du côté caisse, la trésorerie d'entreprise du côté facture.

Un prélèvement SEPA tire les fonds. Le bénéficiaire détient un mandat, lance l'encaissement, et l'argent quitte le compte du payeur, attentif ou non. Le SRTP, lui, pousse. Le bénéficiaire ne peut que demander, et chaque paiement exige l'autorisation propre du payeur, donc aucun mandat à recueillir, conserver ou prouver.

Tout l'argument tient dans cet arbitrage. Le prélèvement donne à une entreprise d'abonnement une trésorerie prévisible et un risque de remboursement de huit semaines. Le SRTP n'a aucun risque de remboursement, puisque le payeur a autorisé chaque paiement, mais un taux d'encaissement qui dépend des réponses des clients. Pour des montants récurrents variables, la réponse de l'open banking s'appelle paiements récurrents variables, à mi-chemin entre les deux.

Envoyer une demande ne coûte rien, et c'est le problème de sécurité caché dans la commodité. Le schéma garantit qu'un message est arrivé au bon format; il ne garantit pas que l'expéditeur est le fournisseur qu'il prétend être. L'usurpation de fournisseur est le schéma à prévoir: une demande qui ressemble à la facture habituelle, avec un autre IBAN derrière.

Une entreprise qui reçoit des demandes a donc besoin de la même discipline que pour les factures par e-mail. Vérifiez le compte du fournisseur dans le référentiel fournisseurs, traitez un IBAN modifié comme un événement qui exige un rappel sur un numéro connu, et rapprochez la demande du bon de commande avant toute approbation. La prévention de la fraude en Allemagne détaille les contrôles, et la vérification du bénéficiaire repère le nom qui ne correspond plus au compte.

L'EPC publie le registre des participants au schéma SRTP, et l'adoption a été plus lente que prévu par ses concepteurs. Le problème de l'œuf et de la poule est structurel: un commerçant ne proposera pas un moyen que peu de banques clientes reçoivent, et une banque ne construira pas la réception de demandes qu'aucun commerçant n'envoie. Wero et l'European Payments Initiative s'attaquent au même manque côté consommateur, sujet de Wero en Allemagne.

Une banque qui adhère comme prestataire du payeur doit recevoir les demandes, les présenter dans son application de façon compréhensible, permettre au client d'accepter, de refuser ou de demander une date ultérieure, et relier l'acceptation à sa propre initiation de paiement. Un prestataire côté bénéficiaire doit valider les données de la demande, traiter les réponses de statut et informer son commerçant. Les deux côtés ont besoin des données d'identification et d'accessibilité du schéma, le même problème d'acheminement que la vérification du bénéficiaire résout avec un annuaire.

Le SEPA Request-to-Pay est un schéma de messages de l'EPC où un bénéficiaire envoie une demande de paiement structurée à un payeur, qui l'accepte ou la refuse dans son application bancaire. Le schéma transporte des demandes jusqu'à 100 000 euros sans déplacer d'argent: le paiement qui suit une acceptation est un virement SEPA distinct.

Non, le SRTP est une couche de messages placée avant le paiement. Un client qui accepte une demande autorise encore un virement, et c'est ce virement qui constitue le paiement. Un commerçant qui propose le SRTP en caisse offre donc un paiement de compte à compte avec une demande jointe, et les règles de règlement viennent du virement, pas du SRTP.

Non. Un message SRTP porte les données nécessaires pour payer, et le droit fiscal allemand et européen exige davantage sur une facture. La demande accompagne donc la facture sans la remplacer, et une entreprise qui veut supprimer sa facturation doit encore respecter à part les règles de facturation. Les versions futures du schéma devraient gérer les paiements partiels et échelonnés, ce qui étend ce qu’une seule demande peut régler.