A university can take gifts on the same Salesforce Commerce storefront that sells its courses, memberships, and event tickets. Designations become products, an any-amount gift becomes a one-unit product multiplied by quantity, and post-order automation writes the gift to the Fundraising objects. ElevateActual built this pattern for a public university's giving storefront.
Why Put Giving on a Commerce Storefront?
An advancement office that runs Salesforce Fundraising has the gift objects but not the checkout. Salesforce.org Elevate, the former Giving Pages and Payment Services product, was retired, with new sales ended in April 2023 and deactivation on or after October 1, 2024; ElevateActual is not affiliated with it. What remains on the platform is Salesforce Commerce, which we call Commerce on Core: B2B or D2C Commerce on the Salesforce Platform with an LWR Experience Cloud storefront, Order Summary and Order Item Summary records, and Person Accounts for the people who buy. On the giving storefront we built for a public university, one cart takes gifts, pledge payments, memberships, and event tickets, and the gift records land on the Fundraising objects the gift officers already use. The institution is not named here.
Status. Everything below is a pattern we built and ran. Rationale. Giving storefronts attract vendor claims about conversion and average gift, and we publish none. What matters is how the pieces are modeled, because that decides what the gift officers see afterward. Platform rule for the whole page: the storefront takes the payment and the Fundraising objects record the gift; neither does the other's job.
How Is Each Giving Feature Modeled?
| Giving feature | How it is modeled on the storefront | What is created after the order |
|---|---|---|
| Designation (a fund the donor chooses) | A Product2 in a category per college, unit, or cause, with the fund's story, image, and a reference to its GiftDesignation | A gift transaction allocated to that designation |
| Fixed-amount gift option | A product variation or price book entry at a set amount | Gift transaction at that amount |
| Any-amount gift | A one-unit "other amount" product under the designation, with the donor's amount entered as quantity | Gift transaction whose amount is the order line total, not the unit price |
| Quick give on any page | A Lightning Web Component that places a designation and amount in the cart from a landing, story, or home page | The same order and gift records as a catalog checkout |
| In-page checkout | The checkout sequence run inside the page the donor is on, through the Commerce APIs and the payment component's hosted field | A completed order without leaving the story |
| Recurring gift | A GiftCommitment with a recurring schedule, created from the first payment on the storefront | Commitment plus schedule; later installments run through Fundraising's commitment processing, not a cart each month |
| Pledge installment | A payment product tied to the donor's open commitment and its next scheduled transaction | The scheduled gift transaction marked paid; the commitment balance reduced |
| Membership or event ticket | Ordinary products in the same cart, with their own categories and automation | Membership or registration records; no gift transaction unless policy says a portion is a gift |
| Receipt | A Flow-sent email on order completion, with the gift details and tax language the gift processing office approves | An acknowledgment record on the gift for the batch acknowledgment process |
| Employer match a donor claims | A field captured at checkout | A soft credit on the commitment for the gift officer to confirm |
How Are Designations Modeled as Products?
Status. Each fund a donor can choose is a product, and the categories mirror the way the institution talks about giving: by college, by cause, by campaign. Rationale. A product has everything a designation page needs: name, story, image, category path, search indexing, and a price book, so the storefront's own search becomes the fund finder with no custom code. Method. The product carries a reference to its GiftDesignation so post-order automation knows where the gift goes, and the designation stays the source of truth for the gift officers. Platform rule: the designation owns the accounting meaning of the fund and the product owns its presentation; a marketing rename of a product must never rename a fund.
How Does an Any-Amount Gift Work?
Status. A storefront sells products at a price, and a donor wants to type an amount. The pattern that resolved this without a custom pricing engine is a one-unit product under each designation whose quantity is the gift. Rationale. Quantity is the one number the standard cart lets a buyer set freely, so the standard cart, tax, and payment components work unchanged. Method. A picker component presents the fixed options and an "other amount" field together and writes the right product and quantity to the cart, and the cart editor shows the amount as a single figure rather than a quantity. After the order, the automation reads the line total, not the unit price, when it creates the gift transaction. Platform rule: every flow and report downstream must use the order line total, and we audit for it, because the one report that uses unit price will show every any-amount gift as a one-unit gift.
What Are Quick Give and In-Page Checkout?
Donors rarely decide on the giving page; they decide on a scholarship story, a lab news item, or a reunion page. Status. Quick give is a Lightning Web Component that sits on any page of the site with a designation and amount options preset, so the gift starts where the decision happened. In-page checkout goes further: the checkout sequence runs inside the page the donor is on, through the Commerce APIs and the payment component's hosted card field, so the donor never leaves the story. Rationale. Each page change between decision and receipt is a place to stop, and the standard checkout has several. Method. The component drives the same cart, steps, and payment handshake as the catalog checkout, so the resulting order is indistinguishable from any other. Card entry stays in the processor's hosted field, keeping card data inside the processor's compliance boundary. Platform rule: in-page checkout changes where the steps are shown, not what the steps are.
What Happens After the Order?
Status. The order is a Commerce record. The gift is a Fundraising record. Post-order automation, built in Flow on the Order Summary, creates the gift: a GiftTransaction allocated to the designation and credited to the donor's Person Account for a one-time gift, or a GiftCommitment with a schedule and the first transaction for a recurring gift. For a guest donor it finds or creates the Person Account by email and name first. Rationale. Gift officers, rollups, RFM scoring, acknowledgments, and Accounting Subledger all read the Fundraising objects and none read orders, so the handoff is what makes the storefront part of advancement. Method. The receipt goes out from the same automation, with the designation, amount, date, and approved tax language, and an acknowledgment record is written for the batch process. Platform rule: one order produces one set of gift records, once; the automation checks for an existing gift before creating one, because an order can be updated after it is placed.
How Do Pledge Installments, Memberships, and Event Tickets Share the Cart?
Status. A donor with an open pledge pays an installment through the same cart as a new gift. The storefront shows the open commitment and its next scheduled transaction, places a payment product for that amount in the cart, and after the order the automation marks the scheduled transaction paid and reduces the balance. Memberships and event tickets are ordinary products whose automation creates membership or registration records, not gift transactions, unless policy says a portion of a membership is a gift. Rationale. One cart means one receipt, one payment, and one place for the donor to go. Method. Each product carries a type that tells the automation whether the line is a gift, a pledge payment, or a purchase. Platform rule: the storefront must never create a gift transaction for something the policy does not count as a gift, so that type is a policy decision owned by the gift processing office, not a configuration detail. Our guide to Salesforce Commerce for higher education covers the shared cart in the course context.
How Did We Test Giving Day Load?
A giving day concentrates a year of small gifts into a day. Status. Before the storefront's first giving day, we built a guest-checkout generator: a script that walks the storefront's own guest checkout end to end, creating a cart, adding a designation and an amount, entering a test payment, and placing the order. We ran many copies at once, increasing the number until something gave. Rationale. The question was where the ceiling was: the checkout, the payment handshake, the post-order automation, or the receipt email. Method. We ran it against a test environment with receipts suppressed, watched order creation, automation queue depth, and error logs, and found the point at which orders began to queue and which layer was the limit. We then deferred the non-urgent automation, set an orders-per-minute expectation for the giving day team that stayed under the ceiling with room to spare, and cleaned up every generated record. We do not publish the figures, because they belong to one storefront's configuration. Platform rule: the daily email sending limit and the automation queue are part of the throughput ceiling, and a plan that counts only the checkout will meet them at the worst time.
What Does the Storefront Not Replace?
The storefront replaces a giving form vendor. It does not replace three things. The gift processing policy. What counts as a gift, how a joint gift is credited, when a membership is partly a gift, what the receipt must say, and when a pledge is written off are decisions the gift processing office makes; the storefront enforces them through product types and automation. The foundation's bank and processor. Money moves through the foundation's merchant account and payment processor, whether Salesforce Payments with Stripe or a campus processor such as Transact or TouchNet that the storefront integrates with; the storefront never holds funds. Our article on how universities take payments on a Salesforce storefront explains the options. The general ledger. Accounting Subledger prepares journal entries from gift transactions; the finance team's ledger remains the system of record. Which Salesforce product carries the Fundraising objects, covered in Nonprofit Cloud vs Education Cloud for advancement, changes none of this. The giving patterns here run in our demonstration environment; the See It Live page explains how to walk through one.
Questions We Hear
Can a donor give any amount on a Salesforce Commerce storefront?
Yes. The pattern we use is a one-unit "other amount" product under each designation, with the donor's amount entered as quantity. A picker component writes the right product and quantity to the cart, so the standard cart, tax, and payment components work unchanged. After the order, the automation reads the order line total, never the unit price, to create the gift transaction.
Where does the gift end up after checkout?
On the standard Salesforce Fundraising objects. Post-order automation built in Flow reads the Order Summary, finds or creates the donor's Person Account, and creates a gift transaction allocated to the designation, or a gift commitment with a schedule for a recurring gift. Rollups, RFM scoring, acknowledgments, and Accounting Subledger then see the gift the same way they see a gift entered by staff. The order remains a Commerce record for the receipt and the payment trail.
Can pledge payments, memberships, and event tickets go through the same cart?
Yes, and that is the practical reason to put giving on the storefront. A pledge installment is a payment product tied to the donor's open commitment, and the automation marks the scheduled transaction paid. Memberships and tickets are ordinary products with their own records. Each product carries a type that tells the automation whether the line is a gift, a pledge payment, or a purchase, and the gift processing office sets that type.
How do you know the storefront will hold up on giving day?
We test it. A guest-checkout generator walks the storefront's own guest checkout from cart to placed order, and we run many copies at once against a test environment with receipts suppressed, increasing load until orders begin to queue. That shows which layer is the ceiling: checkout, payment handshake, post-order automation, or email. We then defer non-urgent automation, set a safe orders-per-minute expectation for the giving day team, and clean up the generated records.
Does the storefront replace our payment processor or our gift processing office?
Neither. Money moves through the foundation's merchant account and processor, whether Salesforce Payments with Stripe or a campus processor such as Transact or TouchNet that the storefront integrates with; the storefront never holds funds. The gift processing office still decides what counts as a gift, how it is credited, and what the receipt says; the storefront enforces those decisions. What it replaces is the giving form vendor.