Portal access: permissions and sharing for customers

A customer who logs in to your Experience Cloud portal can only pay if Salesforce lets them open the REDA Pay screens and read the records behind them. Four things must be in place, and each one answers a different question:

Miss any one of them and the customer sees an empty step, an error or a login loop. This article sets up all four and then tests them as a real customer. The pages themselves are covered in Let customers pay in your portal.

Step 1 — Find out which licence your portal users have

Salesforce shares records with portal users in two different ways depending on the licence, so check it first. Open Setup → Users → Users, click a portal user, click their Profile, and read User License.

If your portal mixes licences, set up both routes.

Step 2 — Give portal users 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). Assign REDA Pay - Community User to every portal user who pays: Setup → Permission Sets → REDA Pay - Community User → Manage Assignments → Add Assignment. For a large portal, add it to a permission set group that your portal users already receive, or assign it in bulk with your usual user-provisioning process. The set is kept up to date by REDA Pay upgrades, which is why it is the recommended option.

Option B — Put the same settings on the portal profile. Some organisations manage portal access only through profiles. Then edit each portal profile that pays and give it what the permission set contains:

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

The packaged permission set grants no Delete, View All or Modify All on any REDA Pay object; do not add them on the profile either.

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

What the permission set grants. If you use profiles instead, copy exactly this.

Step 3 — Create the sharing set: each customer sees only their own records

Object access says a customer may read Pay Orders; it does not say which. Without a sharing set they see none, because REDA Pay's records are private to external users by default. The sharing set grants access to the records linked to the customer's own Contact.

1. Open Setup → Digital Experiences → Settings, scroll to Sharing Sets and click New.
2. Enter a Label, for example REDA Pay - Customer Records.
3. Under Select Profiles, add every portal profile whose users pay.
4. Under Configure Access, add Pay Customer, Pay Method and Pay Order. For each, click Set Up and choose:
   • User: Contact
   • Target object field: Contact
   • Access Level: Read/Write
5. Save.

Pay Transactions and Fee Setups need no entry: they inherit access from their Pay Order and Processing Account.

If your portal pages identify the customer by Account (the Portal Record Identifier setting User-Account — see Let customers pay in your portal), REDA Pay links the records to the Account, so map User: Account to each object's Account field instead. Every user of that company then sees the company's payments.

A sharing set with Pay Customer, Pay Method and Pay Order, each matched User:Contact to the object's Contact field with Read/Write access

The sharing set is what turns "Pay Orders" into "my Pay Orders".

Step 4 — Let customers read the active Pay Profiles and Processing Accounts

The payment screen reads the Pay Profile and Processing Account to know which methods are allowed, which fees apply and how to brand the page. These records belong to no customer, so the sharing set cannot cover them.

Route A — Role-based licences (Customer Community Plus, Partner): two sharing rules. In Setup → Sharing Settings, under Pay Profile Sharing Rules click New, and create:

Then the same under Processing Account Sharing Rules: Is Active equals True, shared with All Customer Portal Users, Read Only.

Route B — High-volume licences (Customer Community, Customer Community Login): default external access. Sharing rules cannot include high-volume users, so open the two objects to external users instead. In Setup → Sharing Settings, click Edit under Organization-Wide Defaults (some orgs label this section Default Sharing Settings) and set Default External Access to Public Read Only for Pay Profile and Processing Account. Leave Pay Order, Pay Customer and Pay Method Private: the sharing set handles those.

With route B, external users can read every Pay Profile and Processing Account record, active or not. The screens offer only active ones, and the identifiers on these records are encrypted; card and bank details are never stored on them.

The Pay Profile Sharing Rules list in Sharing Settings with a criteria rule "Is Active equals True" shared with All Customer Portal Users, Read Only

Route A: role-based portal users read active Pay Profiles through a sharing rule.

The default sharing settings (Organization-Wide Defaults) rows for the REDA Pay objects, showing Default Internal Access and Default External Access for each

Route B changes the Default External Access column for Pay Profile and Processing Account only.

Step 5 — Make sure the profile is a member of the site

Users can only log in to a site their profile belongs to. In Setup → Digital Experiences → All Sites, click Workspaces next to your site, open Administration → Members, and check that each portal profile from Step 3 is in Selected Profiles. Add it if not, and Save.

Step 6 — Test as a real customer

An administrator sees every record, so testing as yourself proves nothing. Test as a portal user:

1. Open a test customer's Contact and choose Log in to Experience as User.
2. Open the payment page. If several active Pay Profiles exist, "Select Pay Profile" lists them; choose one.
3. The payment screen opens with the account's branding and the customer's saved methods.
4. Enter an amount, press Pay, and cancel the summary.
5. Open the customer's payment history page if you have one: only that customer's Pay Orders appear.

Symptoms and what is missing

Mistakes to avoid

FAQ

Where to go next

• Let customers pay in your portal — build the payment pages.
• Portal autopay: recurring payments by customers — what customers can schedule.
• Who can do what: permission sets — all seven REDA Pay permission sets.