Salesforce Commerce for Higher Education: 20 Questions, Answered

Yes. A course section is a product, a certificate is a bundle or a program product, and a learner buys either in a cart with guest or authenticated checkout. The part that makes it a university storefront rather than a retail one is what happens after payment: automation reads the order lines, finds the Course Offering behind each product, and creates a Course Offering Participant record in Education Cloud, so the registration exists the moment the receipt does. Unity Environmental University's public storefront at learn.unity.edu sells Distance Education courses and bundles this way, and UNE Online's storefront went live for fall 2026 enrollment. The article on selling courses through Salesforce Commerce follows one purchase end to end.

No. As of October 2026 there is no Salesforce SKU by that name, and a proposal that uses it is describing something assembled from other products. The storefront products that run on the Salesforce Platform are B2B Commerce and D2C Commerce, built in Experience Builder on LWR sites, with Storefront APIs and extension points for tax, shipping, and payment. ElevateActual's term for that stack, connected to Education Cloud, is Commerce on Core: the LWR storefront, Order Summary and Order Item Summary records, Person Accounts for learners, and Course Offering Participant records created at checkout. Salesforce's own lifelong learning page promises "a modern storefront experience" and lists Commerce Cloud among the supporting products. The Salesforce Commerce for higher education guide sorts out the names.

No, and for course sales it is the wrong product. B2C Commerce is the former Demandware platform: a separate stack with its own hosting and code base, connected to Salesforce CRM by integration. It exists for large retail catalogs and holiday traffic. A university that buys it to sell courses then has to build the connection to Education Cloud that D2C or B2B Commerce gives it for free, because those two run in the same org as the learner records. Storefront Next, Salesforce's React template, belongs to B2C Commerce and does not apply either. If an RFP response says "Commerce Cloud B2C," ask how enrollment gets created. The commerce guide compares the three in one table.

Partly, and the gap is the point. Education Cloud models noncredit programs with the same Learning, Course Offering, and Course Offering Participant objects it uses for degrees, and its Student Financials module bills a known learner for known fees through a Salesforce Payments merchant account. What Education Cloud does not include is a public catalog, a cart, promotions, guest checkout, or group purchase. Those come from Salesforce Commerce installed in the same org. So the honest answer is: Education Cloud holds the enrollment and the learner, Commerce sells the seat, and the two share one data model. The continuing education page describes how the pieces fit for an open-enrollment unit.

On a Commerce on Core storefront, checkout produces an Order and an Order Summary with one Order Item Summary per line. A record-triggered Flow then does the enrollment work: it finds or creates the Person Account from the shopper's details, matches each line to its Course Offering, creates a Course Offering Participant with the right status, and publishes a Platform Event for the SIS and the LMS. The receipt goes out from the Order Summary. None of that is custom code; it is Flow and standard objects, which is why a campus admin can read it later. The Flow-first automation article shows the exact sequence and the two places it can fail.

Yes, on D2C Commerce. A guest enters name, email, and payment, and the post-purchase Flow creates or matches a Person Account afterward, so the institution still gets a clean learner record without forcing an account on someone buying a one-evening workshop. Matching by email and name needs a rule, and duplicate handling needs a decision, because guests misspell their own names. Our house demonstration storefront, ElevateActual University, runs guest checkout across fifty programs so visitors can try it. Authenticated checkout stays available for returning learners who want order history and saved details. The see it live page links to the demo and to the production storefronts we may name.

Each Course Offering in Education Cloud, meaning a section with dates, location, and format, becomes a product the storefront can sell. There are two ways to arrange them. The simple model lists each section as its own product under a category per term, which is right when sections differ mostly by date. The variation model makes the course a parent product with term and modality as attributes, so a learner picks "Spring 2027, online" from a selector, which is right when the same course runs every term in several formats. Both read capacity from the offering. The continuing education data model article shows the mapping from Learning Course down to the product and back to the enrollment.

Yes. This is what B2B Commerce is for: an employer's account gets a Buyer Group, the Buyer Group gets a price book with the negotiated rate and visibility into a private catalog, and a coordinator buys ten seats in one order. A registration form then collects the ten learners' names, and the Flow creates ten Course Offering Participant records against one Order Summary. Invoice terms are possible where the institution's finance office allows them. The phase-two scope for DU Learning Exchange adds group registration in exactly this shape. Many institutions run a D2C store for individuals and a B2B store for partners against the same catalog. The Salesforce Commerce guide covers corporate partnerships.

Yes. A membership is a product with a term, a gift is a product with a designation and any amount, and a course is a product with an offering behind it. All three sit in one cart and one Order Summary, and the post-purchase Flow routes each line by product type: enrollment for the course, a gift record for the donation, an expiry date for the membership. Alumni units like this because a learner renewing a membership can add a gift without a second checkout. Recurring gifts and giving-day traffic add their own design questions. The online giving article covers any-amount gifts and what a giving day does to a storefront.

Yes. An LWR Experience Cloud site runs on a custom domain, so the storefront lives at learn.yourschool.edu or shop.yourschool.edu with the institution's own certificate, not on a vendor subdomain. Unity Environmental University's storefront is at learn.unity.edu. The campus web team provides the DNS record and the certificate; Salesforce serves the site. Keep program marketing on the main site if the content team prefers, and deep-link from campaigns into the storefront, which is how DU Learning Exchange was designed. One domain decision to make early: whether the storefront is a path on the main site or its own subdomain, since cookie consent and analytics follow from it. See the continuing education page.

