The cost of a Salesforce storefront for continuing education comes from four places: Salesforce licenses, processing fees set by the processor, the build, and running it. Licenses are published list prices; the other three depend on scope choices the unit controls. ElevateActual names those choices, without figures, so a director can size a project before asking for a quote.
What Are the Four Cost Components?
Every storefront estimate we have written breaks into the same four parts. Licenses are what the institution pays Salesforce each year for the products the storefront runs on. Payment processing is what the processor keeps from each transaction. The build is what a partner or an internal team charges to design, configure, integrate, and launch. Run is what it costs, in staff time and subscriptions, to keep the storefront selling after launch. A director who can place the unit against each of the four can predict where an estimate will land.
The storefront in question is what ElevateActual calls Commerce on Core: B2B or D2C Commerce on the Salesforce Platform, with an LWR Experience Cloud storefront, connected to Education Cloud so that checkout creates the enrollment. The guide to Salesforce Commerce for higher education explains the architecture. This article explains the bill.
What Do the Licenses Cover?
Four Salesforce products can appear on a storefront license order, and not every project needs all four.
- Salesforce Commerce. The storefront engine: catalog, pricing, cart, checkout, and order records. Salesforce prices B2B and D2C Commerce on terms tied to the volume sold through the store, so a unit's expected annual sales matter more than its headcount.
- Experience Cloud. The site the learner visits. Guest shoppers browse and buy without a license. Learners who sign in to see orders and enrollments consume Experience Cloud capacity, which Salesforce prices per login or per member on its Experience Cloud for Education pricing page.
- Education Cloud. The learner record: Person Accounts, Learning Programs, Course Offerings, and Course Offering Participants. If the institution already runs Education Cloud, the storefront adds no new Education Cloud license. If it does not, this is the largest single line, and the published list price is on Salesforce's Education Cloud pricing page.
- Payments. Salesforce Payments is quoted as part of the Commerce contract, and its ongoing cost is the processing fee. A hosted checkout through the campus processor adds no Salesforce license at all.
Two licensing questions move the total more than any other. First, does the institution already own Education Cloud and Experience Cloud? A unit inside an Education Cloud campus often needs only Commerce. Second, how many people need a full Salesforce license to administer the store? On our storefronts, unit staff manage courses from Salesforce fields with a Commerce administrator permission set, and that group is usually small. Salesforce publishes list prices and the account executive quotes the contract. We do not quote either on this site.
Who Sets Payment Processing Fees?
The processor does. Whether the storefront uses Salesforce Payments with Stripe, Transact CashNet, or TouchNet, the per-transaction fee is set by the processor agreement and the card networks, not by Salesforce and not by the implementation partner. For most campuses the storefront changes nothing here, because the pattern we recommend keeps the existing campus processor, so the processing line in a storefront budget is the line the bursar already has. The article on taking payments on a Salesforce storefront compares the options.
One policy choice does affect it: whether the institution passes a card fee to the learner. That is set by the treasurer, and the storefront can display the total either way.
What Makes a Build Larger or Smaller?
Build effort is where scope choices show up. Six choices account for most of the difference between our smallest and largest storefront projects.
Catalog Shape
A flat catalog of courses, each sold once per term, is the cheapest to build and the easiest to run. Catalogs with nested programs, prerequisites, and course-to-program rules take more modeling, more test cases, and more training.
Variations
A course offered in two terms, two sections, and two modalities is one product with variation attributes, not eight products. Setting up the variation model is a one-time cost that pays back every term, because the unit maintains one product page per course. Catalogs that need many attribute combinations, or prices that differ by attribute, take longer.
Custom Checkout Rules
Standard checkout handles guest and registered learners, promotions, and buyer groups. Rules beyond that, such as residency pricing, timed seat holds, prerequisite checks at add-to-cart, or checkout embedded in a program page, require Lightning Web Components and sometimes Apex. Each rule is its own line in the build.
SIS Integration
If the storefront is the system of record for noncredit enrollment, there is no SIS integration to build. If every paid enrollment must land in Banner, Colleague, Jenzabar, or PeopleSoft, the integration is often the largest single build item, and the institution's integration team sets the pace. We integrate only through supported APIs, never direct database writes, which is safer and also slower to approve.
Number of Units
One continuing education unit with one catalog is one store. A university that wants language programs, professional education, and summer camps in a single storefront needs category design, per-unit permissions, per-unit reporting, and sometimes per-unit payment routing. Each additional unit adds discovery and testing even when the technical pattern is shared.
Migration of History
Launching with an empty order history is the cheapest path and is often fine for noncredit programs. Bringing prior enrollments, certificates in progress, and promotion codes across from Destiny One, CampusCE, Lumens, or a spreadsheet adds a data workstream with its own mapping, cleansing, and validation cycles.
What Does It Cost to Run?
Running cost is mostly people, and three questions decide it.
- Who publishes products? On our storefronts, unit staff create and update course offerings from Salesforce fields and the product appears on the storefront without a developer. If the design instead needs a developer or a web team to publish each term's catalog, running cost rises every term.
- Who answers learners? Order questions, refund requests, and login problems need a named owner with the right permission set. Storefronts that route these to a shared Salesforce queue with a case record cost less to run than storefronts where they arrive by email to whoever is available.
- What is the release cadence? Salesforce ships three releases a year. Someone reviews the release notes for Commerce and Education Cloud, retests checkout in a sandbox, and republishes the storefront. An institution with a Salesforce administrator absorbs this; a unit without one needs a support arrangement.
The how we deliver page describes the handover and training that settle the first two of these before launch.
How Do Scope Choices Change Effort and Running Cost?
| Scope choice | Effect on build effort | Effect on running cost |
|---|---|---|
| Flat catalog, one product per course | Low | Low |
| Variation attributes for term, section, and modality | Medium, one-time setup | Low; fewer products to maintain each term |
| Guest checkout only | Low | Low |
| Registered learner accounts with order history | Medium | Medium; login support and Experience Cloud capacity |
| Salesforce Payments with Stripe | Low | Medium; the unit owns a merchant account and payouts |
| Hosted checkout with the campus processor | Medium; signed handoff and adapter | Low; the bursar's existing process |
| Standard checkout rules | Low | Low |
| Custom checkout rules in Lightning Web Components or Apex | High | Medium; retest after each release |
| No SIS integration; the storefront is the record | Low | Low |
| SIS integration through supported APIs | High | Medium; monitoring and SIS upgrades |
| Single unit | Low | Low |
| Several units in one storefront | High | Medium; per-unit permissions and reporting |
| Launch with no history | Low | Low |
| Migrate enrollments and certificates in progress | High | Low once launched |
| Standard order confirmation email | Low | Low |
| Custom receipt templates and bulk notifications | Medium | Medium; email limits and template upkeep |
Mark the unit's choices down the left column. A column of Lows is an accelerator. A column with three or more Highs is a scoped project, and the estimate should say so.
Why Does a Fixed-Scope Accelerator Exist?
Most continuing education storefronts need the same things: a catalog with variations, guest and registered checkout, one payment path, order confirmation, and learner-record automation that creates the Course Offering Participant when the order is paid. When the scope is the same, the estimate should be the same. That is the reasoning behind the Commerce Accelerator, one of three fixed-scope accelerators ElevateActual runs, each live in about two months and each starting with structured discovery. Fixing the scope lets the price be fixed, and fixing the sequence tells the unit what it is deciding in which week.
The discovery at the start exists to find out whether the unit fits. Most do. Some do not, and it is better to learn that in week one than in week six.
What Pushes a Project Out of the Accelerator
- An SIS integration on the critical path to launch, rather than in a second phase.
- More than one payment processor, or a processor the campus has not yet contracted.
- Checkout rules that standard Commerce does not do, such as residency pricing or timed seat holds.
- Several units launching at once with different catalogs, permissions, and refund policies.
- Migration of enrollment history that must be complete on day one.
- An institution without Education Cloud or Experience Cloud, where licensing and provisioning run alongside the build.
None of these is a reason not to build. Each is a reason to scope a project rather than run the accelerator, with a timeline that reflects the extra work. The implementation timeline by scope shows how the same choices change the calendar. A unit that can answer the six build questions and the three run questions above will receive an estimate it can defend to its chief financial officer, and that is how we expect to keep estimating storefronts as more units move to Salesforce.
Questions We Hear
Why does this article give no figures?
Salesforce publishes its list prices and negotiates contracts institution by institution, so any figure we printed would be wrong for most readers. Build estimates depend on the scope choices above, which is why we estimate after discovery rather than before. The drivers are stable even when the numbers are not, and a director who understands them can read any estimate critically.
Does the storefront need Education Cloud?
Salesforce Commerce can sell a product without Education Cloud, but the enrollment then has no standard place to live. We build on Education Cloud so that checkout creates a Course Offering Participant on a Person Account, which is the record the rest of the institution can report on. If the campus already owns Education Cloud, the storefront adds no new learner-record license.
Is Salesforce Payments cheaper than keeping the campus processor?
Compare the processor agreements, not the storefront. In both cases the per-transaction fee is set by the processor and the card networks. Salesforce Payments means the unit or institution holds a new merchant account with Stripe behind it; a hosted checkout keeps the bursar's current agreement. The storefront cost is similar either way.
What is the smallest storefront that is still worth building?
A flat catalog with variation attributes, guest checkout, one payment path through the campus processor, the standard order confirmation email, and a flow that creates the enrollment record when the order is paid. No SIS integration and no migrated history. That storefront fits the accelerator and gives the unit a record of every learner it did not have before.
How does the cost change after the first year?
Licenses renew annually and scale with the volume sold or the number of signed-in learners. The build does not repeat. Running cost depends on the three questions above: who publishes products, who answers learners, and who handles releases. Units that keep publishing in the hands of their own staff see running cost settle into ordinary administrative time.