# PR

> Payment Recipient

Le bénéficiaire d'un paiement : la personne ou l'entreprise dont le compte sera crédité. Toujours identifié par son IBAN dans les API DSP2.

_Catégorie: acteur_

---

## Définition

Le **PR** (_Payment Recipient_) est le bénéficiaire d'un paiement : la personne ou l'entreprise dont le compte sera crédité.

Dans le standard STET et plus largement dans les API DSP2 (Berlin Group, OB UK), il est identifié par son IBAN et son nom, transmis dans le bloc `creditor` ou `beneficiary`.

## PR vs PAO : qui paie, qui reçoit

C'est la dualité de base de tout paiement :

- **PAO** (_Payment Account Owner_) — paie : son compte est débité.
- **PR** (_Payment Recipient_) — reçoit : son compte est crédité.

Le PSU, lui, est l'utilisateur du service qui orchestre l'opération. Il peut être le PAO (cas standard : vous payez vous-même), le PR (Payment Request : un marchand demande à être payé) ou un tiers (un comptable agissant pour son client).

## Ce qui caractérise le PR

- Identifié par un IBAN valide, éligible aux instruments utilisés (SCT, SCT Inst, SDD).
- Son nom est rapproché de l'IBAN par la Verification of Payee (VoP), obligatoire depuis 2025 sur les virements instantanés SEPA.
- Peut être un particulier, une entreprise, une administration ou un autre PSP.
- N'a aucune action à effectuer pour recevoir un virement (contrairement à un prélèvement, qui exige un mandat).

## Ce qui ne le caractérise pas

- Il **ne consent à rien** : c'est le PAO qui valide le débit via SCA.
- Il **n'a pas besoin** d'être agréé ni d'avoir une relation contractuelle avec le PISP pour recevoir des fonds.
- Il **ne contrôle pas** le moment de l'exécution : c'est l'ASPSP du PAO qui décide, selon les règles SEPA.

## Dans l'écosystème PSD2

Le PR est passif dans le flux : il est la destination des fonds, sans participer au consentement ni à l'authentification. Sa fiabilité (IBAN valide, nom cohérent) conditionne en revanche la réussite et la sécurité de l'opération.

```mermaid
flowchart LR
    PSU["PSU\n(orchestrateur)"]
    PISP["PISP\nOrdonne le virement"]
    PAO["PAO\n(débité)"]
    ASPSP_PAO["ASPSP du PAO"]
    ASPSP_PR["ASPSP du PR"]
    PR["PR\n(crédité)"]

    PSU -->|"Demande"| PISP
    PISP -->|"Ordre + IBAN du PR"| ASPSP_PAO
    PAO -->|"SCA + consentement"| ASPSP_PAO
    ASPSP_PAO -->|"Vérifie IBAN/nom (VOP)"| ASPSP_PR
    ASPSP_PAO -->|"Virement SEPA / Inst"| ASPSP_PR
    ASPSP_PR -->|"Crédite"| PR
```

## Exemples concrets

- **E-commerce** : vous payez chez Decathlon via Fintecture. Decathlon est le PR, son IBAN marchand est crédité ; vous êtes le PAO (et le PSU).
- **Facture B2B** : votre fournisseur envoie une demande de paiement via Bridge. Il est le PR ; son IBAN est préchargé, vous n'avez rien à saisir.
- **Virement entre proches** : sur Lydia ou Lyf, votre ami est le PR ; l'appli affiche son numéro de téléphone, mais c'est bien son IBAN qui est résolu et crédité.
- **VoP** : depuis octobre 2025, toute banque européenne vérifie que le nom du PR correspond à son IBAN avant un virement instantané — les apps fintech doivent gérer ce contrôle dans leur UX (avertir si « Jean Dupont » ne correspond pas à « SARL Dupont »).

## Sources

- [STET PSD2 API specifications](https://www.stet.eu/en/psd2/) — STET
- [Regulation (EU) 2024/886 (Instant Payments / VOP)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AL_202400886) — EUR-Lex, 2024-03-19

---

Source: https://openfinanceguide.com/fr/glossary/pr