Payments, Credits & Reconciliation¶

Part of the Aashray Business Logic. Related: Booking Lifecycle & Engine, Stay: Rooms & Flats, Food, Travel, Adhyayan & Utsav, Status Vocabulary & Automatic Checks.

This is the money domain, and it's fundamentally a lifecycle, not a single transaction: the system sets a price centrally, a member's payment (or non-payment) is just the event that starts things moving, a later cancellation may turn what they paid into credit instead of a refund, and none of it is truly finished until staff close the loop by reconciling what Aashray recorded against what the payment gateway actually settled into the centre's bank account.

Step one: a price is set centrally¶

A member never types in or edits a price. Whenever someone builds a booking in the member app, a stay, a flat, a meal, an Adhyayan, an Utsav package, or travel, the member app sends the details to the system, and the system alone decides what it costs. The prices in effect today:

A non-AC room costs ₹700 per night; an AC room costs ₹1,100 per night.
A flat costs the same as a non-AC room per night, except a flat owner booking their own flat pays nothing.
Breakfast costs ₹60 per plate; lunch and dinner cost ₹120 per plate each.
An Adhyayan or Utsav costs whatever amount staff have set for that specific Adhyayan or package.
Travel costs nothing at the time of booking, a staff member sets (or waives) the fare afterward.
A seat that lands on a waitlist is never charged until it's promoted to a confirmed seat.

Step two: a member pays¶

Three ways to settle a booking exist today:

Pay online, now, the normal path when the person booking is registered in India. The member is shown the total and pays through the member app's checkout.
Pay later, within 24 hours. Whenever an amount is due, the review screen also offers Pay Later. The booking and its payment order are created exactly as for Pay Now; the member app only skips the checkout. The member then pays from Pending Payments (see "The 24-hour payment window," below).
Pay in cash at the centre, used for bookings staff create on a member's behalf, and automatically when the person booking is registered in a country other than India.

Online payment follows the payer's registered country, not the card. A payer registered outside India gets no payment order at booking, and each charge is recorded as payable in cash at the Research Centre (backend). Pending Payments still lets that member try to pay online, with a notice that international cards are not supported and that they may proceed only with an Indian bank account (member app). A failed attempt leaves the item payable in cash (backend).

The 24-hour payment window¶

A booking left in "pay later" status is automatically cancelled if the member hasn't completed payment within 24 hours of booking it. This applies only to members registered in India; a failed payment counts as unpaid. This is purely about finishing payment, it's a different rule from, and shouldn't be confused with, the separate 24-hour lead time staff use when confirming travel arrangements (see Travel).

The window starts when the booking is made. Pending Payments shows a live countdown on each online item: green while there's time, orange in the last 3 hours, red once it has expired (member app).
Once expired, the item can no longer be paid, the booking is simply cancelled. The member app does not let the member select an expired item. The backend also refuses to create a payment order that includes an online item older than 24 hours, with the message that one or more payments have expired, even before the automatic check has cancelled it.
Cash-based bookings are exempt from this window; they never expire this way and show no countdown. This includes charges due at the office from staff-made room and flat bookings and from staff promotions of waitlisted room and flat bookings: the 24-hour check never cancels them. Staff promotion of a waitlisted Utsav booking and a travel booking moved to payment create online charges for payers registered in India, and those do fall under the 24-hour check (backend).
Just before it cancels an item, the system checks it again. If the payment went through in the meantime, the booking is kept.
If a pending item already had credit applied toward it, that credit is returned when the 24-hour cancellation happens. This applies to every booking type.

A payment-confirmation gap¶

When a member pays online, Razorpay sends the backend a payment notice. The backend records every notice it receives. It then fetches the payment from Razorpay and compares the payment ID, order ID, amount, and currency before it settles the booking. A notice that does not match is refused. A check of Razorpay's signature on each notice exists in the backend but is not switched on; the lookup is a temporary fallback. The lookup reduces spoofing risk, but missing signature verification remains a security gap.

