# Administrator guide ## The one thing that matters most The eligibility rules decide what a customer is told and whether you take their money. A wrong rule means either refusing business you could have handled, or — far worse — taking payment for a challan that requires the owner to appear in court in person. **Have a lawyer confirm each rule before you enable a state.** ## States Two separate switches, and the distinction matters: - **Enabled** — the state appears to customers. - **Service available** — challans in that state can actually be purchased. A state can be enabled but not sellable while you confirm its legal process. Uttar Pradesh ships in exactly that position. Turning off *Service available* takes effect on the next page load. Existing paid orders are unaffected. ## Eligibility rules A rule naming both a state and an offence beats a state-wide default. Within the same specificity, higher priority wins, then the newest rule. If nothing matches, the engine returns `MANUAL_REVIEW_REQUIRED` — it never guesses. Actions: | Action | Meaning | Sellable | |---|---|---| | `ONLINE_CLOSURE_ALLOWED` | Can be closed without a court appearance | Yes | | `LAWYER_ASSISTED_ALLOWED` | An advocate handles it on the customer's behalf | Yes | | `PHYSICAL_COURT_PRESENCE_REQUIRED` | The owner must attend in person | No | | `GOVERNMENT_PAYMENT_ONLY` | Pay the authority directly; we add nothing | No | | `DISABLED` | Not handled at present | No | | `MANUAL_REVIEW_REQUIRED` | Needs a human to look | No | Editing a rule increments its version. Every order records the rule id and version it was sold under, so you can always reconstruct why a sale was allowed. The **customer message** is the only explanation most people will read. Write it in plain language. Note: a challan the provider reports as already before a court is forced to `PHYSICAL_COURT_PRESENCE_REQUIRED` regardless of the rule. This is deliberate and cannot be overridden from the interface. ## Providers Secrets are write-only. Once saved you can never read one back — only the last four characters are shown. Leaving a secret field blank leaves the stored value untouched, so you can change the endpoint without re-entering the key. Changing a secret is recorded in the audit log; its value is not. Every driver ships as `mock`. Nothing real happens until you switch it. Use **Save and test** on each provider before going live. ## Pricing The service fee applies to **new orders only**. Orders already placed keep the fee they were priced at — changing this setting never reprices history. The government amount is pass-through. It appears in reports as a liability, not as income. The dashboard's "gross contribution" figure is service fee, less coupons, less recorded lawyer costs. Tax ships at 0 basis points. Set it after confirming your GST position with an accountant. 1800 = 18%. ## Lawyers Applications arrive as `pending` and cannot sign in until you approve them. Check the bar council number against the state bar council roll before approving — the application form does not verify it. Paid cases route automatically by state and current load. You can override and assign manually from the Lawyers screen. ## Reports The CSV export contains commercial and status fields only. Identity documents and their references are deliberately excluded, so the export can be shared with an accountant without exposing customer documents. ## Audit log Append-only. Sensitive values are redacted at write time, so it never contains a password, one-time code, API secret or identity number. Review it weekly. ## Support queue `/admin/tickets`. The queue sorts urgent and high above everything else, then by last activity. Tick **Internal note only** to write something the customer will never see — useful for what you found in the gateway, or context for the next person. A normal reply moves the ticket to *waiting customer* and emails them; an internal note does neither. ## Expert requests `/admin/expert-requests`. These come from customers whose challan requires them in court. Ticking **open a ticket** creates a support thread they can actually see and reply to, seeded with an honest explanation. A bare request row is invisible to them. ## Coupons `/admin/coupons`. A coupon only ever discounts the service fee — that limit is enforced in pricing, so there is no way to configure around it. Tick states only if the promotion is genuinely regional: if you tick any, every challan in the cart must be in one of them. A coupon's code cannot be edited after creation, because customers may already have it. Coupons are deactivated, never deleted, so old orders stay explicable. ## Pages, posts and templates `/admin/pages`, `/admin/posts`, `/admin/email-templates`. Authored HTML is sanitised on save: script tags, inline event handlers and `javascript:` URLs are stripped. System pages (privacy, terms, refunds) keep their addresses because the footer links to them. A post saved as *published* with a future date stays hidden until that date. Template variables are shown above the editor. Remove one and you get a warning, not a block — but check the result before you rely on it. ## Advocate credentials From the Lawyers list, follow **Credentials**. Check the bar council number against the state roll before approving: the form does not verify it and a document can be forged. Every file you open is recorded against your account. ## Analytics `/admin/analytics`. Visitors are counted by a per-day salted hash, so these figures will not match a third-party tool and cannot identify anyone. The funnel shows drop-off between steps; a drop above 50% is highlighted, which is usually where to look first. ## Adding staff accounts Not yet available in the interface. Insert a row into `support_users` with a bcrypt hash and the role id you want. The roles themselves — admin, support, ops, content — are seeded and their permissions are tested.