# A Compliance-Grade Invoice Still Had a Hardcoded 404 in It > A payment can succeed and still leave a customer staring at a 404. ZopNight's Razorpay integration redirected every customer back to a fixed path after a successful payment, a path that assumes the… Source: https://zop.dev/resources/blogs/a-hardcoded-payment-callback-was-404ing-on-prod-all-along Published: 2026-09-30 · Author: riya-mittal · Tags: cloud-governance, billing, compliance --- A payment can succeed and still leave a customer staring at a 404. ZopNight's Razorpay integration redirected every customer back to a fixed path after a successful payment, a path that assumes the application lives at the root of its own domain. Production doesn't work that way. The app actually runs nested under its own path, and the hard-coded redirect had no way of knowing that, so a customer who'd just paid landed on an error page instead of a confirmation. ## A Default That Matches the Old Behavior Exactly The fix adds a nullable metadata column to [each tenant's payment settings](https://zop.dev/resources/blogs/self-serve-billing-needed-an-immutable-price-record), carrying a configurable callback path that defaults to the exact value that used to be hard-coded everywhere. That default is the detail that makes this safe to ship without touching every tenant at once: nothing changes in production behavior until someone deliberately sets a different path for a specific tenant. Architecture diagram 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 was changed to explicitly preserve 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 confusing screen. ## Fixing the Code Doesn't Fix Already-Sent Links Shipping this fix isn't the end of the story, because the migration only adds the capability to configure a correct path. It doesn't retroactively repair the value already stored for the one tenant that matters most. Someone still has to go into the new Edit settings screen, or call the PATCH endpoint directly, and set that tenant's callback path to the actual, real application path, by hand, after deploy. Payment links generated and sent out before that manual step keep pointing at their original, broken path permanently. A fix to the code going forward has no effect on a URL a customer already has sitting in their inbox. Only newly generated links, created after the tenant's setting is corrected, actually benefit from the fix at all. ## An Invoice Rewritten to Be Read by a Person Alongside the redirect fix, roughly 30 separate pieces of invoice and credit-note copy were rewritten in plain language. Each invoice displays a per-cloud-account activity column, one clear calculation trail from raw cloud usage down to the final total, and a [bill-to card that keeps GSTIN](https://zop.dev/resources/blogs/soc-2-compliance-on-cloud-infrastructure-a-technical-checklist-for-engineering-teams), place of supply, email, and phone grouped together instead of scattered. A credit note opens as its own page, showing the refund and exactly where it applied, and the two documents stack with a direct way to 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 compliance 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 than 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. ## Two Smaller Fixes Riding the Same Release A [related webhook fix](https://zop.dev/resources/blogs/choosing-your-cost-source-meant-never-showing-a-fake-zero) 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 redirect bug and 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.