Security
Your donor data stays in your org.
Pledgivo is a managed package that runs inside your Salesforce org. This page sets out where its data lives, how card payments are handled, and who can see what, with a link to the documentation behind each part.
Where your data lives.
Donors are Contacts or Person Accounts, gifts are Opportunities and fundraisers are Campaigns: standard records in your own org. The package's own records, such as recurring gifts and payment logs, are stored there too.
The package sends nothing to CloudAlgo. It has no telemetry, no usage analytics and no call home. Its links to this documentation carry nothing about your org. The link to manage your subscription passes your org ID, and only when a staff member clicks it.
Stripe receives what it needs to take a payment: the card, the amount, and the donor's name and email. It goes to your own Stripe account, which CloudAlgo cannot see.
Card data never reaches Salesforce.
The card fields on a donation page are Stripe's own, loaded by Stripe.js from Stripe's servers. The donor's card details go from their browser straight to Stripe. What reaches your org is Stripe's reference to the payment and a summary of the card, such as its brand, last four digits and expiry date, never the full card number or security code.
Your Stripe keys, which the setup guide has you create as restricted keys, are stored in Named Credentials you build in Setup. The package ships no key and stores none in a field: a payment account record holds only the names of those credentials.
Stripe never calls into your org. After a payment, your org asks Stripe what happened, so there is no webhook address to protect and no signing secret to keep.
Your permissions apply.
Staff screens work within the signed-in person's own access. The code behind them runs with sharing, its queries check object and field permissions by default, and its saves follow your record sharing. Where the package has to work outside one person's access, such as a background job that processes every gift, the reason is written next to that line of code.
Four permission sets ship with the package
- Fundraising Admin
- Full access to the fundraising objects and to the package's settings. Carries all three custom permissions below.
- Fundraising User
- For program staff: read and create donations. No settings, and none of the three custom permissions.
- Fundraising Read Only
- View only, for board members and executive staff.
- Fundraising Guest Donor
- For your public site's guest user. What it allows is set out in the next section.
Three custom permissions gate the sensitive actions
- Process Refunds
- Refund a donation, in full or in part, back through Stripe. Checked before any refund request is sent, because a refund moves real money.
- Manage Recurring Gifts
- Pause, resume, skip, retry or change a donor's live recurring gift from its record page, because these change what a donor is billed and when.
- Manage Fundraising Settings
- Change the org-wide settings: general settings, scheduled jobs, feature detection, reset to defaults and the public site. Without it, every settings save is refused.
Public pages get the least they need.
Your donation and event pages run as your site's guest user, with the Fundraising Guest Donor permission set. It can read the page designs, campaign updates, funds, templates and payment settings that public pages use, and create the records that a donation, a saved card or a donor's request starts from. Its permission set grants no edit or delete on any object. The few updates a public page needs, such as marking the donor's own staging record submitted or reserving event seats, are made by named package code that states its reason at that line.
A donation is first saved as a staging record. A background job in your org then creates the Contact and the Opportunity from it.
When something unexpected goes wrong on a public page, the visitor sees one generic message; the package's own plain-language messages, such as a ticket tier that is no longer available, are shown as written. The details are written to a log in your org, never to the page.
No component loads code or styles from another site. The one exception is Stripe.js, which Stripe requires to be loaded from its own servers, and which only the package's two Stripe payment pages load.
Checked by scanners, not just by us.
Salesforce Code Analyzer runs on every change to the package. The Checkmarx source scan in Salesforce's Partner Security Portal has been run on the package's code as well.
Every security finding from either scanner is fixed or has a written answer explaining why it is not a vulnerability. Both sets of answers are published, in the false-positive template Salesforce gives partners.
Review status.
Pledgivo is in AppExchange security review.
Ask us what this page does not answer.
Questions about data, permissions or the scans are read and answered by the team that builds Pledgivo.