How a payment notice settles a booking¶

What the backend does with each notice (backend):

Paid. Each covered payment item becomes paid. Stay and flat bookings move to awaiting check-in. Adhyayan, Utsav, and travel bookings become confirmed. Meal items are marked paid; the meals themselves do not change.
Authorized only. The items are marked authorized. The booking does not change.
Failed. Online items are marked failed and can be paid again within the 24 hours. A charge due at the office stays payable in cash.
Any other notice is acknowledged and ignored. A notice for an order with nothing left to pay changes nothing.
Never more than was paid. Items are settled in the order they were created until the paid amount runs out. Items the payment does not cover keep their status, so they can still be paid or expire, and the shortfall is logged.
Repeated notices. Razorpay can send the same payment more than once. A repeat never spends the same money twice.
After a paid notice, the backend sends the confirmation email and WhatsApp updates described in Booking Lifecycle & Engine.

Paying from Pending Payments¶

Pending Payments, opened from the member app's home screen, lists up to 100 unpaid items where the member is the payer, including items they booked for other people. It shows online items awaiting payment, failed online items, and charges due at the office. Each item shows its title, amount, dates and nights, the person it was booked for, any staff note, and a cash label for charges due at the office. A summary shows the total still payable and how many items, worth how much, have expired (member app).

The member selects items, or selects every item that has not expired, and taps pay. Meal charges can be paid here.
The backend builds one payment order for the selected items. If the member taps pay again for the same unpaid items and the amount has not changed, the backend reuses the same order, so a payment already in progress is not lost.
If that order was already paid, the backend refuses a new one with the message that payment was already received and the member should contact support if the booking is not yet confirmed.
If nothing is left to pay, the backend refuses and the member sees the failure screen.
If the checkout takes more than 10 seconds to open, the member app says so and asks the member to complete it if it appears, or else try again.
After a successful checkout, the member sees the "Booking Confirmed" screen. After a failure or a closed checkout, the member sees the "Payment Failed" screen, which offers Try Again and contact support.
An older payment path, kept for earlier member app versions, refuses meal charges (backend).

Step three: if it's cancelled, money becomes credit, never cash¶

Once a payment has been collected, a later cancellation follows the booking type's rule. Aashray does not send an automatic cash refund to a card or bank account. Some paid cancellations create credit, while others do not. If an unpaid booking that already had credit applied to it is cancelled, only that applied credit is returned; no new credit is created. One exception: a member who cancels their own unpaid Adhyayan booking does not get the applied credit back.

What happens to the money on cancellation (backend):

Who cancels	Booking type	Paid booking	Unpaid booking with credit already applied
Member	Stay, flat	Full price becomes credit	Applied credit returned
Member	Food	Full price becomes credit, whoever booked the meal	Applied credit returned; the meal's charge is closed
Member	Travel, Utsav	No credit	Applied credit returned
Member	Adhyayan	No credit	Applied credit not returned
Staff	Room stay (cancel action), food	Full price becomes credit	Applied credit returned
Staff	Flat (cancel action)	No money moves; the payment is left as it was	No money moves
Staff	Stay or flat through the status window (only from waiting or pending payment)	Not allowed	Payment marked admin cancelled; applied credit not returned
Staff	Travel, Utsav	Staff choose: full price becomes credit, or no credit	Applied credit returned
Staff	Adhyayan	Full price always becomes credit; staff get no choice	Applied credit returned
24-hour payment check	All types	Does not apply	Applied credit returned

"Full price" means the amount paid plus any credit applied. A travel cancellation for seats full or wrong form made in the staff panel gives no credit for a paid booking; an unpaid booking's applied credit is returned. The staff panel records the reason as a staff comment and sends an ordinary staff cancellation with "no credit" chosen (staff panel). The backend also has separate seats-full and wrong-form cancellations that return the full price as credit, but the staff panel does not use them (backend).

