REDA Pay
Winter 2026 · v1.57000
5 Nov 2026
Payload API v2, secure card entry on every site, and set-up guides for every channel
REDA Pay 1.57000 is a main release. It brings together everything shipped since main release 1.56: the patches 1.56001, 1.56002, 1.56003 and 1.56004 (3–4 November 2026). An org that already runs 1.56004 has every change on this page. This page tells you how to install REDA Pay for the first time, how to upgrade an org that runs 1.56 or one of the patches, which steps the upgrade cannot do for you, and what changed, in the words your team will use.
Version facts. Package: REDA Pay · Version number: 1.57000 · Version name: Winter 2026.
Upgrade now — production · Install in sandbox
Installation links. Version 1.57000 was released on 5 November 2026 and needs no installation password; Salesforce sign-in, package licensing and permissions still apply. The links identify the package version, not a particular organisation: your Salesforce sign-in decides where it installs. To see which version an org runs today: Setup → Installed Packages → REDA Pay → Version Number.
Prefer that we do it? The REDA team installs, upgrades and sets up REDA Pay for you. Email sales@reda.one to book a session.
On this page
- At a glance: who needs to do what
- Install REDA Pay for the first time
- After installing: set up each payment channel
- Upgrade from 1.56 or a patch
- After upgrading: steps the upgrade cannot do for you
- Check that everything works
- What's new in this release
- Fixed in this release
- New fields, actions and components, and who can see them
At a glance: who needs to do what
| Your situation | What to do | Where |
|---|---|---|
| REDA Pay is not installed yet | Install the package, then follow the set-up roadmap: encryption key, Pay Profile and API key, processing accounts, permission sets, webhooks, and the channels you use (staff screens, customer portal, public payment links, scheduled payments). | Install and After installing |
| Your org runs 1.56 | Upgrade, then complete every step in After upgrading: the new Pay Profile fields and action on your layouts, access for your own profiles or cloned permission sets, the webhook site's guest access, the value-set values, and a republish of each Experience Cloud site that hosts REDA Pay screens. | Upgrade |
| Your org runs 1.56001, 1.56002 or 1.56003 | Upgrade, then republish each Experience Cloud site that hosts the v2 screens and check the other steps in After upgrading — most were already done when the patch was installed. | Upgrade |
| Your org runs 1.56004 | It already has every change on this page. If you have not completed After upgrading, do it now; no republish is needed. | After upgrading |
| You want to use Payload's v2 API (secure card entry, screens on an LWR site, signed webhooks) | Set Payload API Version to v2 on the Pay Profile and run Setup Webhooks. Nothing else moves; the switch can be reversed. | Choose the Payload API version |
| Your customer portal or public site is an LWR site | Place the v2 components on its pages (the classic components do not run on LWR). Page names, guest access and sharing are set out step by step. | Portal · Public links |
| Your users work in Spanish, French or Portuguese (Brazil) | Nothing: after the upgrade REDA Pay appears in the user's language. Check the language on the user record if it still shows English. | What's new |
Install REDA Pay for the first time
You need a Salesforce administrator (the System Administrator profile, or a profile with Download AppExchange Packages and Customize Application) and a Payload account whose dashboard you can sign in to. Install in a sandbox first if you have one.
- Open the installation link for the environment you are installing into (production or sandbox). If you do not have it, ask your REDA account executive or support@reda.one.
- Sign in as the administrator of that org. If you have several orgs, check the org name at the top of the page before you continue.
- On the installation page, confirm the package name REDA Pay and the version number against this page.
- Choose Install for Admins Only. Access for everyone else is granted afterwards through the REDA Pay permission sets, not through this choice.
- Click Install. If Salesforce says the installation continues in the background, wait for its email before you go on.
- Open Setup → Installed Packages and confirm that REDA Pay is listed with this version number.
Installing is the first of twelve steps. The rest are in the next section.
After installing: set up each payment channel
Follow Setup roadmap: from install to your first payment from step 1. In short:
| Step | What it does | Guide |
|---|---|---|
| 1. Permission sets | Give the administrator REDA Pay - Admin User; later, give staff REDA Pay - User and so on. | Who can do what |
| 2. Encryption key | Generate the key that encrypts your Payload API key and identifiers. Once per org. | Generate the encryption key |
| 3. Pay Profile and API key | Create the profile, store the Payload API key with Update API Token, and choose Payload API Version v1 or v2. | Create a Pay Profile · Choose the API version |
| 4. Processing accounts | Sync your merchant accounts from Payload, activate the profile, configure each account (transfer types, methods, branding, fees, link settings). | Sync and activate · Configure |
| 5. Webhooks | A public Salesforce site that Payload calls, its guest user's access, and Setup Webhooks. On v2, a signing secret. | Set up webhooks |
| 6. Staff payments | Put the payment screen on Lead, Contact and Account pages; take a test payment. | Add REDA Pay to record pages · Take a payment |
| 7. Customer portal | Pages, component settings, permission set, sharing set and default external access for a logged-in portal — Aura or LWR. | Let customers pay in your portal · Portal access |
| 8. Public payment links | Public pages, exact page API names, the guest user's permission set and Apex access, the four guest sharing rules (with the portal-owned-records option), the public-API preference, and the processing account's link settings. | Set up the public site · Guest access |
| 9. Scheduled payments and recovery | Schedule the daily job and turn on failed-payment recovery. | Daily job · Recovery |
Upgrade from 1.56 or a patch
- Note which version the org runs: Setup → Installed Packages → REDA Pay → Version Number.
- Upgrade a sandbox first. Open the installation link while signed in to the sandbox, keep Install for Admins Only, click Upgrade, and wait for the confirmation email.
- Complete After upgrading in the sandbox, run the checks in Check that everything works, then repeat both in production.
Your data, configuration, encryption key, webhooks and scheduled jobs survive the upgrade. The full procedure, with what survives and what to re-check, is in Upgrading REDA Pay.
After upgrading: steps the upgrade cannot do for you
A managed-package upgrade installs new components but never changes a page layout you use, never grants access to your own profiles or permission sets, never adds a value to a value set your org already has, and never republishes an Experience Cloud site. Do these by hand, in this order. Each row says who it applies to.
| Step | Applies to | What to do |
|---|---|---|
| 1. Add the new Pay Profile fields and action to your layouts | Every org upgrading from 1.56 | On each Pay Profile page layout in use, add the fields Payload API Version, Webhook Signing Secret and Payment Appearance (section Information for the first, API Setup for the second and External Labels for the third, as on the packaged layout) and the action Update Webhook Secret. Click-by-click steps: Upgrading REDA Pay. |
| 2. Grant the new classes and page to your own profiles or cloned permission sets | Orgs that do not assign the packaged REDA Pay permission sets | Payers (staff, portal users, the public site's guest user): Apex classes rpay.PayloadV2SecureCapture and rpay.PayloadSecureFieldsController, Visualforce page rpay.PayloadSecureFields. Administrators: class rpay.UpdateWebhookSecretController and edit access to the three new fields. The packaged permission sets already carry all of this. Steps: Upgrading REDA Pay. |
| 3. Give the webhook site's guest user the v2 callback class | Every org that will use Payload API v2 | On the webhook site's guest profile, enable rpay.PayloadCallbackV2 next to rpay.PayloadCallback. Then set the profile to v2 and run Setup Webhooks. Steps: Set up webhooks. |
| 4. Republish every Experience Cloud site that hosts REDA Pay screens | Every org upgrading from 1.56001, 1.56002 or 1.56003, and every org that places the v2 components | An LWR site keeps serving the previous version's component code until you publish it again: open the site in Experience Builder and click Publish. Compare the site's unpublished changes first, because publishing makes them live too. Publish sites one at a time. |
| 5. Add the value-set values your org lacks | Orgs upgrading from 1.56 that pay or collect in Brazilian reais or Colombian pesos, or hold Colombian addresses | The values BRL and COP (Account Currency) and CO (Country) were added after 1.56 and are not added to an existing org. Add them in Setup → Picklist Value Sets, typing exactly those API names. Steps: Upgrading REDA Pay. |
| 6. Check your own copies of REDA Pay record pages | Orgs that cloned a REDA Pay Lightning record page | The packaged record pages now take their tab titles from translatable labels. A page you cloned keeps the titles you typed; retype them with the labels if you want them translated. |
| 7. Decide on Create Missing Transactions | All orgs | New installs get CREATE_MISSING_TRANSACTIONS = TRUE; an upgrade keeps your value. Read Org switches and error messages and set it deliberately. |
Check that everything works
- Setup → Installed Packages shows REDA Pay 1.57000.
- Open a Pay Profile: the three new fields and the Update Webhook Secret action are on the page.
- As a staff user who holds only REDA Pay - User, take a small test payment from a Lead against Payload's test environment. On a v2 profile the card and bank details are entered in the secure form and a progress message appears while the payment runs.
- If you use a portal, log in as a test customer (Log in to Experience as User on their Contact) and reach the payment screen.
- If you use payment links, create a test link and open it in a private browser window: the payment screen opens, and the review summary shows the order number and amounts.
- Open the Pay Profile's Webhook Setup tab: ten rows on v1, eleven on v2, each with a Webhook Id.
- Set a test user's language to Spanish, French or Portuguese (Brazil) and open a Pay Order: tabs, fields and buttons appear in that language.
- Open REDA Pay Logs: no new Attention Needed entries.
What's new in this release
| Change | What your team will notice | Setup or review |
|---|---|---|
| 1. Payload API v2, chosen per Pay Profile | A new field Payload API Version on the Pay Profile. Blank or v1 keeps everything exactly as before. v2 switches that profile to Payload's current API: the same buttons, schedulers and reports, with the new screens below. v1 and v2 share records, identifiers and the API key, so the switch moves no data and can be reversed. | Place the field on your layouts; set it to v2 when you are ready; run Setup Webhooks. Choose the Payload API version |
| 2. Card and bank details entered in Payload's secure form | On a v2 profile the card number, security code and account number are typed into a form Payload serves inside the payment screen. They never pass through Salesforce. If a browser extension blocks it, the screen says so after ten seconds. | Nothing to configure. If your own profiles or permission sets are in use, grant the page and classes in step 2. |
| 3. New payment and payment-method screens, for every kind of site | Six components — REDA Pay - New Pay Order (v2), Pay Order Request (v2), Pay Order Result (v2), New Pay Method (v2), Pay Method Request (v2), Pay Method Result (v2) — with the same settings, URL parameters, validations and button rules as the classic screens, in a phone-first layout with method tiles and a result card. They can be placed on LWR sites, which the classic screens cannot. Inside Salesforce, the classic payment button opens the v2 screen by itself when the profile is on v2. | Portals and public sites on v2: place the v2 components and set the page names exactly. Portal · Public links · Component settings |
| 4. Signed webhooks and the Update Webhook Secret action | On v2, Payload signs every webhook delivery with a secret you set through Update Webhook Secret on the Pay Profile, and REDA Pay checks the signature. Setup Webhooks on a v2 profile removes only that profile's own webhooks and registers eleven (the ten of v1, with credit replaced by payout and withdraw added). | Add the action to your layouts; enable rpay.PayloadCallbackV2 for the webhook site's guest user. Set up webhooks |
| 5. Payment Appearance | The v2 screens follow your Salesforce or site theme by default. A new Payment Appearance field on the Pay Profile, and Brand Colour, Text Colour, Background Colour and Font Family settings on the v2 components, let you set your own colours and font. | Optional. Brand the payment screen |
| 6. Progress messages | While a v2 payment runs, the screen shows what it is doing — Getting your payment ready…, Securing your payment details…, Preparing your payment…, Processing your payment… This can take a few seconds. Please keep this window open. — instead of a spinner. The method screens do the same. | Nothing. |
| 7. Spanish, French and Portuguese (Brazil) | Every label, field, help text, picklist value, layout section, validation message, tab and button of REDA Pay is translated. A user whose language is one of these sees REDA Pay in it. | Check the user's Language on the user record. Translations apply to the packaged pages; a record page you cloned keeps your titles (step 6). |
| 8. Create Link always offered | The Create Link button no longer disappears when a processing account is not set up for links. Pressing it then shows: "Payment links are not set up for this processing account: its Link Site Public URL is empty. Ask your administrator to fill it in." | Fill Link Site Public URL on the accounts that issue links. Set up the public site |
| 9. Refund and Void explain settlement | On a v2 profile, Refund on a payment that has not settled closes with: "This payment has not settled yet, so it cannot be refunded. Void it instead, or refund it once it has settled (usually by the end of the business day)." Void on a settled payment says: "This payment has already settled, so it can no longer be voided. Refund it instead." (v1 and v2). | Tell your refunds desk. Void or refund a payment |
| 10. All screen text from translatable labels | Every message, button and tab title on the classic and v2 screens, the record pages and the REDA Pay flows comes from a label. Technical tags such as "[Transfer Type]" no longer appear in messages, and the flow screens no longer show an internal name as their header. | Nothing. |
| 11. Plainer flow names | The packaged flows carry plain names and descriptions, so an administrator opening Setup → Flows sees what each one does. | If you override a REDA Pay flow, compare it with the new version. |
| 12. Create Missing Transactions on by default for new installs | A fresh install reconciles deposits even when a Pay Transaction is missing in Salesforce, by creating it. Upgrades keep your current setting. | Step 7. |
Fixed in this release
| Fix | What was wrong | Now |
|---|---|---|
| A customer's other links stay open | When one of a customer's payment links was paid, revoked or expired, the customer's other open links could stop opening ("Invalid request: Bad request Parameters."). | The other links keep working. A customer affected before the upgrade is repaired the next time one of their open link orders is saved. |
| Secure form on LWR sites | On an LWR site the v2 card and bank form could not load (first shipped in 1.56001, fixed in 1.56002). | The form loads on LWR and Aura sites and inside Salesforce. |
| Review summary on LWR sites | The order number and amounts in the v2 review summary wrapped one character per line on an LWR site. | They read normally. |
| Result pages | The v2 result pages showed the classic message box instead of the result card the payment screen shows. | They show the same result card. |
New fields, actions and components, and who can see them
All three new fields are on Pay Profile. The packaged permission sets that read Pay Profile read them; REDA Pay - Admin User edits them. If you use your own profiles or permission sets, grant the access yourself (After upgrading, step 2).
| Field or action | Where on the packaged layout | Who enters it | What it is for |
|---|---|---|---|
| Payload API Version (picklist: v1, v2) | Information section | Administrator | Blank or v1: as before. v2: this profile uses Payload's v2 API. Run Setup Webhooks after changing it. |
| Webhook Signing Secret | API Setup section | Nobody types it: set through the Update Webhook Secret action | Up to 64 characters that Payload uses to sign v2 webhook deliveries. Blank: deliveries are accepted without a signature check. |
| Payment Appearance | External Labels section | Administrator, optional | Colours and font for the v2 screens, for example {"brandColor":"#006B63"}. Blank: the host theme. |
| Update Webhook Secret (action) | Pay Profile actions, beside Update API Token | Administrator | Opens a dialog to set the signing secret; then run Setup Webhooks. |
| Six v2 components | Lightning App Builder and Experience Builder, under Custom - Managed, named REDA Pay - … (v2) | Administrator places them | The v2 payment and payment-method screens for pages and sites. Component settings reference |
No new object, tab, permission set or record page is added. The value-set values BRL, COP and CO are new to orgs upgrading from 1.56 (step 5).