The platform parts are documented and the custom parts are your responsibility. Salesforce publishes accessibility conformance reports for Experience Cloud LWR, Commerce, and Education Cloud on its accessibility conformance reports index, which tell you how the standard components perform against WCAG. Every custom Lightning Web Component, every image a unit uploads without alt text, and every color choice in the theme is outside those reports. On the storefronts we have built, the recurring defects are contrast in brand colors, focus order in custom pickers, and alt text on course tiles. The WCAG checklist for a university storefront on LWR is the list we test against before launch.

Two patterns, and we have built both. The first is Salesforce Payments: a merchant account provisioned through Stripe, with the payment form inside the Salesforce checkout and settlement reported in Salesforce. The second is hosted checkout: the storefront builds the cart and order, hands the learner to the campus processor's hosted page at Transact CashNet or TouchNet with a signed request, and a post-authorization adapter writes the result back to the order. In the second pattern the item code equals the course number, so finance reconciles the deposit without a crosswalk. The bursar's choice of processor usually decides which pattern you get. The payments article compares them line by line.

No. The campus payment processor stays, and the storefront sits beside it. What moves to Salesforce is the catalog, the cart, the order, the receipt, and the enrollment; what stays with TouchNet or Transact CashNet is card acceptance, settlement, and the general ledger feed. The hosted-checkout pattern exists precisely so that the bursar does not acquire a second merchant account they did not ask for. We built the Transact CashNet eMarket checkout with a signed handoff and a post-authorization adapter for this reason, and TouchNet follows the same pattern. Tell the bursar early; the conversation goes better when the answer to "are you replacing us" is no. The payments article has the integration detail.

Line by line, and the rule is the institution's to decide before anyone configures anything. Most universities are not taxed on instruction but may be taxed on books, materials, merchandise, or event tickets, and the answer varies by state and sometimes by buyer location. Salesforce Commerce provides a standard tax integration and an extension point for a tax calculator written in Apex, which is one of the few places where we write Apex at all. The extension computes tax per cart line and the result is stored on the Order Item Summary, so receipts and refunds carry it. If everything you sell is exempt, the configuration is a single switch. The tax, refunds, and receipts article covers the decision tree.

At the order line. A withdrawal before the deadline cancels the Order Item Summary, refunds the payment through Salesforce Payments or through the campus processor, and updates the Course Offering Participant status, all from one staff action. Partial refunds, drop fees, and transfers to a later section are policy questions that each unit answers differently, and the storefront enforces whatever the policy says, so write the policy first. On the storefronts we have built, the most common surprise is a unit that had never written its refund rule down because the old platform's staff did it by hand. Receipts are regenerated after a refund so the learner's record matches finance. The refunds article lists the policy decisions.

Four things, in descending order of effect. Scope: how many units, catalogs, and payment paths launch on day one. Integration: whether enrollments post to the SIS and the LMS in real time, in a nightly file, or not at all. Catalog shape: a flat list of sections is quicker than variations, bundles, prerequisites, and member pricing. And decisions: a unit that knows its refund rule, its tax rule, and its approval chain finishes weeks earlier than one that discovers them during build. Licenses are a separate line, priced by Salesforce. We publish no figures on this site because the drivers matter more than any number without context. The cost drivers article goes through each one.

About two months for a fixed-scope storefront with one unit, one payment path, and enrollment automation, which is what the ElevateActual Commerce accelerator delivers. Unity Environmental University went from kickoff to a live public storefront in about three months. DU Learning Exchange kicked off in June 2026, signed user acceptance in September, and deployed to production the same month, with launch following the university's identity and SIS integration steps. The schedule stretches when the payment processor's sandbox is slow to provision, when the catalog is still being decided, or when the SIS integration has no owner on the campus side. The UAT and go-live article shows the last four weeks in detail.

A storefront on the institution's domain with its brand, the catalog loaded from the unit's course data, checkout through Salesforce Payments or a hosted campus processor, learner-record automation that creates Person Accounts and Course Offering Participant records at purchase, receipts, a Commerce Admin permission set so unit staff manage content without system administrator rights, user acceptance testing, and training. It starts with structured discovery and lands in about two months. It does not include SIS integration beyond a defined handoff, marketing site redesign, or a second payment path, each of which is scoped separately when wanted. The Commerce accelerator page lists the deliverables and the boundaries.

The institution, with as much help as it wants. The storefront is Flow, standard objects, and a small amount of Apex for tax and payments, so a Salesforce administrator who did not build it can read it. Unit administrators manage course content from Salesforce fields under a Commerce Admin permission set rather than as system administrators, which is how DU Learning Exchange is set up. ElevateActual offers a retainer or staff augmentation for institutions without a Commerce specialist, and a Salesforce release twice a year is the main reason to keep one on call. Documentation and a decision log are part of the handover, because the next administrator will ask why. The how we deliver page describes the handover.

Yes. ElevateActual University is our house demonstration storefront at demo.elevateactual.com/eau: fifty programs across seven categories, one cart, guest checkout, and the same enrollment automation we deploy for clients, on a fictional university so nothing is confidential. You can add a course, a membership, and a gift to one cart and complete checkout. For production examples, Unity Environmental University's storefront is public at learn.unity.edu, and UNE Online's storefront serves its graduate health programs. We walk through either on a call and can show the Education Cloud records that checkout creates. The see it live page has the links and a short guide to what to click first.