Salesforce Commerce for Higher Education: How Universities Sell Courses Online

Universities sell courses, certificates, and gifts on Salesforce by running B2B or D2C Commerce on the Salesforce Platform with an Experience Cloud storefront, connected to Education Cloud so that checkout creates the enrollment record. ElevateActual calls that pattern Commerce on Core. It is not B2C Commerce, not a student information system, and not a payment processor.

What Does Salesforce Itself Say About Commerce in Higher Education?

Salesforce has no product page for commerce in higher education, and no product with that name. As of October 2026 the closest official statement is on the Salesforce Lifelong Learning page, which says: "Deliver a modern storefront experience that surfaces relevant course, program, and degree offerings to students," and lists Commerce Cloud among the supporting products. The Education Cloud product page, the Academic Operations page, and the Education Cloud pricing page do not mention a storefront.

Two other Salesforce sources fill in the picture. A Salesforce Architects article on continuing education positions Commerce Cloud for program purchase and registration, paired with Experience Cloud for the learner portal, and calls it a better fit for most post-degree certificate programs than a traditional enrollment system. Salesforce has also posted account executive roles dedicated to Commerce Cloud in higher education, naming lifelong learning, alternative credentials, continuing education, alumni engagement, and digital storefronts as the use cases.

What is missing is the detail: which Commerce product, which records, which payment processor, and what a learner experiences at checkout. This guide supplies it from the storefronts we have built. The short version for a continuing education unit is on our continuing education commerce page. To click through a working store first, see a Salesforce university storefront live. The fixed-scope version of the build is the Commerce Accelerator.

What Is Commerce on Core, and How Is It Different From B2C Commerce?

Salesforce sells three things under the Commerce name, and the differences matter. Commerce on Core is ElevateActual's term for B2B Commerce or D2C Commerce built on the Salesforce Platform, with a storefront built in Experience Builder on the Lightning Web Runtime (LWR). "On Core" means the store, the carts, the orders, the learner records, and the Education Cloud objects all live in one Salesforce org, in one database, under one security model. The Salesforce Commerce developer guide documents this stack: LWR storefronts, Storefront APIs, and extension points for tax, shipping, and payment.

B2C Commerce is the former Demandware product: a separate retail platform with its own data store, developer tooling, and hosting, built for high-volume consumer retail. Storefront Next is a React storefront template for B2C Commerce, described in the Salesforce Storefront Next announcement. Neither runs in the org where Education Cloud keeps learner records, and we do not use either for higher education.

Salesforce publishes accessibility conformance reports for Experience Cloud LWR, Commerce, and Education Cloud on its accessibility conformance report index. Every term in this section has a one-paragraph definition in the Salesforce higher education glossary.

What Does the Reference Architecture Look Like?

The architecture is a chain of standard records, and every link in it is a Salesforce object you can report on. Here is the chain as we build it, from the learner's browser to the enrollment record.

1. Storefront. An LWR Experience Cloud site tied to a WebStore. Categories, search, product pages, and the cart are standard Commerce components; custom Lightning Web Components cover the rest, such as a term-and-modality picker.
2. Catalog. Each sellable offering is a Product2. A course that runs in several terms or modalities is a variation parent with one child product per section. Prices live in Pricebook2 and PricebookEntry; cohort pricing is a BuyerGroup with its own price book; discounts are Promotion records.
3. Cart and checkout. Selections sit in a WebCart. Checkout collects the buyer's details, calculates tax through a tax extension when the unit charges it, and hands the payment to the processor.
4. Order. A successful payment creates an Order with OrderItem lines, and Commerce generates the OrderSummary and OrderItemSummary records. Staff work from the Order Summary: refunds, cancellations, and receipts happen there.
5. Learner. The buyer is a Person Account, a record on Account that carries the person and the account in one row. Guest buyers are matched to an existing Person Account by email and name, or a new one is created.
6. Enrollment. A record-triggered Flow on the Order Item Summary creates a CourseOfferingParticipant linking the Person Account to the CourseOffering the product represents. The Course Offering belongs to a LearningCourse within a LearningProgram, and runs in an AcademicTerm.

