Tax, refunds, and receipts are the unglamorous end of a university storefront project. Most course fees are exempt from sales tax, yet checkout still needs a tax configuration. Refunds must update the order, not just the card. Receipts count against a daily email cap. ElevateActual handles each the same way; here is where every setting lives and who decides it.
What Will You Trip Over First?
Not the catalog, and not the checkout page. The first thing a continuing education unit trips over, once the storefront looks finished, is one of three unglamorous things: a tax setting nobody thought they needed because nothing is taxable, a refund that went back to the card but never reached the order, or a receipt that did not arrive because the org had already sent its daily allowance of email. None of these is hard. All of them are invisible until the week before launch, which is the worst week to discover anything.
This article says where each one lives in Salesforce, which decisions are the unit's and which the institution's, and how a production hot test a few days before launch finds all three. The storefront 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 covers the rest.
Sales Tax: Exempt Is Not the Same as Not Configured
Most course fees are not subject to sales tax in many states, and most continuing education directors know that. What surprises them is the follow-on. A textbook or lab kit sold with a course may be taxable. A membership may be taxable. A camp T-shirt is taxable almost everywhere. The moment a unit sells anything that is not instruction, tax becomes a configuration task, and the answer varies by state and by the institution's own exempt status. The determination is the institution's call, usually the controller's. The storefront's job is to carry it out line by line.
Where the Tax Setting Lives
Every Salesforce Commerce store needs a tax provider, even when every product is exempt. In Setup, under the store's integrations, there is a row for the tax service. It can point at Salesforce's standard tax calculation, at a tax calculator extension written in Apex, or at an outside tax service. Remove that row, or never create it, and checkout cannot total the cart. On every storefront we have built we leave the row in place and configure the products as exempt, because the next product the unit adds may not be.
Products carry a tax category, and the store carries a default. Taxable materials get a taxable category; courses get an exempt one. Where real per-line tax is required, a tax calculator extension computes it at checkout. Salesforce documents the extension points in its Commerce developer guide, and this is one of the few places we allow Apex, because the platform asks for it.
The Missing Default Tax Category
Here is the specific trap. If the store's default tax category is missing, or a product has no category and the store has no default to fall back on, checkout fails at the pricing step with an Apex error that says nothing about tax. We have seen this on a production hot test: the sandbox had the default, production did not, because tax categories are records rather than metadata and did not travel with the deployment. The learner would have seen a generic checkout error. The fix took minutes once we knew where to look, which is why the hot test exists. Put the default tax category on the go-live checklist and it never happens to you.
Refunds: Who Presses the Button, and What Has to Update
A refund in a university storefront is almost always a drop. The learner withdraws before the deadline, the unit's policy says full or partial refund, and someone has to make two things true at once: the money goes back, and the order in Salesforce says so. The second half is the one that gets skipped.
Standard Refund Versus Manual Capture
With Salesforce Payments, the standard refund runs from the order. A user with the right permission opens the order summary, chooses the lines to refund, and Salesforce sends the refund to the processor and updates the OrderPaymentSummary record so the captured amount, the refunded amount, and the balance agree. The order, the enrollment, and the bank all tell the same story.
With a hosted checkout through the campus processor, the refund is issued in TouchNet or Transact CashNet by the bursar's office, because that is where the merchant account is. Salesforce does not know about it until something records it: a screen flow for the registrar's team that marks the line refunded and updates the payment summary, or an automated step that reads the processor's report. Without that step the order says paid, the participant record says enrolled, and the learner's card says refunded. The article on taking payments on a Salesforce storefront explains why the two paths differ.
Partial Refunds for Drops
Partial refunds are where unit policy meets configuration. A unit that refunds part of the fee after the first session, or keeps a materials fee, needs that rule written down before the build, because the refund flow has to compute it. The policy is the unit's. The approval is often shared: the unit approves the drop, the bursar approves the money, and the flow records who did which. The flow-first automation for enrollment article shows how the drop, the refund, and the participant status change travel together.
Receipts: What a Learner Expects to Get
A learner expects one email, within a minute, that says what they bought, what they paid, when the course meets, and how to reach the unit. In Salesforce Commerce that is the order confirmation email, sent by a flow when the order summary is created, from an organization-wide email address the institution has verified. Write the template early, because the receipt is the first thing a director forwards to a colleague with the words "is this right."
The from address must be a verified organization-wide address, or the email will not send and nothing on the storefront will say why. The receipt should carry what an employer's reimbursement office needs: the institution's name, the order number, the line items, and the amount paid, so the learner never asks for a second document.
The Daily Email Send Limit
Every Salesforce org has a daily cap on single emails sent from automation, including Flow email alerts, and the cap resets at midnight GMT. It depends on the edition, and sandboxes and developer orgs are capped far lower than production, which is why a bulk test in a sandbox can fail for a reason that has nothing to do with your flow. Production is comfortably above a normal day of receipts. It is not comfortably above a registration-day rush plus a reminder campaign sent from the same org that morning. When the cap is reached, order confirmations stop quietly for the rest of the day. Bulk sends belong in a marketing platform or in a scheduled flow that paces itself, not in a one-shot list email on the morning registration opens. The institution's Salesforce administrator knows the cap; ask before the first term.
Who Decides What?
| Decision | Who decides | Where it lives in Salesforce |
|---|---|---|
| Which products are taxable | Institution: controller or tax office | Tax category on Product2; the store's default tax category |
| How tax is calculated: standard, extension, or outside service | Institution, with the implementation team | The tax service row under the store's integrations in Setup |
| Refund policy and drop deadlines | Unit | Refund flow logic and the policy text on the product page |
| Who may issue a refund | Institution (bursar) for the money; unit for the drop | Permission set for the refund action; approval step in the flow |
| Where the refund is executed | Institution, through the processor contract | Salesforce Payments from the order, or the processor console followed by an update to OrderPaymentSummary |
| Receipt wording and branding | Unit | Order confirmation email template and the flow that sends it |
| From address | Institution: IT and the email domain owner | Organization-wide email addresses in Setup |
| Daily email volume plan | Institution's Salesforce administrator, with the unit | Flow email alerts versus a marketing platform; scheduled flow pacing |
| Card fee shown to the learner | Institution: treasurer | Checkout display and processor configuration |
The Production Hot Test
Two or three days before launch, after the production deployment and before the public link goes out, someone on the unit's staff buys a real course on the production storefront with a real card. Not a sandbox, not a test card. Then the team checks six things.
- The cart totaled, which proves the tax integration row and the default tax category exist in production.
- The payment succeeded on the production merchant account, and the bursar can see it.
- The order summary shows paid and the
OrderPaymentSummarybalance is correct. - The Course Offering Participant record was created with the right status.
- The receipt arrived, from the right address, with the right wording, within a minute.
- The refund, issued the same day through the real refund path, reached the card and updated the order.
The hot test costs one course fee for a day and a short meeting. It has found a missing default tax category on a storefront that had passed user acceptance testing, and it catches an unverified from address or an unassigned refund permission just as well. It also settles who does what on launch day, because the people who ran it will answer the first learner's email. The UAT and go-live article places it in the full launch sequence, and the Commerce Accelerator includes it as a fixed step.
Tax, refunds, and receipts will never be the part of the project anyone wants to present. They are the part the learner notices. Get them right and nobody will mention them, which, for this corner of a storefront, is the goal.
Questions We Hear
Our courses are all tax exempt. Do we still need a tax setup?
Yes. Salesforce Commerce totals the cart through a tax service, so the store needs the tax integration row and a default tax category even when every line is exempt. Configure the courses as exempt rather than removing tax, so that a taxable textbook or kit added next term does not need a new project. The determination of what is exempt belongs to the institution's controller.
Who should own refunds, the unit or the bursar?
Split it. The unit owns the drop decision and the policy that sets the amount. The bursar owns the movement of money, because the merchant account is theirs. We build both steps into one flow so the drop, the approval, the refund, and the participant status change happen in order and the record shows who did each.
Can a learner get a refund without calling anyone?
Within the policy window, yes. A screen flow on the learner's account page can accept a drop request, compute the refund from the unit's policy, and either process it or queue it for approval. Most units keep a human approval step for the first term and remove it once they trust the policy logic. Outside the window, the request becomes a case for learner services.
Why did my receipt not send?
Check four things, in this order: the flow that sends it is active, the from address is a verified organization-wide email address, the org has not reached its daily single-email cap, and, if you are testing in a sandbox, email deliverability is set to allow all email rather than system email only. On the storefronts we have built, the second and fourth are the usual causes.
What is a production hot test and who runs it?
A real purchase on the production storefront with a real card, two or three days before launch, followed by a real refund the same day. A member of the unit's staff buys; the implementation team and the bursar's office watch the order, the payment, the enrollment record, and the receipt. It proves the configuration reached production, not just the sandbox.