ZopNight’s Billing Rewrite: Clearer Invoices, Safer Payments
A billing document builds confidence by being legible, not just accurate. ZopNight’s invoice and credit-note views in Settings → Billing went through a full rewrite this release: roughly 30 separate pieces of copy converted into plain language, a clearer calculation trail from raw cloud usage down to the final total, and tax and contact details grouped together instead of scattered across the page.
An Invoice Rewritten to Be Read by a Person
Each invoice now displays a per-cloud-account activity column, so spend is traceable to the specific account that generated it, and a bill-to card that keeps GSTIN, place of supply, email, and phone grouped together rather than spread across the layout. A credit note now opens as its own page, showing the refund amount and exactly where it applied, with the two documents stacking so a person can step backward and forward between a credit note and the invoice it relates to, plus deep links that open either one directly.
| What changed | Why it matters |
|---|---|
| ~30 strings rewritten in plain language | A customer reads an invoice without needing to decode internal terminology |
| Per-account activity column | Spend is traceable to the specific cloud account that generated it |
| Bill-to card with tax details grouped | Finance teams don’t have to hunt across the page for tax fields |
| Stacked drawers with deep links | A credit note and its invoice can be compared directly, not reconstructed from memory |
A PDF That Matches What You Already Saw
Downloaded PDFs now render from the identical components as the on-screen drawer, forced into light theme regardless of whatever theme the viewer actually has set, so a PDF never reads as a different document from the one a customer was just looking at on screen. Files are named after their actual invoice or credit note number instead of a generic filename, and every PDF carries a direct Pay now link. The invoice-issued notification email’s own underlying data now carries that same payment link directly, rather than requiring a customer to dig through the product to find a way to pay.
A Redirect Path That Needed to Be Configurable
Alongside the invoice rewrite, the post-payment redirect used after a Razorpay checkout moved from a fixed, assumed path to a per-tenant configurable one. The fix adds a nullable metadata column to each tenant’s payment settings, carrying a callback path that defaults to the previous value, so nothing in production changes until a specific tenant’s path is deliberately set.
A new internal PATCH endpoint touches only the host and the callback path for one tenant’s settings, while the existing full-replace PUT endpoint now explicitly preserves whatever metadata is already stored whenever a caller doesn’t include it, rather than silently erasing it the way a naive full replace normally would. The internal Payments page itself was split into two distinct sections, merchant credentials in one place and payment settings in another, since they’re genuinely different kinds of configuration that had been living together under one screen.
Rolling this out needed one manual step afterward: a tenant’s callback path has to be set explicitly through the new Edit settings screen, or the PATCH endpoint directly, before that tenant benefits from the fix. Links generated before that step keep their original callback path, since a configuration change going forward has no effect on a URL already sent out. Only links generated after the setting is corrected use the new path.
Two Smaller Fixes Riding the Same Release
A related webhook fix carved out an explicit exception in the signature verification logic for a pair of Razorpay event types that arrive as siblings describing the same underlying payment, which had previously been refused outright as if they were duplicate or invalid events. Receivable-type invoices were also explicitly excluded from the dunning process entirely, since dunning exists to chase down unpaid, payable invoices, and a receivable was never the kind of document that logic was meant to act on in the first place. Both fixes are small on their own. Shipped in the same release as a full invoice rewrite, they’re a reminder that a billing system builds credibility one correctly handled edge case at a time, not in one single sweeping release.
