Student fee view
Total fees, paid amount, outstanding balance and payment status, with transaction dates, references and available receipts.
The connected systems view
Separate systems.
Shared context.
Keep the source of truth clear. Bring the information your teams need into the workflow.
Explore the integration blueprint ↓matra vedaInstitutional context
Fee REST APIEmail / SMTPBiometric attendanceSMS gatewayPayment gateway
Identity mapping · Permissions · Exception review
Conceptual view; connections depend on agreed scope and provider support.
People behind the connections
Shared systems.
Shared understanding.
A connected system supports the people who use it every day. Clinical teams, administrators and IT staff need a clear view of what is current, what is missing and who will resolve it.
- Agree how patient and student identities are matched across systems.
- Give authorised teams visibility into the latest successful synchronisation.
- Route missing or rejected records to a named owner for review.
Fee management
integration.
The existing fee system remains the financial source of record, connected through its REST API.
Administrative fee view
Filters by year, department, course and payment status; outstanding summaries and collection views.
Synchronization visibility
Mapped student IDs, API connection status, refresh, last successful sync and records with synchronization errors.
Financial authority
External fee records remain controlled by the existing fee system. Payment initiation follows the agreed gateway and API scope.
The integration
workspace.
Relevant status and history for each connected service.
Email / SMTP
Sender configuration, notification categories, delivery history and test-connection controls.
Biometric attendance
Device/provider status, received attendance records, synchronization timestamps and failed records.
SMS gateway
Provider and sender configuration, notification categories, delivery history and status.
Payment gateway
Provider status, transaction references, success and failure counts and synchronization visibility.
Integration health
Connected, Disconnected, Configuration Required and Sync Error states. Production credentials remain protected on the server.
The integration blueprint
Connect with purpose.
Check every exchange.
A successful connection needs more than an API: a clear source of truth, reliable identity mapping and visible exception handling.
Define the authority
Agree which system owns each record, field and correction. Keep financial edits with the authorised financial source.
Make failures visible
Track last sync, rejected records and provider errors. Route unresolved exchanges to a responsible administrator.
Protect the context
Scope permissions and data exchange to the approved workflow. Confirm vendor support before promising interoperability.
Additional connections to assess
Keep each service
connected to its owner.
Extend the integration review beyond payments and attendance when the institution needs a broader campus and learning workflow.
Learning & library systems
Agree student identity, course mapping and the limited progress or clearance information to exchange.
See learning requirements ↗Hospital & clinical learning
Define the permitted link between student postings and the teaching hospital. Keep educational and clinical permissions explicit.
See clinical learning ↗Finance & campus services
Review scholarship adjustments, service charges and payroll connections. Preserve the authoritative financial system.
See service requirements ↗Provider APIs, data permissions and vendor cooperation must be verified. These connections are assessment areas, not confirmed live integrations.
Frequently asked questions
Clear answers.
Before the next step.
Understand the scope, dependencies and decisions that matter for your institution.
Can Matra Health connect to our existing systems?
The integration scope covers fee records, email, biometric attendance, SMS and payment gateways. A live connection depends on the provider API, identity mapping, credentials, permissions and vendor cooperation.
Does the ERP replace our existing finance system?
The described integration preserves the existing fee system as the financial source of record. ERP views show permitted payment and balance information. Any payment initiation or financial changes need a separately agreed scope.
Are synchronised records always real time?
Update frequency depends on the provider and integration design. Agree refresh intervals, last-successful-sync visibility and how rejected or delayed records are resolved; do not assume every service supports instant updates.
Can we connect an LMS, library system or teaching hospital?
These are additional integration areas to assess. Define the limited data to exchange, the responsible system and the permissions. A teaching-hospital link needs explicit separation of educational and clinical access.
Explore the fit for your institution.
Start with your workflows, current systems and priorities.