Credit¶

Credit is Aashray's own currency inside the member app, 1 credit = ₹1. It cannot be withdrawn or converted to cash; it can only be spent on a future eligible booking.

Earning credit. An eligible cancellation can turn the amount already paid into credit. Credit is tracked separately per category: stay/flat, food, travel, Utsav, and Adhyayan. Credit goes to the person who paid, which can be the booker.
Spending credit. Available credit is applied automatically the next time a member books something in the same category, they never have to choose to use it. If the credit fully covers the price, no online payment step is needed at all, and the booking is confirmed right away. When staff move a waiting Utsav booking to payment, the payer's Utsav credit is applied first in the same way. Food credit is spent the same way on guest meal charges, and the booking quote shows it. One exception: when staff move a waitlisted Adhyayan booking to payment and credit covers the whole fee, the charge is marked paid but the booking stays payment pending (see Adhyayan & Utsav). The system locks a member's credit balance while a booking uses it, so two bookings made at the same moment cannot spend the same credit twice (backend).
Where a member sees it. Their profile shows available stay, travel, food, and Utsav credit. It does not show Adhyayan credit (member app). The booking review screen shows the original price struck through with the credit applied and the new amount due.
Paid travel and Utsav bookings are non-refundable when the member cancels. Unlike stays, flats, and food, the member's own cancellation creates no credit. This is a product decision, confirmed on 2026-09-30. Only a staff cancellation can return that money as credit. For a travel or Utsav booking, staff can do this even after the member has already cancelled it. For a booking that was never paid, staff credit returns only credit that was applied and not yet given back (backend).

Gaps in how credit works today: - Adhyayan credit is only partly supported. A staff cancellation always turns the full price into Adhyayan credit, and that credit is applied automatically to the member's next Adhyayan booking. But the member's profile does not show this credit, and the booking review does not preview it. A member who cancels a paid Adhyayan booking earns no credit, and a member who cancels an unpaid one loses any credit already applied to it.

Step four: staff close the loop, settlements and reconciliation¶

This is the stage that finishes the lifecycle for every payment, not just the ones that get cancelled: it's how staff confirm that money Aashray believes it collected actually landed in the centre's bank account. Behind the scenes, staff periodically import reports from the payment provider showing which payments actually settled, and match them against Aashray's own record of what members paid. From this, staff can:

See which of Aashray's payments belong to which settlement batch, and drill into any one payment.
Download reports of completed payments, pending payments, credit granted, and credit spent.
Review every member's credit balance and history.

This reconciliation only runs when staff manually import the provider's reports, it isn't automatic or continuous today. Nothing flags a difference between Aashray's records and the settlement files; staff compare them by eye.

Staff finance reports¶

Super admins and accounts admins use these staff panel pages. The backend also accepts a second accounts role (see Known limitations).

Report	What it lists	Filters	Download
Completed Transaction Report	Payments paid online, paid in cash, or turned into credit	Creation date range (required, default last 7 days); type: all, stay, flat, Adhyayan (optionally one Adhyayan), Utsav (optionally one Utsav), travel, or food	Excel file named by the dates and the filter
Pending Transaction Report	Online and cash payments not yet paid	Creation date range (default last 7 days)	Excel file
Credited Transaction Report	Payments turned into credit by a cancellation	Date the credit was given (default last 7 days)	Excel file
Credits Used Report	Paid bookings that used credit, with the payer's current credit of that type	Creation date range (default last 7 days)	Excel file
Mumukshu Credits Report	Every card holder with credit, with stay, food, travel, and Utsav balances and contact details	Search	None

Each transaction report shows, per payment item: booking ID, type, quantity (nights for stays and flats, otherwise 1), check-in and check-out for stays and flats, amount paid, credit used, staff note, status, payment order ID, and the name, card number, address, email, and phone of both the payer and the person booked for. Staff can search within each table (staff panel and backend).

