In February 2026, Transact+CBORD (the company has since rebranded as Illumia) announced a partnership with MyVenue to bring stored-value payment rails into stadiums and large-venue environments. The deal means students and fans can tap their campus credentials at concession stands, merchandise kiosks, and event gates — the same way they tap at a dining hall register. It’s a signal that campus commerce is no longer confined to the meal plan swipe. The infrastructure is expanding, and fast.
For dining directors and IT leaders, this raises a practical question: if the rails are getting longer, who’s building the bridges?
The answer isn’t to rip out your existing POS system or rewrite your campus card integration. It’s to connect what you already have into a unified experience that students can actually use. That’s the integration challenge most campuses are still solving — and it’s the one that will define dining satisfaction for the next decade.
The Transact+CBORD MyVenue Deal: What It Actually Means
Transact Campus and CBORD merged in 2024 to form the dominant platform for campus credentialing, meal plan management, and stored-value transactions. The combined company rebranded as Illumia in 2026. Their combined footprint covers over 1,500 institutions. The MyVenue partnership extends that footprint into stadiums, arenas, and entertainment venues — environments where stored value has historically been friction-heavy or nonexistent.
The mechanics are straightforward: MyVenue’s point-of-sale and payment infrastructure connects to Transact+CBORD’s stored-value rails. A student’s campus ID, which already holds declining balance dollars and meal swipes, can now be used at a football stadium concession stand without a separate app, card, or payment method. The credential travels. The balance is shared. The transaction is instant.
What makes this significant for campus dining isn’t the stadium use case itself — most dining directors aren’t running concession stands. It’s the precedent. Stored value is becoming a portable layer that sits on top of existing systems. The campus card is no longer just a meal plan token. It’s a commerce credential that can move across venues, devices, and contexts.
That shift has direct implications for how campuses think about their dining technology stack.
The Integration Reality on Most Campuses
Walk into any campus dining operation and you’ll find a layered stack of systems that were never designed to talk to each other. The POS terminal might be from one vendor. The meal plan engine is likely powered by CBORD (now part of Illumia) or a legacy equivalent. The campus card system runs on Transact or Blackboard. FoodPro, Computrition, JAMIX, or a similar back-of-house system manages inventory and production. The nutrition database lives in yet another platform.
Each system does its job. The problem is the seams between them.
When a student wants to check their meal plan balance, they might need to log into a portal that looks like it was built in 2009. When they want to see what’s served at the dining hall tonight, they’re checking a PDF menu posted on a website. When they want to understand the nutritional content of their meal, they’re Googling ingredients. None of these experiences are connected to the POS, the card system, or each other.
The result is a fragmented student experience layered on top of a functional-but-invisible back end. The kitchen works. The register works. The card works. But the student’s relationship with campus dining is mediated by disconnected touchpoints that create friction at every step.
This is the gap that integration needs to close — not by replacing the POS or the meal plan engine, but by building a student-facing layer that connects to all of them.
What “Integration” Actually Means in Campus Dining
Integration in campus dining isn’t a single API call. It’s a multi-system orchestration problem that touches at least four distinct layers.
POS Integration
The point-of-sale system is the transaction layer. Every swipe, tap, and purchase flows through it. Integrating with the POS means reading transaction data in real time, understanding purchase patterns, and surfacing that information to students and administrators. It also means being able to push data back — menu items, pricing changes, location hours — without requiring a POS terminal update.
Most POS vendors in campus dining (including brands like Micros, Toast, and custom CBORD configurations) expose some form of API or data export. The challenge is normalization. Each campus configures its POS differently, with different item codes, modifier structures, and reporting hierarchies. A real integration layer needs to handle that variability without requiring custom development for every deployment.
Campus Card and Meal Plan Rails
The campus card system is the identity and payment layer. It knows who the student is, what meal plan they’re on, and how much declining balance they have left. Transact+CBORD’s (now Illumia’s) dominance in this space means most campuses are working with a common set of credential and stored-value protocols.
Integration here means reading meal plan balances and transaction history, validating credentials for campus-specific features (like guest swipes or dietary accommodations), and ensuring that any student-facing experience respects the same authorization rules that the card system enforces.
The MyVenue partnership is relevant because it demonstrates that Transact+CBORD’s (now Illumia’s) rails are designed to be extended. The same stored-value infrastructure that powers dining hall transactions can power stadium purchases, laundry machines, and vending. A student-facing app that integrates with those rails can surface a unified view of where and how a student’s campus dollars are being spent.
Back-of-House Systems
FoodPro, CBORD, Computrition, JAMIX, and similar platforms manage the operational side of dining: production schedules, inventory levels, recipe costing, and HACCP compliance. These systems are the source of truth for what’s being prepared, when, and in what quantity.
Integration with back-of-house systems enables real-time menu accuracy. When a dining hall runs out of a menu item, the student-facing layer should know immediately. When a recipe changes — a new allergen is introduced, a substitution is made — the nutritional data should update without a manual re-entry.
This is the layer most campuses have historically ignored in their student-facing technology. The back of house stays behind the kitchen doors, and students get whatever information was manually published at the start of the day. Closing that loop is one of the highest-impact integrations available.
Nutrition and Dietary Data
Students increasingly expect nutritional transparency — not just calorie counts, but macronutrient breakdowns, allergen flags, and dietary preference filters (halal, kosher, vegan, gluten-free). That data typically lives in recipe management systems or nutrition databases, but it’s rarely surfaced to students in a usable format.
Integration means pulling nutrition data from the source system and presenting it in a way that students can filter, search, and act on. It also means keeping that data current as recipes change and ingredients shift throughout the semester.
The Case for a Student-Facing Integration Layer
The reason campuses need a dedicated student-facing layer — rather than just exposing raw APIs to students — is that the back-end systems were designed for operators, not end users.
A POS system is optimized for transaction speed and reporting accuracy. A campus card system is optimized for credential management and financial compliance. A back-of-house system is optimized for production planning and food safety. None of them were designed to answer the question a student asks at 11:45 AM: “What’s for lunch, and can I eat it?”
That question requires data from all four layers, synthesized into a single experience. The student doesn’t care which system the menu comes from or which API provides the allergen data. They care about whether the dining hall has something they can eat, how much it costs, and whether their meal plan can cover it.
A student-facing integration layer sits between the back-end systems and the student’s device. It reads from the POS, the card system, the back-of-house platform, and the nutrition database. It normalizes that data, applies campus-specific business rules, and presents it through an interface that students actually want to use.
This is the architecture that scales. You don’t need to replace your POS when you upgrade your student app. You don’t need to migrate off CBORD when you add dietary filtering. You don’t need to rewrite your FoodPro integration when a new campus opens. The integration layer absorbs the variability and presents a stable interface to students.
What This Means for Campus Dining Leaders
The Transact+CBORD (now Illumia) MyVenue partnership is a leading indicator. Stored value is becoming a portable, cross-venue layer. Campus credentials are becoming commerce credentials. The infrastructure is getting more capable, more connected, and more standardized.
But infrastructure alone doesn’t improve the student experience. Students don’t see the stored-value rails or the POS middleware. They see the app on their phone. They see the menu on the screen. They see the balance in their account. The quality of that surface layer — and its ability to connect to everything underneath — is what determines whether students feel served or frustrated.
For dining directors, the integration question isn’t whether to connect systems. It’s how to connect them in a way that’s maintainable, scalable, and student-centered. That means choosing a student-facing platform that was built for integration from day one — one that treats your existing POS, campus card, and back-of-house systems as partners, not obstacles.
Dining Connect is that platform. Our integration architecture connects to the campus systems you already run — Transact, CBORD, FoodPro, Computrition, JAMIX, and your POS layer — and gives students a branded app with real-time menus, nutrition tracking, and meal plan visibility, all on top of the infrastructure your team has already built. We don’t replace your stack. We make it visible to the people who matter most: your students.