Taking online donations in Salesforce

Salesforce's fundraising products are built to record gifts. In Nonprofit Cloud, now Agentforce Nonprofit, single and batch Gift Entry lets staff enter one-time gifts and commitment installments, and processing an entry or a gift batch creates or updates the gift transaction that tracks the payment. Gift commitments track gifts promised but not paid in full at the start, such as a monthly gift or a pledge. Gift entries are available only when the Fundraising Access licence is enabled. The Nonprofit Success Pack has its own Gift Entry for single gifts and batches.

Recording a gift is a different job from taking one. Salesforce's own payments products, the Elevate family, which included Giving Pages and recurring donation processing, were retired on 11 February 2025, and Salesforce now recommends partner solutions. Its Trailhead module describes the same arrangement: an independent software vendor that handles payment processing and online donations can send payment information to Fundraising as a gift transaction record.

So Salesforce can hold your donations, and something else has to take them: a page a donor can pay on, a payment processor, and a way for the result to reach your records. The three options below differ in where that something lives and who looks after it.

Many online giving tools for nonprofits are platforms of their own. Donors give on the platform's pages, the platform takes the payment, and it keeps its own record of each donor. An integration then copies donors and gifts into Salesforce, as they happen or on a schedule, depending on the vendor.

You get a finished donation page, payment handling and receipts without building anything, and the vendor runs and secures the platform. Some offer features the other two routes may not, such as peer-to-peer fundraising pages.

What you take on

• Two copies of every donor. The platform's record and Salesforce's record can drift apart. When they disagree, someone has to decide which one is right.
• The sync itself. Field mappings, failed records and the delay between a gift and its arrival in Salesforce all depend on the integration, and someone has to watch it.
• Duplicate donors. If the integration matches people differently from the way your team does, the same donor can arrive twice and need merging.
• Fees in more than one place. Depending on the vendor: a share of each donation or a subscription, card processing, and sometimes a separate charge for the Salesforce connection.
• Whose payment account. Ask whether gifts are processed through a payment account your organization owns, or through one the platform controls, and what happens to it if you leave.

A good fit when Salesforce is not your main record of donors, or when you need a feature that only a platform offers.

Named platforms side by side, from each vendor's own pages

Salesforce has the parts. An Experience Cloud site can host public pages for visitors who are not signed in, Apex can run your own logic, and a processor such as Stripe takes the payment. A developer can join them into a donation form that writes straight to your records, shaped exactly as your team wants.

What you take on

• Card data and PCI scope. If card details pass through your own pages or code, your PCI obligations grow: Stripe notes that a business handling card data directly may need to meet more than 300 security controls. Stripe.js and Elements avoid that by hosting every card input in a frame served from Stripe's domain, so card details never touch your servers, and Stripe's PCI guide lists an Elements or Checkout integration under SAQ A. Stripe.js has to be loaded from js.stripe.com, not bundled or hosted yourself. What comes back, such as the card brand, last four digits and expiry date, is outside PCI scope and can be stored. PCI compliance is still shared, and you attest to it every year.
• Guest-user security. Donors are not signed in, so your page runs as the site's guest user. Salesforce's guest user guidance is strict: guest users can be granted read and create permissions on objects, never update or delete; they can be given read access to records only through guest sharing rules, which open the matching records to anyone; and Apex a guest can call should run with sharing. Anything more a donation needs, such as finding the donor's existing Contact, has to be done by your own code working beyond the guest's access, which Salesforce asks you to keep to a minimum.
• Retries and double charges. A dropped connection between Salesforce and Stripe can leave you unsure whether a charge went through. Stripe's idempotency keys let you repeat a request without charging twice, but your code has to send them. Monthly gifts need a schedule and a plan for declined renewals: Stripe Billing can retry failed subscription payments, or your own code can, and either way the result has to reach your records.
• Receipts and thank-yous. Stripe can email a receipt automatically for successful payments, with your branding and business details on it. A thank-you in your own words, or a year-end giving summary, comes from your own templates and your own records.
• Keeping it running. The code is yours to maintain as Salesforce and Stripe change, after the person who wrote it has moved on.

A good fit when you have Salesforce developers on staff, want full control of the form and the data, and can keep them on it.

The third route is a package installed into your own Salesforce org. The donation pages, the payment step and the records are parts of one app, kept up to date by its publisher. A gift is written to your records by code running in your org, so there is no second donor database and no sync to watch.

What changes

• One copy of every donor. Donors and gifts are your own records from the start, in your reports and dashboards with everything else.
• The publisher carries the build work. The card frame, guest-user access, retries and receipts from Option 2 are the publisher's job. Ask any publisher how they handle each one, and ask to see it in writing.
• You still need an admin. Someone installs the package, connects the payment processor and sets up the public site. The app only suits organizations that keep their donors in Salesforce.
• You depend on the publisher. As with a platform, you rely on them to keep the app working through Salesforce's releases and their processor's changes.

One example: Pledgivo