On the credits report, tapping a balance opens that member's history for that type: each credit received and each use, with the amount paid, the credit used, and a running balance.

Settlement imports. Two upload pages read Razorpay's Excel exports. Each page first shows the file's rows on screen, and then uploads them (staff panel and backend).

Settlement Report imports settlement batches: ID, amount, status, fees, tax, bank reference, and date. Rows without a valid date are skipped. A batch already imported is ignored, and staff see how many rows were new and how many were duplicates.
Settlement Reconciliation imports one row per settled payment: order, payment, amount, fee, tax, credit, settlement batch, settlement date, and bank reference. Rows without an order or payment ID, or with a bad date, are skipped. A row for a payment already imported is updated.

Settlement Breakdown Report. Lists settlement batches in a date range (default last 7 days), with fees and tax summed from the reconciliation rows. Opening a batch lists each payment order in it, with the number of items, total paid, credit used, fees, tax, and credit amount. An order with no matching Aashray payment is labelled a Satshrut payment and highlighted. Opening an order lists its paid items with the payer, the person booked for, the settlement date, and any Adhyayan staff comment. For a Satshrut payment, the payer is matched by phone number. The full export is one Excel file with three linked sheets: batches, orders, and item details.

Known limitations today¶

Adhyayan credit is only partly supported. Only staff cancellations create it, members cannot see it in their profile or booking review, and a member who cancels an unpaid Adhyayan booking loses any credit applied to it.
A payment that arrives after its booking was cancelled is not resolved. If the payment record was still open, the system marks it paid but leaves the booking cancelled. If the payment record was already cancelled, for example by the 24-hour check, the system does not apply the payment to anything. In both cases the system writes only an internal log warning. It sends no alert, issues no credit, and makes no refund (backend).
Approving a waitlisted flat stay always charges the non-AC rate. When staff move a waitlisted flat stay to payment, the backend charges ₹700 a night even when the person staying owns the flat, although an owner's own stay is otherwise free.
The online-payment flow does not verify Razorpay's signature on the payment notice. The check exists in the backend but is not switched on. The flow does fetch and compare the payment details before settlement (see above).
Members registered outside India get no online payment at booking. Their charges become due at the office. Pending Payments lets them try online only with an Indian bank account.
A payment that stops at "authorized" is stranded. It no longer appears in Pending Payments, and the 24-hour check does not cancel it. Nothing in the system resolves it (backend and member app).
The member app shows "Booking Confirmed" as soon as the checkout succeeds. The backend confirms the booking only when Razorpay's payment notice arrives. If that notice never arrives, the 24-hour check can still cancel the booking.
The finance reports have gaps. The Completed report also includes payments turned into credit. The Pending report leaves out failed online payments. Meal rows show the payer as the person booked for. The Breakdown report labels every settled order it cannot match as a Satshrut payment. The credits report has no Adhyayan column.
The member app's credit explanation differs from the backend. The profile's "About Credits" note says that credit is earned only when a paid booking is cancelled, and that it is applied to stay, flat, Utsav, and guest food bookings. In the backend, cancelling an unpaid booking also returns any credit applied to it, and a member's own cancellation of a paid travel, Utsav, or Adhyayan booking earns no credit. Travel and Adhyayan credit are also applied automatically (backend and member app).
Seats-full and wrong-form travel cancellations give no credit from the staff panel, although the backend has a path for them that returns the full price as credit.
A member's credit history can show the wrong credited amount. For a cancelled booking that had credit applied, the history shows the amount paid or due, not the credit actually returned.
Staff panel and backend roles do not match. The backend accepts a second accounts role, but the staff panel does not let a person with only that role sign in. The accounts menu, the Pending report, and both upload pages also refuse that role. Card admins and office admins can open a credits report page, but the backend refuses to load it for them.
Flats are priced at the non-AC room rate, with no distinct flat price of their own, even though this may not reflect the intended pricing.