🪔Puja & Bookings

Yes. Temple Hub runs on any iPad in a counter-top stand as a full front-desk point of sale — no proprietary hardware to buy. Staff can charge pujas, donations, memberships and facility bookings with cash, card, or split tender, reconcile the cash drawer at the end of each shift, and the same stand can flip to a devotee self-service mode for check-in and donations. A secure stand locks it to the counter and swivels for the devotee to sign or tap to pay. Contact us for a kiosk demo.

You can configure any puja type — archana, abhishekam, homam, sevas, and custom services — each with its own pricing, duration, priest requirements, and materials list. Devotees can browse and book these services directly from their portal.

The Bookings tile lets admins view, manage, and update all puja and facility reservations in one place. You can see upcoming bookings, check devotee details, and coordinate with priests — all without switching between systems.

Yes. Devotees can book pujas on behalf of any family member in their profile. All bookings appear in the devotee's order history and in the admin's Finance Dashboard tile for easy tracking and refund management.

The Finance Dashboard tile gives admins a full view of all devotee puja orders — including payment details, service records, and order status. Admins can issue refunds directly from this tile without needing to contact the payment provider separately. It opens as a full-screen three-frame console (like the Bookings POS): a left navigator rail with section jump-links — clicking Trends & Compare expands one-click Quick Range buttons (Today, Last 7 Days, This Month, This Quarter, This Year, All Time) below it, and clicking Revenue Analytics expands a Filter View and Revenue View picker right below it that drive the center breakdown and ledger, with a badge showing how many filter rules are active; the center holding all metrics, charts and the transaction ledger at full width, with the transaction search box in the ledger header; and a collapsible right-hand Finance Snapshot (slide it open or closed with its arrow button) showing what the center doesn't: a payment-mix bar, a Needs Attention list of anomaly flags (high refund rate, cash variance, drawer over/short, complimentary orders), Range Highlights (top service, top contributor, peak revenue day), and Export PDF/Excel buttons. Under 1280px wide (phones, tablets, small laptops) the right rail is replaced by a Finance Snapshot card in the page, just above Open Shifts. Its Needs Attention flags are never out of sight, and the header's Export button takes you to its Export PDF / Excel buttons. From 1280px up, the header has direct PDF and Excel buttons. Below 768px the left rail hides too, and the Filters & Tools card, with the Revenue Analytics views as one-tap chips, appears above the revenue breakdown instead. The Revenue Trends graph has its Daily / Weekly / Monthly switch in its top-left corner. Hover over the graph, or tap it on a touch screen, to see each point's figures. Key metrics for the selected date range include Gross Sales, Refunds, Net Revenue, Order Volume, Average Order, plus Donations (and their share of revenue), Tax-Exempt total, Refund Rate, and Cash vs Card collected. Right below the Net Revenue banner, a live "Today at a glance" bar shows the temple's current day (in the temple's timezone, whatever range is selected): how many sales each of the temple's own categories (named exactly as on its Categories page), plus Canteen, Store and Event, has taken and for how much — one tile per category that has sold today (categories with no sales yet are hidden; a category the temple adds later gets its own tile automatically; an Uncategorized tile appears only when a sale matches no category), updating within seconds of each sale; refunds, deposits and drawer adjustments are not counted as sales. The money tiles below it are grouped: Collections (Cash Collected, Card Collected, Donations, Tax-Deductible) is always open, while Orders & Refunds, Fees & Tax, and Cash Drawer & Deposits fold away behind an arrow and show their headline figures while closed. A collapsible Business Analytics section (closed by default; click its arrow to open) adds derived insight metrics for the finance/BI team: Net Margin (net ÷ gross), Daily Average run-rate, a linear Projected Month total, Median Order (outlier-robust vs the average), Unique Devotees and revenue per devotee, Repeat-Devotee Revenue Share, Online vs Front-Desk share, Complimentary and Tax-Exempt shares, and Cash Variance (drawer over/short as a percentage of cash handled). Every figure respects the active date range and filters and updates in real time.

The Finance Dashboard's Revenue Analytics section breaks collections down several ways: By Payment Channel (the tender — cash, card terminal, online card, split, check, complimentary), By Source (Temple Website self-service vs the admin Front Desk/POS), By Category, By Service, By Devotee, By Priest, By Collector / Cashier, and By Time of Day. The "By Devotee" view is a contributor leaderboard showing how much each devotee has paid, along with the number of unique devotees and the average given per devotee — handy for recognizing top supporters and for year-end acknowledgements. Tap or click any row to filter the transaction ledger by it. In By Category, tapping a category opens its services, and the filter button beside it filters by the whole category. On a phone each row becomes a two-line card showing the full name, amount, share and order count. Cash-drawer reconciliation entries (shift over/short) are excluded from every breakdown and from Gross/Net revenue — they appear only in the dedicated "Drawer Over/Short" card and the ledger, since they are internal adjustments rather than sales. The one exception: extra cash converted to a general donation at shift close counts as real Cash + Donation revenue. Store and canteen sales appear in every view: under their tender in By Payment Channel (cash, card, split), as Front Desk in By Source, and as their own categories in By Category. The Donations card counts website donations as well as front-desk ones, and the Tax-Deductible card shows what will reach tax letters under Booking Rules → Receipts & Tax.

They answer different questions. By Source is a two-bucket split of where the sale originated: Temple Website (the devotee paid online themselves) vs Front Desk (POS) (a staff member collected it at the desk, whatever the tender). By Collector / Cashier breaks the front-desk bucket down to the individual person who collected each payment — useful for per-cashier accountability and matching each cashier's total against their shift reconciliation; website orders appear there as "Online / Self-Service". In short: Source tells you whether the temple or the devotee ran the transaction; Collector tells you which staff member's hands the money passed through — and Source's Front Desk total should equal the sum of all human collectors.

Yes. Both use one pricing rule: an active member pays the member price, and everyone else pays the non-member price, or the member price when no non-member price is set. Both also offer the same booking times: the service's own times when it has any, otherwise the temple's hourly grid, and in either case only inside the temple's operating hours for that date when Booking Rules "Respect temple timings" is on. A time set on a service outside the temple's hours is therefore not offered anywhere.

Staff are never asked to charge the card again, and the record is kept. Temple Hub keeps retrying the save for about 15 seconds. If it still cannot save, the screen changes to "Card charged — not recorded yet" and shows the Receipt No, the amount and the card's last four digits. The card form is removed, so the same sale cannot be charged twice. Staff press "Retry saving" to record it. If the screen is closed first, the device keeps a copy and saves it automatically the next time a payment screen opens for that temple. This applies at the Bookings counter, the Canteen, Catering, the Store, and the website donation page.

Temple Hub quietly retries the load for a few seconds first, which clears most busy moments. If it still can't load, a "Some information didn't load" banner appears at the top of the admin screen with a Reload button, so an empty list is never mistaken for "nothing here". The Canteen Orders, Kitchen, Store Sell and event check-in screens keep what they already show when a refresh fails, add a notice with a Retry button, and say a scan or search "couldn't check" instead of saying the order, product or signup doesn't exist.

Yes. The Finance Dashboard reports sales under each temple's own categories — the ones on its Categories page, with the names the temple gave them — plus Canteen, Store and Event. Add a category and it gets its own tile in "Today at a glance", its own row in Revenue Analytics → By Category, and its own choice in the ledger's Category filter with its first sale, with nothing to set up. Every order records its category when it is paid, so a sale keeps its category even if the service is later moved to a different one. Website donations are reported under the category chosen in Booking Rules → Order Records → "Donation page category" (the category named "Donation" until one is chosen). A sale that matches no category shows in an Uncategorized tile and under Needs Attention until its service is given a category. Categories are for reporting only — they never change how a payment is treated on receipts or IRS statements, which follow Booking Rules → Receipts & Tax.

So it stays fast at a busy counter. The Orders screen opens on "Today", which loads only the temple's current day instead of every order ever taken, so each refresh is quick no matter how much history builds up. Choose "All days" to load earlier orders; it is slower, so switch back to "Today" for the counter. An unfinished order from an earlier day appears only under "All days", and the bell counts today's orders only. Scanning an order's code still finds an older order, because the scanner checks the full history before saying it doesn't exist.

It is a payment the temple received before it used Temple Hub — for example cash, checks or another system — loaded from the temple's own spreadsheet when the temple joined. It is linked to the devotee's profile, dated on the original payment day, and recorded as paid, so it counts toward the devotee's giving and appears on their yearly tax letter when it is a donation. Because Temple Hub did not take the payment, an imported order cannot be refunded or cancelled; the refund and cancel buttons are not offered for it.

Each part goes back the way it was paid: the card part to the card, and the cash part in cash from the refunding staff member's open cash drawer. The refund screen shows every payment method on its own row with what was paid, what has already been refunded and what can still be refunded, so a split payment of $60 by card and $40 in cash shows $60 refundable to the card and $40 in cash. The cash that can be refunded is the cash the temple kept for that order — change handed back, and change the devotee chose to donate, is never refunded again. By default a refund goes to the card first; staff can move part of it to cash, up to the cash refundable. One approval code covers both parts. A SuperAdmin can also hand a card payment back in cash when the card itself cannot take the refund, for example a closed or replaced card. Payments by check, Zelle, Venmo or another method are refunded in cash from the drawer by default, or the same way they came in (a check issued or a transfer sent), recorded with its check number or confirmation. Reservations held without payment have nothing to refund.

Every payment shows one number to people: the Receipt No (e.g. TXN-2610-POS-7K3Q9MX). It is built as TXN, then the year and month (2610 = October 2026), then where the payment was taken (POS = temple counter, STR = store, CAN = canteen, WEB = website or devotee portal), then a 7-character random code. It appears on printed receipts, receipt emails and the devotee's receipt view, and it is what you search for at the counter. The Order ID (e.g. order-mr61iegvrm8w) is the internal database ID of the order itself; it exists even before payment and is shown in Transaction Details for audits. Card payments also store the processor's own references: Square's Payment ID (Square also stores the Receipt No as its reference, so Square reports show the same number), or for Datacap a numeric Gateway Ref plus the Ref No and Auth Code that Datacap returns. Those are used for settlement and refunds, never printed on the receipt. A cash-change donation is logged with a "-D" suffix (TXN-2610-POS-7K3Q9MX-D) so it traces to its parent payment. Older records may also show a separate Invoice No; new payments no longer create one because it was always identical to the Receipt No. Older receipts in the short TXN-LL7Q55 style remain valid and searchable. The same Receipt No appears on the devotee's annual tax statement and in My Profile on the temple website, so every number matches across receipt, statement and ledger.

Yes. In Confirm Payment Details, choose the "Other" mode (next to Cash / Card / Split) and pick the method — Check, Zelle, Venmo, PayPal, Cash App, Bank Transfer, or Other. Enter the reference or confirmation number and attach a required proof image (take a photo or upload a screenshot). The payment is recorded as a paid order, so it appears in the Finance Dashboard and the devotee's profile, and an acknowledgment is emailed to the devotee and can be printed. The proof image is viewable only by Finance, SuperAdmin, and the cashier who collected it. For checks, automatic scanning of the check number and amount is planned in a later update.

The Bookings tile opens a full-screen point-of-sale (POS) view built for the temple front desk. Staff pick puja or facility services from a category-organized store, attach the devotee (search, add new, or continue as guest), choose the date and time, and take payment — cash with change calculation, card, split cash+card, complimentary, or "Other" methods like check and Zelle. The same screen manages existing reservations (collect payment, reschedule, reassign priest, cancel, holds with expiry countdowns), shows order history with refunds, and runs the cashier shift: opening cash count, live cash/card totals, and end-of-shift reconciliation with a printable closing receipt. Records where money moved (paid, refunded, or complimentary) can never be deleted — they are retained permanently for financial reporting and audit; only never-paid rows such as expired holds or unpaid cancellations can be cleaned up.

Yes, if the temple turns it on — it is a per-temple setting. Under Temple Setup → Booking Rules → Holds, the "Allow reserve without payment" rule controls it: when it's on, a booking can be saved On Hold for a devotee with no payment collected — the date is blocked, a hold expiry counts down, and payment is taken later when the devotee confirms. When the rule is off, payment is required at booking time and the Save-on-Hold and Reserve options disappear from the POS entirely. A Reservation Policy panel in the same section fine-tunes it: which services may be reserved (all, only chosen categories, only chosen services, or none), whether a reservation needs admin approval before the devotee can pay (never, always, facilities only, or only above a set dollar amount), how long an unpaid reservation lasts, the maximum number of open reservations one devotee may hold, and whether reserving is members-only. When approval is required, a devotee's website reservation lands in Bookings → Active marked "Awaiting approval"; a SuperAdmin or Admin taps Approve (or Reject with a reason) — only after approval does the "Pay Now" button appear on the devotee's dashboard for that booking, and the devotee is emailed either way. Pair it with "Auto-expire on-hold bookings" so unpaid reservations cancel themselves after the window.

The reservation lands in the admin Bookings screen (Active tab) with an "⏳ Awaiting approval" badge. Admins and SuperAdmins see ✓ Approve and ✕ Reject buttons on the row — other roles don't. Approving emails the devotee and unlocks Pay Now on their website dashboard, and the row shows "✓ Approved · awaiting payment" until they pay. Rejecting requires a written reason, which is emailed to the devotee along with a push notification, and the booking is cancelled. Every decision — who approved or rejected, when, and why — is recorded in the audit log.

Yes. Shifts are per-admin: each cashier starts their own shift with their own opening cash count, and any number of shifts can be open at once. Every POS payment is tagged with the shift that collected it, so at End Shift the expected totals are derived directly from that shift's orders — one admin's drawer never mixes with another's. Cash drawers are configured under Settings → Add Setting → "Cash Drawer / Counter" (one row per physical box, e.g. "Front Desk 1", "Floor 2"); at Start Shift the cashier picks their drawer from a dropdown, a drawer already in use shows as taken and can't be claimed twice, and the drawer remembers its float — the closing count left in the box pre-fills the opening count for whoever runs that drawer next, whoever they are. The drawer name appears on the shift bar, printed labels, and the reconciliation record. Temples that configure no drawers can still type a free-text label. For counters where several cashiers genuinely work one box at once (e.g. a festival counter), mark the drawer "Shared" in its setting: it stays selectable while in use ("in use — join"), the first shift carries the opening float (joiners start at $0 unless they add cash), and the last shift to close counts the box against the whole group's collections — with the trade-off, stated plainly, that any over/short belongs to the group rather than one person. If an admin accidentally starts a shift on a second device, the POS adopts their existing open shift instead of creating a duplicate. The Finance Dashboard shows an "Open Shifts" panel listing every open drawer with its running totals and a combined expected-cash figure for the treasurer. Best practice: one login per person, one cash box per login — never share an admin account between two people.

Yes. The Facility Services tile lets devotees and admins book the temple hall, kitchen, and other shared spaces. These reservations appear alongside puja bookings in the main Bookings tile so admins always have a unified view. When booking a facility at the front desk, staff pick the required duration/rate for the space and can optionally add In-Temple priest services to the same reservation — the calendar automatically blocks dates the chosen priest is already booked.

Yes. Admins add each item once under Temple Setup → Equipment & Add-ons with the quantity the temple owns (e.g., Wireless Mic × 2), a price, and whether it is a shared pool or fixed to one space. Devotees then add items with quantity steppers on the website or at the front desk; availability is counted per time slot, so a request that would go over what the temple owns is refused before payment. Equipment is taxed and itemised on receipts like any other part of the sale, and can carry a refundable deposit set in Booking Rules → Deposits & Fees.

Yes. Booking Rules has a live Policy Summary — on a wide screen it sits on the right, and on tablets and phones a "Summary" button opens it as a drawer or bottom sheet; tapping any heading jumps to that section's settings. It covers every section: scheduling and access rules, capacity, blackout dates, plan limits, lead times, offers, reservations, who can issue refunds, security deposits, priest breakout fees, cancellation and reschedule fees, order records, the rental agreement, receipts and tax treatment, canteen spend and loyalty, and Contribution Standing. It updates as you edit, even before you save. Click "Copy" to copy the full policy as plain text — including each staff role's refund permission, every deposit and fee, and the IRS treatment of every payment category — to paste into board minutes, an email or your records.

Yes, with Contribution Standing — an optional cumulative value indicator, off by default, that a SuperAdmin sets up under Booking Rules → Contribution Standing. Every temple's bylaws differ, so nothing is hard-coded: you choose which payment categories count (the same categories as Receipts & Tax; only Donations by default), whether fees and tax are excluded, the time window (lifetime, calendar years, fiscal years, or rolling months), and how amounts combine (a running total, a single payment, or the target met every year). You then define named tiers such as Annual, Life or Patron and what each tier unlocks — voting rights, board candidacy, member pricing, recognition and more. Each choice explains in one line what will happen. Temple Hub calculates a recommendation from your rules; your bylaws decide and your board certifies any voter list.

Yes. Besides a simple total, Contribution Standing can weight each category differently (for example, donations at 100% and pujas at 50%), count recent years more than older ones, use an average or weighted average per year (optionally dropping the lowest year, or counting only the years since a devotee joined), or convert dollars and volunteer hours into points. A category limit can cap how much of a score any one category supplies. Tiers can be reached at a fixed score, at a percentage of the target (for example 80%), or by ranking — such as the top 10% of devotees — which is fixed once the voter roll is frozen.

Once Contribution Standing is on, three places show it. A devotee's Bookings view in Manage Devotees has a Contribution Standing card with their tier, a Qualified or Pending check badge, their votes and voter pool, and a progress bar to the next tier; "Why?" lists every payment with the reason it did or didn't count. A Contribution Standing panel at the top of Manage Devotees lists every devotee's tier, with filters for each tier, eligible voters, pending checks and payments that need attribution. And every order's details show whether that payment counts and who receives the credit. Admins confirm manual checks, such as signing the bylaws, right on the card, and each confirmation is recorded in System Logs. Score amounts are shown only to the staff roles the temple chooses; other staff see the tier only.

Yes. A SuperAdmin opens Manage Devotees → Contribution Standing → Voter roll and clicks "Freeze voter roll". The frozen roll is a snapshot of every devotee's tier, status, votes and voter pool, together with the rules in force that day — later refunds, payments or rule changes never alter it. Each roll can be exported to Excel or PDF for the election committee. Unfreezing requires a SuperAdmin and a written reason, and the original rows are kept. Freezing, unfreezing and exporting are all recorded in System Logs. If you set a yearly cutoff date, a reminder appears once it passes until a roll is frozen. Before any change to the Contribution Standing rules is saved, Temple Hub shows how many devotees it would move between tiers, and lists them.

Yes, if the temple allows it. When "Devotees see their own standing" is on under Booking Rules → Contribution Standing → Who sees what, a "My Standing" card appears on My Profile on the temple website. It shows the devotee's tier, a Qualified, Pending or Inactive status, their votes and voter pool, progress to the next tier and any renewal due, plus "How is this calculated?" listing their own payments and the reason each did or didn't count. Devotees only ever see their own record: a household tier shows the household's combined total but never a spouse's or relative's individual gifts. The temple can hide dollar amounts or the next-tier hint, or turn the card off entirely.

From Temple Member Profiles. Each profile has a "Paid staff (salary or stipend)" switch — turn it on for salaried priests and office staff, and leave it off for volunteers and unpaid board members. When a temple turns on Contribution Standing's "Not a paid staff member or priest" check, a devotee whose email matches a paid-staff profile automatically fails it, and everyone else passes with no manual tick. Login roles in Manage Users are not used, because a volunteer can hold an Admin login without being paid. An admin can override a single devotee with a written reason, such as pay that has ended, and every override is recorded in System Logs.

Yes, optionally. When renewal is required, each devotee with a tier must be renewed for the year — by an admin's "Renew" button on their profile, or automatically by a counted payment that year or an active Yearly or Lifetime membership, if the temple chooses automatic renewal. Devotees not renewed by the renew-by date plus any grace period show as Inactive: their tier stays on record but carries no votes until they renew, and nobody is removed. Admins can email renewal reminders, and tier-change notices after freezing a new roll, from the Voter roll tab — emails go out only when an admin confirms.

A payment made by a Company profile in Manage Devotees is credited to the company's primary owner by default — the owner with the largest ownership share. A temple can instead split the credit by each owner's share or not count business payments at all, and can cap how much one business counts per year. A tier can also be earned by an individual or pooled across a household, with one vote, a fixed number of votes, or a vote for each eligible adult. Standing credit is separate from tax receipts: a business's payment is always receipted to the business. Every change to these settings is recorded in System Logs.

Admins can assign priests to specific pujas, sevas, and events and manage their shifts. Each priest gets a personal schedule of their upcoming services, so they always know what they are assigned to and when. Priest assignments also flow into each priest's personal schedule, into the Temple Calendar's Bookings filter (visible to SuperAdmins and to any role granted the Bookings tile in Tile Access), and into finance reporting, where you can see revenue attributed to each priest.

Yes. Memberships are sold like any other service at the front-desk Bookings POS. Create a service with the category "Membership" and the subcategory "Yearly" (or "Annual") or "Lifetime", set its price, and it appears in the POS store. When the membership is paid — cash, card, or other methods — the devotee's profile is updated automatically: yearly memberships get an expiry date one year from purchase (renewing early extends from the current expiry, so no paid time is lost), and lifetime memberships never expire. A membership can only be sold to a devotee profile, never to a guest — the POS asks the cashier to select or create the devotee first.

Every service can carry two prices: a Member Price and a Non-Member Price. The Bookings POS checks the selected devotee's membership status automatically — active members (yearly not yet expired, or lifetime) are charged the Member Price, everyone else the Non-Member Price. If a service has no Non-Member Price configured, everyone pays the Member Price, so nothing changes until you fill in non-member prices. The devotee's status ("Member until …", "Lifetime member", or "Not a member") is shown right on the POS cart when they are selected.

Every devotee profile in Manage Devotees has a Membership tab showing their status: "Not a Member", the membership start date, and — for yearly members — the expiry date. The same status also appears as a column in the devotee list and on the POS cart when the devotee is selected for a booking. These fields are read-only: they are set automatically when a membership is purchased at the Bookings POS. Manual grants for legacy or complimentary members (with full audit logging) are planned for a later update.

Yes. Under Temple Setup → Booking Rules, the "Offers & Concessions" section lets admins create offers: a percentage or fixed-dollar discount, optionally with a minimum order value, a validity date range, a members-only or non-members-only restriction, specific service categories, or a repeat-visit condition (the devotee has a prior paid order within a chosen number of days — the classic "second visit within 2 days" concession). With multiple offers you decide exactly which ones may combine; when they do, each percentage is calculated on the original order value, never compounded. Discounts always apply to the original price, and sales tax and card fees are then calculated on the discounted amount. Offers never apply to Membership purchases or Donations. At the front desk, staff tap "Check Offers" in the POS order column: every offer appears as a tile showing the order cost with and without the offer — eligible offers apply to the total instantly, and offers the devotee doesn't qualify for yet still show the potential savings alongside the reason (a gentle nudge to qualify). Non-members see a "Become a Member" button right in the panel: choosing Yearly or Lifetime adds the membership to the same order and immediately unlocks member pricing and member-only offers for it. The receipt shows the original amount, the discount, and the amount charged.

Booking Rules → "Deposits & Fees" holds ONE list for both spaces and equipment — a hall can carry a $300 deposit and a wireless mic a $20 one, picked from the same dropdown. Deposits are never charged at booking: the devotee's card is kept on file (or they leave a check/cash deposit), and an admin charges or releases it after the event. The same section also holds the Priest Breakout Fee, which applies to facilities only.

That is the Booking Rules → "Order Records" setting. "One order for the whole booking" (the default) writes a single ledger row carrying every space, the equipment and the deposit. "One order per space" writes one row per space — the amounts always sum exactly to what was charged, and equipment rides the first row. Either way the devotee made one payment and gets one receipt.

Yes. Devotees can make general donations or give toward a specific purpose, and admins can create fundraising campaigns with public-facing pages so the community can contribute to temple causes. All contributions appear in the Finance Dashboard alongside puja orders, with donation totals and tax-exempt amounts tracked for reporting.