The connections a school actually needs, and no marketplace of logos
Payment gateways, WhatsApp and DLT-registered SMS, biometric attendance devices, accounting exports, a REST API and webhooks. Listed with what each one actually does, and what it does not.
Four gateways, and the reconciliation attached
A gateway integration that takes money is easy. What matters is that the settlement, the receipt and the ledger entry are linked afterwards, so “I already paid” takes ten seconds to answer with a transaction reference.
WhatsApp, SMS and e-mail — and the Indian rule that decides whether SMS works
This is the integration schools are most often misled about. In India, transactional SMS must be sent on a DLT-registered template. An unregistered message is dropped by the operator without an error, which means software can honestly report “sent” while nothing arrived on a single phone. We therefore require an approved template before a campaign can send, and we show you the delivery report rather than the send log.
- 01 WhatsApp Business API Template-based messages for fee reminders, absence alerts, results and notices, with delivery and read status. Your own WhatsApp Business number.
- 02 DLT-registered SMS Through your SMS provider, with the sender ID and template IDs registered on DLT. Templates are mandatory in the software, which is inconvenient once and reliable afterwards.
- 03 SMTP e-mail Your own SMTP or a transactional provider, so mail comes from your domain and does not land in spam as a shared sender would.
- 04 Voice call templates For schools that use automated voice announcements, on the same template discipline.
- 05 Delivery reports, not send logs The number that tells you the truth is on the same screen as the campaign, deliberately.
Hardware, with an honest answer about compatibility
Device integration is where vague promises cost schools money. The right time to check a make and model is before you buy, so bring yours to the call and we will confirm rather than assume.
Most schools stop using Tally. Some CAs would rather not.
Because the fee module posts to a real double-entry general ledger with periods that close, the statutory statements come out of this system and a separate accounting package becomes unnecessary. In practice that is not always the decision a school gets to make — so the export exists for the CA who wants their own copy.
- 01 A complete general ledger here Trial balance, income and expenditure, balance sheet, day book, account ledgers and cash flow, all generated from posted journals rather than summed from receipts.
- 02 Tally-compatible export Vouchers and masters in the XML format Tally imports, so your CA can carry a period across without re-entry.
- 03 CSV for everything else Journals, ledgers and trial balance as CSV for any other package or for a spreadsheet review.
- 04 GST and TDS reports The data your CA needs for the returns. We compute correctly; we do not file on your behalf, and we would rather say so than imply a compliance guarantee.
Your data, programmatically
A REST API and outbound webhooks, available on plans that include API access. Built for the two things schools actually ask for: pushing enquiries into a CRM, and pulling data into a reporting tool of their own.
Integration questions
Something not answered here?
Will you integrate with the specific software we already use?
Do you charge for integrations?
Can we use our own payment gateway account?
Why do you insist on a DLT-registered SMS template?
Will our existing biometric devices work?
Do we still need Tally?
Is the API on every plan?
Can new signups and enquiries reach our CRM automatically?
Bring the list of what you already use
Gateway, SMS provider, biometric model, accounting package, CRM. Twenty minutes and you will have a specific answer on each one, including where the answer is no.
- No card required
- Your data stays yours — export any time
- Setup help included