Security and card data
Taking payments inside Salesforce raises the questions every administrator and auditor asks: where do card numbers go, what is stored, who can see what, and what do we have to do ourselves? This article answers them for REDA Pay 1.56 as it is built, and lists the responsibilities that stay with you.
What is never stored in Salesforce
| Data | Handling |
|---|---|
| Full card number (PAN) | Never written to any Salesforce record. After registration, only the card's brand, type, expiry month and year, cardholder name and postal code are kept, and the method's name shows the last four digits |
| Card security code (CVV/CVC) | Never stored |
| Full bank account number | Never stored. The routing number, account type, class, currency, holder name and last digits (in the name) are kept |
What is stored encrypted
REDA Pay encrypts these with a key that is generated once in your org and never displayed — see Generate the encryption key:
- the Payload API token on the Pay Profile;
- Payload's identifiers for your organisation (Profile Id), each merchant account, each customer and each saved payment method (the token Payload uses in place of the card or account);
- the identifier inside every payment link.
A person who can read these records sees ciphertext. Payload's transaction identifier is stored in clear, because it is a reference number used in support conversations and contains no secret.
How card and bank details travel
On the payment and save-a-method screens, the payer types the card or bank details into REDA Pay's form. REDA Pay sends them to Payload over an encrypted connection, Payload returns a token, and REDA Pay keeps the token and the descriptive details listed above. The details pass through your Salesforce org on the way to Payload; they are not written to a record, a log or a file.
What this means for you:
- Treat your Salesforce org as part of the environment that handles card data, and keep it secure: strong authentication for every user, least-privilege access, no debug logging of payment screens in production.
- Discuss with Payload and your assessor what this architecture means for your PCI DSS scope and the questionnaire you complete. REDA Pay's design keeps card data out of your database; it does not by itself make you "out of scope".
- Payers can also be kept away from your staff entirely by using payment links and the portal, so staff never see or type card numbers.
Sessions, links and guests
| Mechanism | What it protects |
|---|---|
| Encrypted payment session | Each payment screen runs from an encrypted token created when it opens, carrying who pays, which profile and account. It expires after the account's session length (15 minutes by default), so a copied or bookmarked address cannot be reused later |
| Encrypted link identifier | A payment link carries the order's identifier encrypted; the address reveals nothing about the amount or the customer |
| Guest access by rule | The public site's guest user can read a Pay Order only while Has Active Link is true, and a Pay Customer only while it has an active link, through sharing rules you create. When a link is paid, expires or is revoked, the records drop out of the guest's view |
| Single-use guest methods | A card or account entered on a link is saved with Keep Active off |
| Duplicate protection | A second press of the pay button in one session is refused |
| Geolocation and IP capture | Optional recording, and enforcement, of where a payment was made from — see Controls |
Status updates from Payload
Payload reports events to a public address in your org. The message is used only to learn which transaction changed; REDA Pay then reads the transaction from Payload over the authenticated API and stores that. Nothing in an incoming message is written to a record directly. See Set up webhooks.
Who can do what
Access is granted by seven permission sets, from read-only to administrator, and by two switches on the User record for receipts and disbursements — see Who can do what. Records are Public Read Only inside the org for most REDA Pay objects, so any licensed user with object access can read payment records; tighten with your own sharing settings if your policy requires. Field history tracking is on for most fields, which gives you an audit trail of changes.
Your checklist before go-live
| Item | Why |
|---|---|
| ERROR_STACK_TRACE set to FALSE | Technical detail must not reach payers — see Org switches |
| Permission sets assigned by role, Enable Disbursements only where needed | Least privilege |
| Portal sharing set and guest sharing rules exactly as documented | Customers see only their own records; guests only live links |
Logo and footer served over https | No mixed content on the payment page |
| Multi-factor authentication for staff who take payments | Salesforce best practice |
| Debug logs off for payment users in production | Logs can capture request data |
| A named owner for the REDA Pay Logs Attention Needed view | Failures are seen |
| Payload API keys stored only through Update API Token, never in fields, documents or chat | The key is the account |
| Test cards and the Payload test environment used in sandboxes | Real cards never in test |
FAQ
REDA Pay is an application that runs in your Salesforce org; the payment processor is Payload. Ask Payload for its attestation and ask your assessor how an integration that passes card data through your org affects your own scope. This article tells you exactly what the application does so that conversation is well informed.
Yes: the Pay Order's owner and created-by, Processed User Type, and, when captured, IP Address, Geo Latitude and Geo Longitude.
It cannot be exported or regenerated, and it lives in your org. Sandboxes have their own; production's stays with production.