Start with the symptom
Choose the next safe action from what the family or school can actually observe.
Use this first table before changing the fee record, requesting another payment or promising a refund. The observed symptom opens an exception; the latest authorised provider, school and permitted bank evidence determines what happens next.| Observed symptom | Safe next action | Next control point |
|---|---|---|
| Debited, but the fee still appears due | Open one exception, preserve the safe order or payment reference, check the latest provider state and pause any retry instruction | The attempt is verified as captured, failed and reversed, replaced by another payment, or routed to the responsible provider or bank process |
| Pending or processing | Keep a controlled temporary status, check later provider events and give the family a dated next update | A verified final or otherwise actionable state supports the school’s next step |
| Failed | Confirm the exact attempt and whether a debit was reported; if so, follow the applicable reversal or escalation evidence rather than promising one timeline | The payment and any reported debit have a recorded disposition |
| Duplicate attempts or two captured payments | Stop further retry advice, preserve both sets of identifiers and confirm which payment should remain allocated before using the school’s approved excess-payment process | One approved allocation remains and the duplicate amount has a documented resolution |
| Captured or provider-paid, but settlement or bank credit does not reconcile | Preserve the payment and settlement references, bridge gross payments to fees, refunds, disputes and adjustments, and route the difference to the authorised finance owner | The provider settlement evidence, school fee record and authorised bank or accounting treatment explain the difference |
| Refund requested or shown as initiated | Link the refund to the original payment, record the refund ID, amount, approver and current provider state, and communicate initiation separately from receipt | The provider disposition and the school fee or accounting treatment agree |
| Payment disputed or fee position challenged | Open the provider dispute and the school grievance as separate linked routes, protect the current provider deadline and limit the evidence pack to what the case needs | The provider outcome and the school’s approved fee or grievance decision are both recorded |
Provider lifecycle
Use the provider’s current state—not the browser’s last screen.
Razorpay’s official payment-gateway flow separates order creation, checkout response, signature verification, capture and settlement. Its payment documentation also describes late authorisation and state changes. Re-query or review the authorised provider record rather than treating a stale callback, screenshot or message as final evidence.
Open one complete case
Collect one safe evidence pack, message the family and record closure.
Do not make the family repeat the story to several teams. Complete the checklist, use the holding message while evidence is open and support every applicable row in the closure table. Record an authorised Not applicable decision and reason where a row genuinely does not apply.- Approved school fee context: learner or payer reference, academic year, fee item and expected amount.
- Provider context: order ID, payment ID where available, method, amount, currency, attempt time and latest authorised state.
- Later evidence: capture, reversal, refund, settlement or dispute reference and only the permitted bank evidence needed for this case.
- Exception control: observed symptom, safe temporary status, named owner, next action and next review time.
- Family communication: last approved message, recipient, channel and the exact date and time promised for the next update.
- Sensitive-data boundary: never collect a password, OTP, PIN, CVV, full card number, bank credential or provider secret.
Copy-ready family message
Use a neutral holding update while the evidence is still open.
Hello [parent or guardian name]. We are reviewing the [amount] payment reported on [date and time] for [school fee reference]. The school record currently shows [temporary status]. We are checking provider reference [safe order or payment reference] and will update you by [date and time]. [If the payment attempt is unresolved: Please do not retry until that update unless the school confirms it is safe.] We will never ask for your OTP, PIN, CVV, password or full card number.
| Closure test | Required evidence | Leave open when | Record for this case |
|---|---|---|---|
| Provider disposition | Latest authorised payment, reversal, refund, settlement or dispute state and its safe reference | The status is only observed, stale, initiated or still awaiting an applicable provider outcome | State/reference: __________ · Checked: __________ |
| School fee record | Approved allocation, due, excess, refund or other fee treatment with the responsible actor and time | The operational fee position does not yet match the approved outcome | Treatment/actor/time: __________________________ |
| External finance evidence | Required settlement, bank, refund or dispute evidence and the school’s authorised accounting treatment | Money movement or gross-to-net treatment remains unexplained for the case | Evidence, or authorised N/A and reason: __________ |
| Family update | Accurate final message, recipient, approved channel and delivery or contact record | The family has only an interim promise or wording that overstates what is known | Message/channel/time: __________________________ |
| Case record | Final disposition, closure evidence, authorised closer and closure time while preserving the event history | Any linked retry, duplicate, complaint or provider case remains unresolved | Closer/time: __________ · Disposition: __________ |
| Observed condition | Check next | Do not do |
|---|---|---|
| Order exists; no payment ID | Whether checkout began and whether another order or attempt was used | Treat order creation as collection |
| Payment remains pending or authorised | Latest payment event, capture configuration and provider guidance | Force a retry while the first attempt can still change state |
| Provider shows failed; payer reports debit | Payment method, later reversal or authorisation event, bank or provider route | Promise that no debit happened or quote one universal deadline |
| A later payment succeeds | Whether the first attempt also captured or reversed | Close the first exception merely because a second payment worked |
| School callback is missing | Server-side verification, provider payment record and event history | Assume failure from the missing browser response alone |
RBI timing boundary
There is no single reversal time for every payment exception.
RBI’s official failed-transaction TAT framework defines method-specific outer limits. Its annex, for example, lists different treatment for a UPI funds transfer where the beneficiary is not credited and a UPI merchant payment where confirmation is not received. Verify the current rule, payment method and responsible regulated entity; do not turn one row into a promise for every family or transaction.
Different return paths
Separate a reversal, a merchant refund and a duplicate collection.
All three may end with money returning or being owed to a payer, but they begin from different payment histories and need different school records.| Case | Evidence to preserve | School close condition |
|---|---|---|
| Failed or uncaptured attempt reverses | Order, payment attempt, failed or uncaptured state, reversal evidence and dates | Applicable provider or bank evidence supports the reversal and the fee remains correctly due unless another payment succeeded |
| Captured payment is refunded | Original payment ID, refund ID, amount, reason, initiator and current refund state | School fee and accounting treatment agrees to the approved refund disposition |
| Two attempts capture for one fee | Both order and payment IDs, amounts, capture times, settlement/refund evidence | One approved allocation remains and the excess is resolved through the school’s formal process |
| Partial refund | Original gross payment, refund amount, retained amount, approval and provider state | The remaining fee position and external accounting record explain the partial return |
| Refund fails or remains pending | Refund ID, latest state, failure detail where available and escalation history | A completed or otherwise resolved provider disposition is recorded; initiation alone is not reported as receipt by the payer |
Capture boundary
An authorised payment can still require capture before settlement.
Razorpay’s capture-settings documentation distinguishes authorisation from capture and describes automatic refund behavior for payments not captured within its documented window. Confirm the school’s live configuration and current provider terms rather than assuming every authorised attempt will settle.
A refund should remain linked to its original payment. Razorpay’s refund documentation distinguishes refund states and source refunds. The school should separately record who authorised the financial outcome and how the external accounting or documentary process reflects it; Schylva does not currently claim a refund workflow.
Questioned transactions
Route a provider dispute and a school fee complaint without merging them.
A family can question the fee position, the service, the payer identity or the payment itself. A provider dispute has its own deadline and evidence path, while the school still needs a clear, respectful grievance response.Classify the concern.
Record whether the question concerns the school fee amount, learner allocation, duplicate payment, unauthorised payment, non-receipt of a refund or another provider reason.
Protect the provider deadline.
Assign an authorised owner to review the current dispute notice, response due date, reason and permitted evidence. Do not wait for an informal school conversation to expire first.
Build a proportionate evidence pack.
Use the payment and order references, approved fee context, relevant communication and authorised documentary evidence. Exclude unrelated learner or family information.
Respond through the correct channel.
Use the provider’s authorised dispute process for the payment case and the school’s own grievance route for the fee or service question. Record both references where they relate.
Keep the financial outcome open.
Do not treat submission of evidence as a successful outcome. Track the provider decision, any debit or adjustment, and the school’s approved accounting and fee-record treatment.
| Say | Avoid | Why |
|---|---|---|
| We are checking payment ID … against the provider record and will update you by … | Your payment definitely failed | The latest state may still need verification |
| The first attempt remains unresolved; please wait for our next update before retrying | Pay again now and the first debit will automatically return | A retry can create a duplicate and reversal timing is method-specific |
| A refund was initiated on … under refund reference …; its current state is … | The refund is in your bank | Initiation and payer receipt are different events |
| Your complaint and the provider dispute are being tracked under separate references | The bank dispute closes the school complaint | The two routes can answer different questions |
Dispute source
A disputed payment is not a final finding against the family or school.
Razorpay’s official dispute documentation describes a dispute as a case in which a customer or issuing bank questions a payment’s validity. RBI’s current Payment Aggregator Master Direction provides wider responsibilities around disputes, refunds and reconciliation. The school should follow its provider agreement and obtain qualified advice for a specific case.
Keep open work visible
Review unresolved exceptions on a clear cadence.
Use the closure table near the start of this workflow for every symptom route, then review open work on a clear cadence. Removing an item from the queue, initiating a refund or receiving a provider response is not by itself evidence that the complete school exception is resolved.| Cadence | Review | Output |
|---|---|---|
| During collection hours | New debits without confirmation, duplicate risk and family-facing urgency | Safe temporary status, owner and next-update time |
| Daily close | Every new and aging payment, refund, settlement and dispute exception | Verified state, next action and named carry-forward |
| Settlement close | Captured payments, provider fees, refunds, disputes, adjustments and bank credit | Gross-to-net bridge and open settlement exceptions |
| Weekly control review | Repeated causes, aging bands, missed updates and access exceptions | Workflow, training, configuration or escalation improvements |
Three closure tests
Resolved for the provider, school record and family—not just removed from the queue.
Before closure, ask whether the provider state is final enough for the case, whether the school fee and external accounting treatment match the approved outcome, and whether the family received an accurate final update. For captured payments, continue into settlement reconciliation; Razorpay’s settlement reconciliation reference illustrates why gross payments, refunds, fees and adjustments must be bridged before the net bank credit is explained.
Protect people and scope
Limit evidence access and state clearly what Schylva does not automate.
Payment exceptions combine learner context, family communication and financial identifiers. Give each role only the information and action it needs, and keep operational fee status separate from formal accounting or provider case management.Supported today
- fee-structure configuration for the relevant class and academic year
- authorised class and student fee-status review
- supported offline school payment recording
- linked-parent fee status and payment history
- configured parent payment order and verification through Razorpay
Confirm for your school
- authorised provider, bank, accounting and family-communication owners
- the temporary states and service targets used for open exceptions
- provider charges, live capture settings and escalation routes
- the approved refund, dispute, receipt and accounting process
Not currently claimed
- automatic bank or payment-gateway reconciliation
- refund or dispute and chargeback management
- formal receipts, invoices, fee allocation or a general ledger
- free processing, a payment guarantee or support for every gateway
- student self-payment or non-login fee reminders
Current Schylva scope
Payment verification is not automatic exception reconciliation.
Schylva’s public fee scope includes a configured linked-parent Razorpay order and verification before the fee record is updated. It does not claim automatic bank or gateway reconciliation, refunds, chargeback management, formal receipts or full accounting. Review the exact fee-management feature boundaries and keep the external finance and provider controls documented.
Safe evidence
Never collect a password, OTP, PIN, CVV, full card number or API secret to investigate an exception.
Use the minimum permitted order, payment, refund, settlement or dispute reference through an approved support route. Keep bank credentials, live Razorpay keys, full payment instrument data and unnecessary family or learner records out of shared queues and public forms. India’s Digital Personal Data Protection Act, 2023 and notified Digital Personal Data Protection Rules, 2025 have phased commencement; verify current notifications and obtain qualified advice for the school’s specific obligations.
Learn from exceptions
Measure the queue to repair the workflow—not to blame families or staff.
Exception patterns can expose unclear retry guidance, missing identifiers, delayed capture, access gaps or weak settlement review. Counts alone cannot establish fault.Volume
How many attempts became exceptions?
Keep the total payment-attempt denominator and method mix beside the exception count.Aging
Which states remain open longest?
Use age bands by state and owner; one overall average can hide serious outliers.Repeat cause
Where do exceptions cluster?
Separate provider state, duplicate retry, missing school context, settlement and communication causes.Closure quality
Did all records and messages agree?
Sample resolved cases for provider evidence, fee treatment, family update and appropriate access.| Signal | Question before acting | Possible improvement |
|---|---|---|
| Repeated retries while the first attempt is pending | Does the payer see a clear hold-and-check message? | Improve temporary status wording and update timing |
| Many exceptions lack a payment ID | Are order, callback and server-verification references joined correctly? | Repair identifier capture and provider-event review |
| Refund queries remain open after initiation | Is the current refund state and family update owner visible? | Track initiation, provider state and payer-facing closure separately |
| Settlement differences recur | Are fees, tax, refunds, disputes and adjustments included in the bridge? | Strengthen the gross-to-net settlement close |
Interpretation rule
A high exception count is a signal to investigate—not evidence of payer behavior.
Define the denominator, payment methods, time window, outage periods and exclusion rules before comparing results. Use the complete school fee collection and reconciliation guide to connect exception review to fee ownership, provider settlement and bank close.
Frequently asked questions
Clarify the decision and its boundaries.
Use these answers as a starting point, then verify the relevant source, rule and school process.What should a school do when money is debited but the fee still appears due?
Open one exception using the safe school, order and payment references; check the latest authorised provider state and later events; keep the operational fee status unresolved; avoid asking for an immediate retry; and give the family a dated next update. Capture, failure and reversal are provider milestones, not complete case closure: close only after every applicable provider, school, external-finance, family-update and case-record test is supported.
Is a failed payment the same as a reversed payment?
No. Failed describes the provider outcome of the attempt; reversed describes the applicable return of a debit or authorisation. A failed attempt may need later reversal evidence when a payer reports a debit, and the timing depends on the payment method and responsible entity.
Is a reversal the same as a refund?
No. A reversal generally follows a failed or uncaptured payment path, while a merchant refund is linked to an eligible payment that was captured. Preserve the original payment and any refund identifier, and verify the current provider state rather than using the terms interchangeably.
How long does a failed UPI school fee payment take to reverse?
Do not quote one universal period. RBI’s failed-transaction framework contains method- and scenario-specific outer limits, and the responsible bank or provider must apply the current rule to the exact case. Record the attempt and next update, check the latest status and use the approved escalation route when the applicable limit is exceeded.
Should a school ask a parent to pay again while the first payment is pending?
Not until the school checks the latest state and duplicate risk. A pending or late-authorised attempt can change after the first screen or callback. Give the family a temporary status and a dated update instead of an unsupported retry instruction.
Does Schylva automatically handle refunds, disputes or bank reconciliation?
No. Schylva’s current public scope includes configured linked-parent Razorpay order creation and payment verification, but does not claim refunds, dispute or chargeback management, formal receipts, full accounting, or automatic gateway-to-bank reconciliation.
What information is safe to request from a family about a payment exception?
Use only the minimum permitted context, such as the amount, date, method and safe order or payment reference available through the approved route. Never ask for passwords, OTPs, PINs, CVVs, full card numbers, bank credentials, Razorpay keys or unrelated learner and family records.
Primary sources and further reading
Read the official material behind the context.
Sources were reviewed when this checklist was updated on 2 September 2026. Always verify the current official version before relying on a rule or requirement.Reserve Bank of India
Master Direction on Regulation of Payment Aggregator (PA) — 15 September 2025 Primary direction reviewed for current payment-aggregator context, including dispute, refund, reconciliation and settlement responsibilities. This workflow does not provide a regulatory interpretation.Reserve Bank of India
Harmonisation of Turn Around Time and customer compensation for failed transactions Official method-specific failed-transaction framework. Verify current amendments, the exact payment scenario and the responsible regulated entity before relying on a timeline.National Payments Corporation of India
UPI Frequently Asked Questions Official UPI context for pending or failed transactions and complaint routes. The bank or provider process can differ by case.Razorpay
Payment Gateway flow Provider documentation separating order creation, checkout, verification, capture and settlement.Razorpay
About Payments and payment lifecycle Provider documentation for payment states and later authorisation. Confirm the school’s live account configuration and current terms.Razorpay
Capture Settings Provider documentation distinguishing authorisation, capture and automatic refund handling for uncaptured payments.Razorpay
About Refunds Provider documentation for refund types and states. Schylva does not currently claim a refund workflow.Razorpay
About Disputes Provider documentation defining disputes and describing the provider response process. Follow the school’s provider agreement for a specific case.Razorpay
Fetch Settlement Recon Details Provider API reference illustrating how payments, refunds, transfers and adjustments can be associated with settlement evidence.Ministry of Electronics and Information Technology
Digital Personal Data Protection Act, 2023 Primary statutory source for qualified review. This workflow does not decide applicability or provide legal advice.Ministry of Electronics and Information Technology
Digital Personal Data Protection Rules, 2025 Official Gazette notification with phased commencement. Verify later notifications and obtain qualified advice where required.