That last step is the whole point. On the day a learner pays, the unit has a standard Education Cloud enrollment record, the same object a degree program uses, with no re-keying and no nightly export. Salesforce documents the learning objects in Model Program Offerings in Education Cloud and confirms that continuing education programs and CEUs use the same objects as degree programs. We go deeper, with a diagram, in the Education Cloud data model for continuing education.

What Does a Learner See?

A learner sees a catalog, not a form: categories such as professional certificates or language courses, search across the whole catalog, and product pages whose description, instructor, dates, format, and price come from Salesforce fields rather than a page builder.

Courses that run more than once appear once. A learner opens the course, picks a term and a modality, say spring 2027 online or fall 2026 on campus, and the price and seat availability update for that section. This is a product variation, and it is the single design decision that most reduces catalog sprawl.

The cart holds items from any unit that shares the store. Guest checkout is on by default: a learner can pay without creating an account, which matters for a public audience that will not remember a password from two years ago. After payment the learner sees a confirmation page and receives a receipt by email, generated by Flow from the Order Summary. Learners with an account see their order history and, through the Education Cloud learner portal, their enrollments; Salesforce documents that side in Set Up Course Registration.

Test every step on ElevateActual University, our demonstration storefront with fifty programs, seven categories, one cart, and guest checkout, or on the production storefront at learn.unity.edu.

What Do Staff See?

Staff see Salesforce. There is no second administration console to learn.

• Products from Course Offerings. A unit administrator maintains the Course Offering: dates, instructor, seat cap, location. The product the learner sees reflects those fields. On the DU Learning Exchange, unit administrators manage course content from Salesforce fields with a Commerce Admin permission set rather than system administrator rights.
• Pricing and promotions. Price books handle standard, member, and early registration pricing; a date-based price change is a price book entry, not a code deployment. Coupon codes and bundle discounts are Promotion records a unit can create, schedule, and expire.
• Buyer groups for corporate cohorts. B2B Commerce buyer groups let an employer's learners see a private catalog at negotiated prices. The employer can pay once for a cohort, and each learner still gets their own Course Offering Participant record.
• Waitlists. A full section still accepts registrations as waitlisted Course Offering Participant records, which is how the DU Learning Exchange handles waitlists. The planned second phase at DU adds automatic enrollment when a seat opens.
• Reporting. Orders, revenue by program, enrollments by term, and waitlist depth are standard reports. A 2023 Modern Campus and UPCEA report found that 46 percent of continuing education units struggle to get real-time enrollment data. The chain above is the fix for that specific complaint.

How Do Universities Take Payments on a Salesforce Storefront?

The rule we apply on every project: the campus payment processor stays, and the storefront, the order, and the receipt move to Salesforce. A bursar's merchant relationship, PCI scope, reconciliation routine, and general ledger mapping do not need to change. Salesforce Commerce integrates with the processor; it does not replace it.

Salesforce's Student Financials documentation describes fees as Products and a Salesforce Payments merchant account for the learner account view, consistent with the Stripe pattern above. The full comparison, including refunds and reconciliation, is in how universities take payments on a Salesforce storefront; tax, refund, and receipt behavior is in tax, refunds, and receipts on a university storefront.

What Does the Storefront Not Do?

A storefront that claims to do everything will do registration badly. Here is where we draw the line.

• It is not the student information system. Banner, Colleague, Jenzabar, and PeopleSoft remain the system of record for credit-bearing enrollment, transcripts, and financial aid. At UNE Online, Banner is the system of record and is integrated only through supported Banner APIs, never direct database writes. For noncredit units with no SIS footprint, the Course Offering Participant is often the only enrollment record that exists, and that is fine.
• It is not the learning management system. Canvas, Brightspace, and Moodle deliver the course. The storefront creates the enrollment; an integration provisions the LMS seat.
• It is not the payment processor. With a hosted checkout the storefront never holds card data, and with Salesforce Payments the card data goes to the processor's fields, not to Salesforce records.
• It is not the marketing site. The DU Learning Exchange is a transactional-only storefront. Program marketing stays on du.edu, and campaign deep links land the learner on the product page.

Which Universities Run Salesforce Commerce for Courses Today?

Three storefronts we built illustrate the pattern at three different starting points, as of October 2026.

