Payment-link guest access: permissions and sharing

When a customer opens a payment link, they are not logged in. Salesforce treats them as the guest user of your public site: one shared, anonymous identity that every visitor of that site uses. Whatever the guest user can read, any visitor can read. So guest access is set up with care: the guest must be able to open the order behind a live link and pay it, and nothing else.

Three layers do that, and all three are needed:

This article sets up all three for the site that hosts your payment links. Building the pages and connecting the processing account are covered in Set up the public payment-link site.

Step 1 — Find the site's guest user

Each site has its own guest user and guest profile. Use the ones of the site that hosts the link pages.

1. Open Setup → Digital Experiences → All Sites and click Builder next to the site.
2. In Experience Builder, open Settings → General and, under Guest User Profile, click the profile's name. The guest profile opens in Setup.
3. On the profile, click View Users (Assigned Users in the enhanced profile interface): the single user listed is the site's guest user. Note its name; you will pick it when you create the sharing rules.

Step 2 — Give the guest access to the REDA Pay objects and screens

Choose one of two equivalent ways. Both give exactly the same access.

Option A — Assign the permission set (recommended). From the guest profile's list of users, click the guest user, scroll to Permission Set Assignments, click Edit Assignments, add REDA Pay - Public Site User and Save. The set is kept up to date by REDA Pay upgrades.

Option B — Put the same settings on the guest profile. If you prefer profiles, edit the guest profile and grant what the permission set contains:

In the enhanced profile interface these two sections are called Apex Class Access and Custom Metadata Types.

The guest gets no Edit, Delete, View All or Modify All on any REDA Pay object. Create is granted on exactly two objects: Pay Method, for the single-use card or bank account the payer enters, and Pay Transaction.

The permission set also enables rpay.PayloadCallback, the class that receives Payload's webhook messages. A site that serves only payment links does not use it. If you receive webhooks on a separate site, that site's guest needs only rpay.PayloadCallback — see Set up webhooks.

The Object Settings of the REDA Pay - Public Site User permission set, listing the REDA Pay objects: Read on Pay Orders, Pay Customers, Pay Profiles, Processing Accounts and Fee Setups, Read and Create on Pay Methods and Pay Transactions

Everything an anonymous payer can do, in one table. Note what is missing: no Edit, no Delete.

Step 3 — Create the four guest sharing rules

Object access says the guest may read Pay Orders; the sharing rules say which ones. REDA Pay's records are private to external users, so without these rules every link fails. In Setup → Sharing Settings, under each object's Sharing Rules list click New and create:

For the Pay Customer rule, choose the operator not equal to and leave the value empty. REDA Pay fills Order Link Expiration Date Time with the expiry of the customer's live link and clears it when their last live link ends, so the rule matches only customers who have a live link.

Fee Setups and Pay Transactions need no rule: they follow their Processing Account and Pay Order.

The guest sharing rules in Sharing Settings for Pay Order (Has Active Link equals True), Pay Customer (Order Link Expiration Date Time not equal to blank), Pay Profile and Processing Account (Is Active equals True), each shared with the public site's guest user, Read Only

The four rules. Together they open exactly what a live link needs.

What the guest can and cannot reach

Has Active Link is ticked on a Link order while its link can be used. REDA Pay turns it off when the order is paid, when someone revokes it, and about a minute after the link expires. The order then drops out of the guest's view by itself, with no admin action. In practice:

The order identifier in a Link URL is encrypted with your org's key — see Generate the encryption key.

Step 4 — Make the link pages public

1. In Experience Builder, open Settings → General and, under Public Access, select Guest users can see and interact with the site without logging in.
2. Open each link page (entry, payment screen, success, error), click the page's Page Properties, and set Page Access to Public.
3. Publish the site.

Keep any logged-in portal pages on the same site at their own access level: making these four pages public does not open the rest of the site.

Step 5 — Test as an anonymous payer

1. Create a test link for a demo customer: Create and send a payment link.
2. Copy the Link URL and open it in a private browser window, where you are not logged in to Salesforce.
3. The branded payment screen opens with the amount locked. Cancel without paying.
4. Change one character of the address and open it again: the page shows "Invalid request: Bad request Parameters." This proves the guest reaches nothing but a live link.
5. Revoke the test order and open the original address again: it no longer opens a payment screen.

Symptoms and what is missing

Mistakes to avoid

FAQ

Where to go next

• Set up the public payment-link site — the pages and the processing account settings.
• Create and send a payment link — your first link.
• Payment link troubleshooting — messages and fixes.