Accès invité aux liens de paiement : autorisations et partage
Lorsqu’un client ouvre un lien de paiement, il n’est pas connecté. Salesforce le traite comme l’utilisateur invité de votre site public : une identité anonyme et partagée qu’utilise chaque visiteur de ce site. Ce que l’utilisateur invité peut lire, n’importe quel visiteur peut le lire. L’accès invité se configure donc avec soin : l’invité doit pouvoir ouvrir l’ordre qui se trouve derrière un lien actif et le payer, et rien d’autre.
Trois couches y parviennent, et les trois sont nécessaires :
| Couche | Ce qu’elle décide | Où elle se configure |
|---|---|---|
| Accès aux objets, aux classes et aux métadonnées | Qu’un invité peut utiliser les écrans REDA Pay et ces types d’enregistrement | L’ensemble d’autorisations REDA Pay - Public Site User, ou les mêmes paramètres sur le profil invité |
| Règles de partage pour les invités | Quels enregistrements : uniquement les ordres qui ont un lien actif, et ce dont ils ont besoin pour s’afficher | Configuration → Paramètres de partage |
| Pages publiques | Que les pages du lien s’ouvrent sans connexion | Experience Builder |
Cet article configure les trois pour le site qui héberge vos liens de paiement. La création des pages et le raccordement du compte de traitement sont décrits dans Configurer le site public des liens de paiement.
- Le site public existe et les pages des liens sont créées ; consultez Configurer le site public des liens de paiement.
- Vous êtes administrateur Salesforce et pouvez modifier les profils, les paramètres de partage et le site.
Étape 1 — Trouver l’utilisateur invité du site
Chaque site a son propre utilisateur invité et son propre profil invité. Utilisez ceux du site qui héberge les pages des liens.
- Ouvrez Configuration → Expériences numériques → Tous les sites (Digital Experiences → All Sites) et cliquez sur Builder (le lien qui ouvre Experience Builder) à côté du site.
- Dans Experience Builder, ouvrez Paramètres → Général (Settings → General) et, sous Profil de l’utilisateur invité (Guest User Profile), cliquez sur le nom du profil. Le profil invité s’ouvre dans la Configuration.
- Sur le profil, cliquez sur Utilisateurs attribués (dans l’interface de profil standard, View Users) : l’unique utilisateur listé est l’utilisateur invité du site. Notez son nom ; vous le choisirez en créant les règles de partage.
Étape 2 — Donner à l’invité l’accès aux objets et aux écrans REDA Pay
Choisissez l’une de deux méthodes équivalentes. Les deux donnent exactement le même accès.
Option A : attribuer l’ensemble d’autorisations (recommandé). Depuis la liste des utilisateurs du profil invité, cliquez sur l’utilisateur invité, faites défiler jusqu’à Attributions d’ensemble d’autorisations, cliquez sur Modifier les attributions, ajoutez REDA Pay - Public Site User et cliquez sur Enregistrer. Les mises à niveau de REDA Pay tiennent l’ensemble à jour.
Option B : placer les mêmes paramètres sur le profil invité. Si vous préférez les profils, modifiez le profil invité et accordez ce que contient l’ensemble d’autorisations :
| Sur le profil invité | Accorder |
|---|---|
| Paramètres d’objet : Pay Order, Pay Customer, Pay Profile, Processing Account, Fee Setup | Lecture |
| Paramètres d’objet : Pay Method, Pay Transaction | Lecture, création |
| La sécurité au niveau du champ de ces objets | Le même accès aux champs que l’ensemble d’autorisations : ouvrez REDA Pay - Public Site User → Paramètres d’objet et reproduisez chaque objet |
| Accès aux classes Apex activé | rpay.NewPayOrderController et rpay.NewPayMethodController |
| L’accès aux types de métadonnées personnalisées (Enabled Custom Metadata Type Access) | REDA Pay Process Config et REDA Pay Setup |
Dans l’interface de profil améliorée, ces deux dernières sections s’appellent Accès à la classe Apex et Types de métadonnées personnalisées.
L’invité ne reçoit ni modification, ni suppression, ni Afficher tout, ni Modifier tout sur aucun objet REDA Pay. La création est accordée sur exactement deux objets : Pay Method, pour la carte ou le compte bancaire à usage unique que saisit le payeur, et Pay Transaction.
L’ensemble d’autorisations active aussi rpay.PayloadCallback, la classe qui reçoit les messages webhook de Payload. Un site qui ne sert que des liens de paiement ne l’utilise pas. Si vous recevez les webhooks sur un site distinct, l’invité de ce site n’a besoin que de rpay.PayloadCallback ; consultez Configurer les webhooks.
Tout ce qu’un payeur anonyme peut faire, dans un seul tableau. Notez ce qui manque : ni modification, ni suppression.
Étape 3 — Créer les quatre règles de partage pour les invités
L’accès aux objets dit que l’invité peut lire les Pay Orders ; les règles de partage disent lesquels. Les enregistrements REDA Pay sont privés pour les utilisateurs externes : sans ces règles, tous les liens échouent. Dans Configuration → Paramètres de partage, dans la liste des règles de partage de chaque objet, cliquez sur Nouveau et créez :
| Objet | Type de règle | Critères | Partager avec | Accès |
|---|---|---|---|---|
| Pay Order | Accès des utilisateurs invités, basé sur des critères | Has Active Link égal à True | L’utilisateur invité du site | Lecture seule |
| Pay Customer | Accès des utilisateurs invités, basé sur des critères | Order Link Expiration Date Time différent de (vide) | L’utilisateur invité du site | Lecture seule |
| Pay Profile | Accès des utilisateurs invités, basé sur des critères | Is Active égal à True | L’utilisateur invité du site | Lecture seule |
| Processing Account | Accès des utilisateurs invités, basé sur des critères | Is Active égal à True | L’utilisateur invité du site | Lecture seule |
Pour la règle Pay Customer, choisissez l’opérateur différent de et laissez la valeur vide. REDA Pay renseigne l’Order Link Expiration Date Time avec l’expiration du lien actif du client et le vide lorsque son dernier lien actif prend fin : la règle ne correspond donc qu’aux clients qui ont un lien actif.
Les Fee Setups et les Pay Transactions n’ont pas besoin de règle : ils suivent leur Processing Account et leur Pay Order.
Les quatre règles. Ensemble, elles ouvrent exactement ce dont un lien actif a besoin.
Ce que l’invité peut et ne peut pas atteindre
Has Active Link est coché sur un ordre Link tant que son lien est utilisable. REDA Pay le décoche lorsque l’ordre est payé, lorsque quelqu’un le révoque et environ une minute après l’expiration du lien. L’ordre sort alors de lui-même de la vue de l’invité, sans intervention de l’administrateur. En pratique :
| Situation | L’invité peut-il l’ouvrir ? |
|---|---|
| Un ordre Link créé il y a une minute | Oui |
| Le même ordre après paiement | Non |
| Un lien expiré ou révoqué | Non |
| Un ordre Immediate ou Schedule | Non : ils n’ont jamais de lien actif |
| Le lien d’un autre client, adresse modifiée | Non : l’identifiant de l’adresse est chiffré, et un identifiant altéré est refusé |
L’identifiant de l’ordre dans un Link URL est chiffré avec la clé de votre organisation ; consultez Générer la clé de chiffrement.
Étape 4 — Rendre publiques les pages des liens
- Dans Experience Builder, ouvrez Paramètres → Général (Settings → General) et, sous Accès public (Public Access), sélectionnez Guest users can see and interact with the site without logging in (les utilisateurs invités peuvent voir le site et interagir avec lui sans se connecter).
- Ouvrez chaque page du lien (entrée, écran de paiement, réussite, erreur), ouvrez les propriétés de la page et définissez l’accès à la page sur Public.
- Publiez le site.
Laissez à leur propre niveau d’accès les éventuelles pages de portail avec connexion du même site : rendre publiques ces quatre pages n’ouvre pas le reste du site.
Étape 5 — Tester en payeur anonyme
- Créez un lien de test pour un client de démonstration : Créer et envoyer un lien de paiement.
- Copiez le Link URL et ouvrez-le dans une fenêtre de navigation privée, sans être connecté à Salesforce.
- L’écran de paiement à votre image s’ouvre avec le montant verrouillé. Annulez sans payer.
- Modifiez un caractère de l’adresse et ouvrez-la de nouveau : la page affiche « Invalid request: Bad request Parameters. » Cela prouve que l’invité n’atteint rien d’autre qu’un lien actif.
- Révoquez l’ordre de test et rouvrez l’adresse d’origine : elle n’ouvre plus d’écran de paiement.
Symptômes et élément manquant
| Ce que voit le payeur | Ce qui manque généralement | Correction |
|---|---|---|
| Une page de connexion | L’accès public ou l’accès à la page | Étape 4 |
| Une erreur d’accès sur la page | L’accès aux objets ou aux classes Apex pour l’invité | Étape 2 |
| « Invalid request: Bad request Parameters. » sur tous les liens | La règle invité de Pay Order ou de Pay Customer | Étape 3 |
| La page s’ouvre mais sans compte de traitement ni marque | La règle invité de Pay Profile ou de Processing Account | Étape 3 |
Erreurs à éviter
| Erreur | Ce qui se passe | Correction |
|---|---|---|
| Règles de partage créées pour l’utilisateur invité du mauvais site | Les liens échouent toujours | Chaque site a son propre utilisateur invité : utilisez celui du site des liens |
| Donner à l’invité la modification ou la suppression | Des visiteurs anonymes pourraient modifier des enregistrements | N’accordez que ce que l’ensemble d’autorisations accorde |
| Attribuer REDA Pay - Community User à l’invité | Il accorde la modification sur les Pay Customers et les Pay Methods, que des visiteurs anonymes ne doivent pas avoir | Utilisez REDA Pay - Public Site User |
| Une règle Pay Order sans le critère Has Active Link | Tous les ordres deviennent lisibles par n’importe qui | Gardez le critère exactement comme ci-dessus |
| Tester en étant connecté à Salesforce | Votre propre session masque l’accès invité manquant | Testez dans une fenêtre privée |
Questions fréquentes
Ils ne peuvent lire que les ordres dont le lien est actif, et seulement s’ils connaissent l’adresse chiffrée que vous avez envoyée. Les numéros de carte et de compte ne sont jamais stockés dans Salesforce ; consultez Sécurité et données de carte.
Non. Les pages d’enregistrement de moyen fonctionnent avec le même utilisateur invité et le même accès ; consultez Demander ses coordonnées bancaires à un fournisseur.
Oui. Les pages publiques des liens et les pages de portail avec connexion peuvent coexister dans un même site ; configurez cet accès invité pour l’utilisateur invité du site et l’accès au portail pour ses utilisateurs connectés ; consultez Accès au portail : autorisations et partage pour les clients.
Pour aller plus loin
- Configurer le site public des liens de paiement : les pages et les paramètres du compte de traitement.
- Créer et envoyer un lien de paiement : votre premier lien.
- Dépannage des liens de paiement : messages et corrections.