Pledgivo, made by CloudAlgo, runs donation pages, recurring giving, campaigns and ticketed events inside your org, with card payments through your own Stripe account, where Stripe charges its own processing fee. Donors are matched by email to an existing Contact or Person Account, and the card is charged when they give; the Opportunity is created by a job in your org within five minutes at the default setting. It costs $49 per fundraising admin a month, with a three-licence minimum, and never takes a percentage of what you raise. It supports organizations in the US and the UK, and it does not offer peer-to-peer fundraising pages yet.

Pledgivo is in AppExchange security review.

How Pledgivo works Pricing Security

1. Where does the donor record live?

   If the main record is outside Salesforce, ask which copy wins when the two disagree, and who fixes it.

   Pledgivo: in your org, as Contacts or Person Accounts, with each gift an Opportunity.

2. What does each gift cost in total?

   Add the platform's share or subscription, card processing and any charge for the Salesforce connection, and work it out at your yearly giving, not per gift.

   Pledgivo: $49 per fundraising admin a month, with a three-licence minimum. No percentage of donations; Stripe charges its own rate on your account.

3. How long until a gift is in Salesforce, and what happens when that fails?

   Ask how long the delay is, where a failed record shows up, and who is told.

   Pledgivo: within five minutes at the default setting. A gift that has not arrived is shown on the package's Donation Monitor tab.

4. How are returning donors matched?

   A loose matching rule creates duplicates that someone has to merge; a strict one can attach a gift to the wrong person.

   Pledgivo: by email, to the existing Contact or Person Account.

5. Does it work with Person Accounts and NPSP?

   Person Accounts store a person as one record that combines account and contact fields, and not every tool supports them. If you use the Nonprofit Success Pack, ask where recurring gifts land.

   Pledgivo: it detects Person Accounts when it installs, and works alongside NPSP with an optional sync of recurring gifts and designations into NPSP's own records.

6. Who holds the card data?

   When the card fields are served by the payment processor, card numbers never reach your pages or your org. Ask whose servers they pass through and whose payment account the money lands in.

   Pledgivo: card details go from the donor's browser to Stripe; your org stores Stripe's reference and a card summary, never the full number. More on security.

7. Does it support your country and currency?

   Some tools serve only one country. Check yours before you look at anything else.

   Pledgivo: the US and the UK.

Check Pledgivo against your org in five questions

Each source checked on 13 October 2026.

1. Salesforce Help: Elevate RetirementSalesforce has retired the Elevate family of products; the product was retired on February 11, 2025. At the end of a subscription term customers lose Giving Pages and automatic recurring donation processing, and Salesforce recommends alternative partner solutions. Refers to Agentforce Nonprofit (formerly Nonprofit Cloud).
2. salesforce.com: Fundraising softwareUnder Single and Batch Gift Entry: enter and attribute transactions for one-time gifts and commitment installments. Under Gift Commitments: create and track fulfilment of commitments, such as recurring donations, pledges, grants and planned gifts.
3. Trailhead: Track gift transactions (Nonprofit Cloud Fundraising Operations)A gift transaction tracks a payment; Gift Entry enters one or more donations and a Gift Batch groups entries for processing, which creates or updates gift transaction records; a payment processing ISV that handles online donations can send payment information to Fundraising as a gift transaction record.
4. Trailhead: Create and manage gift commitmentsA gift commitment is the promise of a gift that is planned but not paid in full at the start, such as a monthly gift or a pledge.
5. Salesforce Developers: GiftEntry objectGift entries are available only when the Fundraising Access licence is enabled and the Fundraising User permission is assigned.
6. Salesforce Help: Enter Gifts in Gift EntryThe Nonprofit Success Pack's Gift Entry enters gifts one at a time or as a batch.
7. Salesforce Help: Best Practices and Considerations When Configuring the Guest User ProfileGuest users have private org-wide defaults and get read-only record access only through guest sharing rules; the only object permissions allowed are read and create; never give them update or delete; guest-callable Apex should use with sharing, and code that bypasses sharing or permissions should be kept to a minimum.
8. Salesforce Help: Person AccountsPerson accounts store information about individual people by combining certain account and contact fields into one record.
9. stripe.com: A guide to PCI complianceCheckout and Stripe.js and Elements host all card data inputs in an iframe served from Stripe's domain, so card information never touches your servers; the integration table lists Checkout or Elements under SAQ A.
10. Stripe Docs: Integration security guidePCI compliance is shared and you attest to it every year; handling card data directly can mean more than 300 security controls; card type, last four digits and expiry date are not subject to PCI and can be stored.
11. Stripe Docs: Including Stripe.jsStripe.js should always be loaded directly from js.stripe.com, not bundled or hosted yourself.
12. Stripe Docs: Idempotent requestsAn idempotency key lets you repeat a request after a connection error without creating a second object or performing the update twice.
13. Stripe Docs: Automate payment retriesStripe Billing can automatically retry failed subscription and invoice payments.
14. Stripe Docs: Receipts and paid invoicesStripe can automatically email a receipt for successful payments, and your branding and business details control what the receipt shows.