Let customers pay in your portal

If your customers log in to an Experience Cloud site — a resident portal, an owner portal, a client portal — you can put the REDA Pay payment screen inside it. A logged-in customer pays, sets up recurring payments and saves cards and bank accounts, all against their own records, without your team touching a card number. This article sets that up.

How the portal flow works

A portal customer never picks a record: REDA Pay takes the logged-in user's Contact (or Account) as the parent record, finds or creates its Pay Customer, and opens the same screen staff use. The flow crosses four pages you create in Experience Builder:

The same four, with NewPayMethod, NewPayMethodRequest and NewPayMethodResult, let customers save a method without paying.

The portal's payment entry page as a logged-in customer: "Select Pay Profile" with the profile radio buttons and Cancel, cropped to the REDA Pay component

The entry page. A single active profile skips this step.

The portal payment screen as a logged-in customer: the processing account's branding, Card and Bank tabs, the customer's saved bank accounts, and the New Payment panel; no Back button

The payment screen inside the portal. Customers see their own saved methods.

Part 1 — Give portal users access

Portal access has four parts. Each is set up step by step, for both kinds of portal licence, in Portal access: permissions and sharing for customers; in short:

1. Object, class and metadata access. Assign REDA Pay - Community User to the portal users, or give the portal profile the same settings. It grants create and edit on Pay Customers and Pay Methods, read on Pay Orders, Pay Transactions, Pay Profiles, Processing Accounts and Fee Setups, the two Apex classes behind the screens, and read access to the REDA Pay Process Config and REDA Pay Setup custom metadata types.
2. Sharing set. Portal users see only records shared with them. A sharing set on Pay Order, Pay Customer and Pay Method, each matched User: Contact to the object's Contact field with Read/Write, gives each customer their own records: Setup → Digital Experiences → Settings → Sharing Sets.
3. Pay Profiles and Processing Accounts. Customers must read the active ones. For role-based licences (Customer Community Plus, Partner), create two criteria-based sharing rules, Is Active equals True, shared with All Customer Portal Users, Read Only. For high-volume licences (Customer Community, Customer Community Login), which sharing rules cannot reach, set the two objects' Default External Access to Public Read Only. Fee Setups follow their Processing Account automatically.
4. Site membership. The portal profile must be a member of the site.

The Sharing Set configuration screen with Pay Order, Pay Customer and Pay Method each mapped User: Contact to Contact with Read/Write access

The sharing set is what makes "my payments" mean the logged-in customer's payments.

Part 2 — Build the pages

In Experience Builder for the site:

1. Pages → New Page → Standard Page → Blank, named for example New Pay Order (note its API name, shown in the page properties — you will type it below). Drag NewPayOrder (under Custom Components) onto it and set:
   • Is Portal: ticked.
   • Portal Record Identifier: User-Contact (or User-Account if payments belong to the customer's company).
   • Portal Payment Page: the API name of the page in the next step.
   • Portal Success Page, Portal Error Page: the API names of the result pages.
   • Portal Return URL: where Cancel goes — the site's home, or your website.
   • Narrow the screen for this audience: for a resident portal, untick Allow Pay Method Type - Card if cards are not wanted, untick Enable Order Link (links are a staff tool), keep Enable Scheduling Order for autopay. See Component settings reference.
2. New Page named for example New Pay Order Request, with NewPayOrderRequest on it. No settings.
3. Two more pages, Payment Success and Payment Error, each with NewPayOrderResult; tick Is Success on the first only. Add your own text around the component — "Thank you", what happens next, a link back home.
4. Repeat 1–3 with NewPayMethod (setting Portal Method Input Page), NewPayMethodRequest and NewPayMethodResult if customers should save methods without paying.
5. Add the entry pages to the site's navigation menu (for example Make a Payment and Payment Methods).
6. Publish the site.

Page access: the pages should require login (the default for a page in a login-required site). Only the public payment-link site uses guest access — see Set up the public payment-link site.

Part 3 — Test as a customer

Open a test customer's Contact, use Log in to Experience as User, and walk the flow: choose a profile and account if asked, see your saved methods, enter an amount, press Pay, cancel the summary. Then test on a phone-sized window: the tiles and the payment panel stack and nothing scrolls sideways.

The portal payment screen at phone width, with the saved-method tiles stacked above the New Payment panel

The same page on a phone.

Check as the customer, not as an administrator: an administrator sees records a customer cannot, and a missing sharing rule only shows up for a real portal user.

Worked example

Meridian Properties' resident portal: residents pay rent and set up autopay by bank account; no cards, no links.

Mistakes to avoid

FAQ

Where to go next

• Portal access: permissions and sharing for customers
• Portal autopay: recurring payments by customers
• Brand the portal payment pages