Request to Pay

Le Request to Pay (RTP) est une messagerie basée sur la norme Iso20022 mettant en relation un fournisseur et son client, plus généralement un Bénéficiaire et un Débiteur pour le règlement d’une dette ou d’une créance. Les types de transaction concernent le commerce physique, le commerce en ligne, les transactions de Personne à Personne, les services de e-facturation, la perception d’impôts ou de taxes…. Le RTP devient un élément clé du commerce de détail de bout en bout pour les transactions dans les magasins en ligne et physiques. Les segments économiques concernés sont client à entreprise (C2B), entreprise à client (B2C), entreprise à entreprise (B2B), personne à personne (P2P), gouvernement à client (G2C), gouvernement à entreprise (G2B).

Le RTP est basé sur le modèle connu de quatre coins faisant intervenir les RTP Service Providers des bénéficiaires et émetteurs. Les RTP Service Providers peuvent-être des PSP, des E-invoicing Service Providers, des E-commerce Service providers … Seuls les PSP peuvent exécuter des fonctions liées au paiement, telles que l’initiation de paiement ou l’exécution d’instructions de paiement passées via les Clearing and Settlement Mechanisms (CSM). Le modèle peut se réduire à trois coins dans l’hypothèse où le RTP Services Provider est identique aux deux intervenants, voire en direct en cas de relation particulière. Dans un premier temps, l’instrument de règlement découlant des échanges Bénéficiaire/Débiteur est le SCT classique ou le SCt Ins.

L’initiation du RTP est une étape propre au Bénéficiaire (génération du flux par l’appareil du commerçant, facture électronique, smartphone du bénéficiaire…) au cours de laquelle le contenu du RTP est alimenté à minima d’informations obligatoires, telles que le montant à payer, la référence de la transaction, l’identification du débiteur et de son PSP. Le RTP est reçu dans un premier temps par le PSP du bénéficiaire pour être est injecté dans un CSM. Le RTP Service Provider réceptionne à son tour le RTP qu’il communique au débiteur qui, le confirme où le refuse. Si l’option est autorisée par le Bénéficiaire, le Débiteur peut payer un montant différent de celui indiqué dans le RTP. Le « status report » est l’étape où l’acceptation ou le refus du Payeur est transmis au Bénéficiaire via un message de rapport d’état. Selon le cas d’utilisation, le rapport d’état peut être liés à l’initiation du paiement. En cas d’acceptation, le payeur remet à son PSP l’instruction pour initier le paiement. La PSP du bénéficiaire s’engage à exécuter le paiement à la date fixée au regard de la réglementation en vigueur et des obligations fixées pour les types de paiement. L’initiation du paiement, même si elle ne fait pas partie du cycle de vie RTP lui-même, est incluse pour illustrer le lien étroit qu’il entretient avec le RTP, car il utilise les données de paiement du RTP et effectuée sur action du payeur. La notification de l’exécution de l’instruction de paiement, également ne faisant pas partie du cycle de vie RTP lui-même, est inclus pour illustrer la possibilité que le PSP du payeur notifie le PSP du bénéficiaire que l’instruction de paiement a été exécutée.

Les aspects temporels, « maintenant » ou « plus tard », peuvent être attribués à l'acceptation RTP et à l'initiation du paiement avec les significations accepter maintenant, accepter plus tard, payer maintenant, payer plus tard. En plus des critères temporels, le RTP inclus des fonctions qui répondent à d'autres besoins principalement en relation avec le paiement :

• Notification au bénéficiaire de l'exécution de l'instruction de paiement, via son PSP, permettant ainsi au bénéficiaire d’initier étapes ultérieures du flux d'achat (par exemple, préparation de la livraison) avant le dénouement de l’opération.
• Garantie de paiement, pré-autorisation de paiement, donné par le PSP du débiteur.
• Paiement en plusieurs échéances.
• Initiation du paiement dans l'application PSP du payeur qui ne communique pas l’identité du bénéficiaire

En plus de la requête RTP principale et de son rapport d'état correspondant, deux autres requêtes sont nécessaires pour compléter les besoins fonctionnels et techniques : Demande d’annulation de RTP à la demande du bénéficiaire et la Demande de renseignements techniques du RTP. Dans le premier cas, le bénéficiaire aura besoin d’annuler sa transaction en raison par exemple d'un montant erroné ou une erreur sur l'identification du Payeur. Dans certains cas, le bénéficiaire peut avoir besoin d'annuler un précédent RTP envoyé, par exemple en raison d'un montant erroné ou erreur sur l'identification du Payeur. La demande d'annulation est envoyée par le bénéficiaire ou son fournisseur au fournisseur du payeur en utilisant le même chemin de routage que le RTP d'origine. Mais avant d’émettre une annulation, le fournisseur de services RTP du bénéficiaire peut avoir à connaître la validité de sa demande, RTP pouvant être déjà payé, refusé ou annulé.