At the Education Trailblazers Summit in June 2026, UNE Online said most of its support tickets had come from the old storefront not working, and that design sign-off on the new one took a day. On the old platform:

"It's bad for the college and worse for me."

UNE Online, Education Trailblazers Summit, June 2026

On the new storefront:

"It's great for the college and even better for me."

UNE Online, Education Trailblazers Summit, June 2026

The full write-ups are on the case study pages: UNE Online, Unity Environmental University, and DU Learning Exchange.

What Drives the Cost of a Salesforce Storefront?

We do not publish prices, and we will not pretend a storefront has one. The cost has three parts, each driven by decisions the institution controls.

Licensing. Salesforce licenses Commerce on the Platform separately from Education Cloud, and Experience Cloud logins for learners are a further line. The institution's existing Salesforce agreement changes the number more than anything a partner does. Salesforce publishes an Education Cloud pricing page; read it with your account executive, because the published cards do not cover every combination.

Build. The build cost moves with the shape of the catalog (how many products are variations, how many units share the store), the payment pattern (native Salesforce Payments is the least work, a hosted campus checkout with write-back is more), the depth of SIS integration, the historical data to migrate, and the number of custom components the design demands. One unit with native payments and no SIS writes is the small end. A multi-unit store with corporate buyer groups, a hosted checkout adapter, and a Banner integration is the large end.

Run. After launch the recurring cost is the processor's transaction fees plus administrator time to maintain the catalog. The campus team that administers the CRM can administer the store.

The one cost people forget is the old platform. Every month a legacy registration system runs beside the new storefront is a month of double licensing, so we sequence cutover to end that quickly. More in what drives the cost of a Salesforce storefront.

How Long Does It Take to Launch?

Our Commerce Accelerator is a fixed-scope build that goes live in about two months, starting with structured discovery. Unity Environmental University went from kickoff to go-live in about three months. The DU Learning Exchange went from a June 2026 kickoff to a signed user acceptance and production deployment in September 2026.

What stretches a timeline is rarely the storefront. It is single sign-on decisions, SIS integration approval cycles, procurement, and content readiness. We put those on the plan in week one so they do not surprise anyone in week eight. The acceptance routine is in UAT and go-live for a university storefront. If you are leaving a legacy registration platform, the cutover is part of the timeline; see our migration guides, including moving from Destiny One to Salesforce.

How Should You Evaluate a Partner for This Work?

Most Salesforce partners have built either Education Cloud or Commerce, and few have connected the two in production. Put these to every bidder before you sign.

1. Show me one running. Not slides. A public storefront with a real catalog, a cart, and a checkout you can complete. If the partner cannot point to one, you are the pilot.
2. Name the objects. Ask what record is created when a learner pays. The answer should include Order Summary, Person Account, and Course Offering Participant without hesitation.
3. Name the Commerce product. If the proposal is B2C Commerce or Storefront Next for a continuing education unit, ask how the enrollment gets back into Education Cloud and who will run the second platform.
4. Standard first, Flow first. Ask what custom objects the partner expects to create; the right answer is few or none, each with a written reason. Flow and Platform Events should carry the enrollment and receipt logic, with Apex only where the platform requires it, such as a tax calculator extension or a payment adapter.
5. Who does the work, and on which processor. Ask for the names of the people who will build it, whether they have built one before, whether they have shipped checkout against your processor, and who tests custom components for accessibility. Our team page lists ours.

A longer checklist is in what a university RFP committee should ask a Salesforce partner, and the most common buyer questions are answered in the Salesforce Commerce for higher education FAQ.

Where Is This Going?

Three things will shape university storefronts over the next two years. More of the enrollment lifecycle will be standard Education Cloud, which means less custom code and faster builds. The same storefront will sell more than courses: the online giving on Salesforce Commerce pattern puts gifts, memberships, and event tickets in the same cart as a certificate. And Salesforce lists a Course Search agent among its education agents; a storefront built on standard objects is exactly what that agent needs to answer "what runs online in January." We cover that in Agentforce for higher education.

The institutions that benefit first will be the ones whose catalog already lives in standard objects. That is the quiet reason we insist on them.

Questions We Hear