Universities take payments on a Salesforce storefront in one of two ways: natively, through Salesforce Payments with Stripe, or through the campus processor's hosted checkout, such as Transact CashNet eMarket or TouchNet uPay. There the bursar's merchant account stays where it is. The storefront, the order, and the receipt move to Salesforce. ElevateActual has built both.
What Moves to Salesforce and What Stays With the Bursar?
The question a continuing education director usually asks first is whether a Salesforce storefront means a new merchant account. It does not have to. On the storefronts we have built, the most common pattern keeps the campus payment processor where it is and moves three things to Salesforce: the storefront the learner shops on, the order that records what was bought, and the receipt. The bursar keeps the merchant account, the settlement reports, and the general ledger feed that already exists.
This matters because the processor is rarely the unit's decision. TouchNet and Transact contracts are signed by the treasurer or the bursar for the whole institution. A storefront project that asks finance to open a second merchant account turns a two-month build into a procurement conversation. One that sends every payment through the existing processor, with the course number already on the line, is a conversation the bursar can say yes to.
The storefront itself is what ElevateActual calls Commerce on Core: B2B or D2C Commerce built on the Salesforce Platform with an LWR Experience Cloud storefront, writing OrderSummary and OrderItemSummary records, and connected to Education Cloud so enrollment is created at checkout. The guide to Salesforce Commerce for higher education covers the full architecture. This article covers the payment step only.
How Does Salesforce Payments With Stripe Work?
Salesforce Payments is the native option. The institution provisions a merchant account through Salesforce Payments setup, with Stripe as the processor behind it. The card fields render inside the checkout page in a frame the payment provider hosts, so the learner never leaves the storefront. When the learner submits, Salesforce creates the payment authorization, captures it, and writes the result against the order's OrderPaymentSummary record without any custom code.
Three things follow. Refunds can be issued from the order inside Salesforce, and the payment summary updates itself. The payment, the order, and the enrollment sit in one database, so a learner-services coordinator sees all three on one record. And the same merchant account can serve Education Cloud Student Financials, which Salesforce Help describes as using a Salesforce Payments merchant account for fees modeled as products.
The trade is that someone at the institution owns a new merchant account and its payouts. For a self-funded unit, or a private institution whose bursar is willing, this is the shortest path. For a public university where every card transaction must flow through one treasurer-approved processor, it is usually not an option, and the hosted-checkout pattern is the answer.
How Does a Hosted Checkout With CashNet or TouchNet Work?
In a hosted checkout, the storefront builds the cart, totals it, and then hands the learner to a page the processor hosts. The learner enters the card there. The processor authorizes and captures the payment on the bursar's merchant account, then sends the result back to Salesforce, where it is written to the order. The storefront never sees a card number.
Salesforce Commerce supports this through its payment extension points. The Salesforce Commerce developer guide describes payment gateway adapters, which are Apex classes that translate between the storefront's payment requests and an outside gateway. For a redirect flow, the adapter's job is mostly to record an authorization that happened somewhere else, which is why the pattern is called a post-authorization adapter. This is one of the few places in our storefronts where Apex is required rather than Flow, and it is a thin class.
The CashNet eMarket Pattern We Built
Transact CashNet eMarket Checkout is the hosted option that CashNet campuses use. The pattern we built works like this.
- At the payment step the storefront assembles the line items, with each item code equal to the course number, and signs the handoff with the shared secret the bursar's office issued for the store.
- The learner is redirected to the campus-branded CashNet checkout page and pays there. The bursar's merchant account takes the charge.
- CashNet returns the transaction result. A post-authorization adapter writes that result to the order's
OrderPaymentSummary, the order moves to its paid state, and the enrollment automation runs. - The learner lands on the storefront's confirmation page and receives the Salesforce order confirmation email.
The decision that made the bursar comfortable was item code equals course number. CashNet already maps item codes to general ledger accounts, so every charge lands in the right GL account using the mapping the bursar already maintains, and the CashNet batch report matches the Salesforce order report line for line. The storefront did not introduce a new reconciliation step. It reused the one that existed.
TouchNet uStores and uPay
TouchNet Marketplace follows the same shape. uStores is TouchNet's own hosted store; uPay is the hosted payment page an outside application hands off to. A Salesforce storefront uses uPay: it posts the amount and a reference, the learner pays on the TouchNet-hosted page against the campus merchant account, and TouchNet posts the result back to an address the institution configures. A post-authorization adapter, or a Flow listening for that result, writes it to the order. Accounting codes are set on the uPay site by the bursar, so the general ledger behavior is the one the campus already has.
We describe these as integrations because that is what they are. Salesforce does not replace TouchNet or Transact as the processor. It sits in front of them.
How Do the Three Options Compare?
| Question | Salesforce Payments with Stripe | Transact CashNet eMarket hosted checkout | TouchNet uPay hosted checkout |
|---|---|---|---|
| Where is the card entered? | On the storefront checkout page, in fields the payment provider hosts | On a CashNet-hosted page after a signed redirect | On a TouchNet-hosted uPay page after a redirect |
| Who holds the merchant account? | The institution or unit, provisioned through Salesforce Payments | The bursar, under the existing Transact agreement | The bursar, under the existing TouchNet agreement |
| How does the result reach the order? | Natively; Salesforce writes the authorization and capture to OrderPaymentSummary | A post-authorization adapter writes the returned result to the order | A post-authorization adapter or Flow writes the posted result to the order |
| How does it reconcile to the general ledger? | Processor payouts plus a Salesforce payment report; the bursar maps payouts to GL accounts | Item code equals course number, so CashNet's existing GL mapping and batch reports apply | Accounting codes on the uPay site; TouchNet's existing reports and ERP feed apply |
| Payment plans | Not a storefront feature for one-time purchases; installments are separate orders or handled outside the storefront | Handled in Transact's payment plan tools, outside the storefront | Handled in TouchNet's billing tools, outside the storefront |
| Refunds | Issued from the order in Salesforce; the payment summary updates automatically | Issued in CashNet by the bursar, then recorded on the Salesforce order | Issued in TouchNet Marketplace by the bursar, then recorded on the Salesforce order |
| PCI scope | Card data stays with the payment provider; the institution's PCI office confirms the questionnaire level | Card data stays with Transact; the storefront handles no card data | Card data stays with TouchNet; the storefront handles no card data |
| What the learner sees | One page, one brand, no redirect | A redirect to a campus-branded payment page, then a return to the storefront confirmation | A redirect to a campus-branded payment page, then a return to the storefront confirmation |
In every column the storefront, the order, and the receipt are in Salesforce. The columns differ in who holds the money and who presses the refund button.
What Should the Institution Decide Before Building?
Payments cannot be decided by the continuing education unit alone. Three decisions need a name next to them before the build starts, and the discovery that opens the Commerce Accelerator covers all three.
Who Owns the Merchant Account
If the answer is the bursar, the hosted-checkout pattern is settled and the next question is which processor the campus has. If the answer is the unit, Salesforce Payments is open, and the unit needs a bank account for payouts and someone to own the payments workspace. On a few campuses the answer is both: card payments through the campus processor, and a separate Salesforce Payments account for a self-funded unit. That is workable, but it should be chosen in discovery, not discovered in user acceptance testing.
How Refunds Route
A dropped course is the most common reason for a refund. Decide who approves it, who issues it, and where it is recorded. With Salesforce Payments the whole chain can live in Salesforce. With a hosted checkout the bursar issues the refund in the processor, and the storefront needs a step, manual or automated, that updates the order so learner services and the bursar agree. Caroline Hoy covers the details in tax, refunds, and receipts on a university storefront.
How the Campus General Ledger Reconciles
Ask the bursar what report they reconcile from today and what key is on each line. Then make the storefront put that key on every order line. For CashNet campuses it is the item code. For TouchNet campuses it is the accounting code on the uPay site. For Salesforce Payments it is usually a product code or a general ledger field on the product that flows to the order item. The test: the bursar's daily report and the Salesforce order report should match without a spreadsheet in between.
Which Option Fits Which Unit?
- A unit inside a public university with a campus processor. Hosted checkout with the existing processor. Build the signed handoff and the adapter once, then reuse them for every unit that later joins the storefront.
- A private institution whose bursar is open to Salesforce Payments. Native Salesforce Payments. Fewer moving parts, refunds from the order, and one merchant account that can also serve Student Financials later.
- A self-funded unit that already holds its own merchant account. Either works. Salesforce Payments is faster to stand up if the unit will move processors; otherwise a hosted checkout against the current processor keeps the unit's books unchanged.
- A system office standing up a storefront for several campuses. Expect more than one processor. Make the payment step a per-store setting from the start.
The continuing education commerce page describes the rest of the storefront, and the Salesforce Commerce for higher education FAQ answers the shorter questions. Whichever payment path a campus chooses, the pattern holds: the processor stays, and the learner's experience, the order, and the receipt move to where the enrollment record lives. That is the order of operations we expect to keep building through 2027.
Questions We Hear
Do we have to switch from TouchNet or CashNet to use a Salesforce storefront?
No. The storefront hands the learner to the processor's hosted payment page and receives the result back. The bursar's merchant account, settlement, and general ledger feed stay as they are. Salesforce Payments is an option for institutions that want a native checkout, but it is a choice, not a requirement.
Does the learner have to leave the storefront to pay?
With Salesforce Payments, no; the card fields sit on the checkout page. With a hosted checkout, yes, for the payment step only. The learner is redirected to a campus-branded page, pays, and returns to the storefront's confirmation page. Learners already recognize that page from paying tuition, which helps.
Can one storefront use more than one payment method?
Yes. Payment configuration is per store in Salesforce Commerce, and a single org can run several stores. A system office can run one store on Salesforce Payments and another on TouchNet. Within a single store, the common design is one processor for cards plus an invoice or purchase-order path for corporate buyers.
Where does the order live if the payment happens in CashNet?
In Salesforce. The storefront creates the order before the redirect, and the post-authorization adapter writes the payment result to the order's payment summary when CashNet returns the result. CashNet holds the transaction record for the bursar; Salesforce holds the order, the learner, and the enrollment.
How are refunds handled with a hosted checkout?
The bursar issues the refund in the processor, because that is where the money is. The storefront needs a step that records the refund on the Salesforce order so that learner services, the enrollment record, and the bursar agree. That step can be a screen flow for the registrar's team or an automated update from the processor's report.
Is a payment adapter custom code we will have to maintain?
It is a small Apex class that implements an interface Salesforce documents in the Commerce developer guide. We keep it thin: it validates the returned result, writes it to the order, and nothing else. Business rules, such as what happens to the enrollment when payment succeeds, stay in Flow where an administrator can read them.