Test Transaction Ghost: The ₹1 Transaction That Leaves 98 Paise in Production

An engineer runs a ₹1 test transaction. Two months later, finance sees a ₹58 line in the settlement report that no one can explain. The two events are connected — but by the time the variance appears, the credential-misuse root cause is buried under hundreds of subsequent legitimate transactions. The test transaction ghost is one of the most frequent-but-invisible failure modes in payment gateway reconciliation for streaming platforms in India, where subscription volume is high, engineering iteration is constant, and per-transaction amounts are small enough that a ₹1 residue never crosses a monitoring threshold.

The reconciliation in one paragraph

Test transaction ghosts arise when engineering test flows execute against production payment gateway credentials — Razorpay, PayU, Cashfree, Bill Desk, or CCAvenue — instead of the sandbox. The gross amount is captured, a refund is initiated, but the gateway retains its MDR and GST-on-MDR because the fee is booked at the moment of capture. A ₹1 test transaction on a domestic card path with 2% MDR leaves roughly 98 paise net-positive in the settlement file after the “refund” completes. That 98 paise has no invoice, no customer, no subscription, and no order — so it will never reconcile to the ERP. Correct handling quarantines the ghost into a dedicated ledger, traces the credential-misuse root cause with engineering, and either reverses at source or writes off with documentation. Wrong handling — absorbing 98 paise per ghost into month-end variance across hundreds of ghosts — breaks the RBI Payment Aggregator audit trail and creates a drift between GSTR-1 outward supplies and settlement totals that GST officers will eventually question.

What the ghost transaction looks like in India — illustrative streaming brand scenarios

Consider a QA engineer at an illustrative streaming platform — say a mid-tier OTT service similar in scale to Sony LIV or ZEE5 — running a load test against the subscription checkout. The load-test harness is configured to hit the production Razorpay endpoint by mistake: the environment variable PG_ENV was left as prod after a previous debugging session, and the harness picks up production API keys from the shared vault. Each iteration submits a ₹1 charge against a synthetic customer. Two hundred iterations produce two hundred ₹1 captures. The engineer notices at iteration 201, kills the harness, and initiates refunds for all 200 transactions through the Razorpay dashboard.

The refunds process. Each customer-side refund is ₹1 gross — the full charge is returned to the (nonexistent) synthetic card. But on the merchant side, Razorpay’s settlement file for that day shows 200 lines of ₹1 gross captures followed by 200 lines of ₹1 refund deductions — with 200 MDR lines of roughly 2 paise each remaining as fee retention, and 200 GST-on-MDR lines. The net residue in settlement is 200 × ~98 paise = about ₹196.

Because the synthetic customer emails were random strings, none of them exist in the CRM. Because the load-test harness didn’t create invoices, none of the payment_ids match order records. The finance team looks at the settlement file, sees 400 lines that don’t match anything, and — because each line is under ₹1 — flags them as “residual, review later.” Two months pass. The variance line at month-end grows. By the time the aggregate is ₹500 or ₹1,000, the load-test event is forgotten and the root cause is lost.

The same pattern shows up on illustrative platforms across the streaming category — Netflix India, Amazon Prime Video India, Aha Video, Sun NXT, ALT Balaji, MX Player, JioSaavn, Voot Select. What differs is the volume: a platform doing 100,000 subscription renewals a month can absorb ₹500 of ghost residue as noise, but the audit trail damage is identical to a smaller platform where the same ₹500 would look conspicuous.

The specific pathologies that produce ghosts:

• Environment switch misconfiguration. Production API keys leak into test flows. Load-test harnesses run against prod. Feature-flag rollouts execute a “smoke test” through the real payment path. The single most common root cause.
• Automated subscription retry with corrupted metadata. A subscription retry loop for a failed renewal accidentally attaches a test-mode metadata object. The retry succeeds in production, then a downstream job “cleans up” by refunding — but the MDR is already booked.
• Third-party integration testing. An analytics vendor or CRM vendor runs an integration test that includes a ₹1 payment probe. The probe uses production credentials because the vendor was given only one set of keys.
• Chargeback simulation. A chargeback-handling test intentionally creates and reverses a real transaction to verify the chargeback flow. If the test is not documented in the reconciliation ledger, it appears as a ghost.
• Gateway-side test transactions. Very rarely, the gateway itself pushes a probe transaction — usually documented in the gateway’s status logs but not always in the settlement file’s memo field.

The regulatory and PG-rules overlay

Ghost transactions sit at the intersection of three regulatory frameworks in India, all of which insist that every settlement credit and debit be traceable.

RBI Payment Aggregator framework (March 2020). The RBI’s guidelines on payment aggregators and payment gateways require that funds held in the escrow-linked nodal account be traceable to specific merchant transactions. When a settlement credit hits the merchant’s account, it must correspond to a real underlying sale, or a documented refund, or a documented fee reversal. A 98-paise credit with no underlying transaction is a compliance gap on the aggregator’s side — but the merchant also carries an evidence obligation to reconcile every credit to its books.

Merchant Discount Rate rules. MDR on domestic card transactions varies by card type and category. UPI (BHIM-UPI) and RuPay debit have zero MDR per the Ministry of Finance notification dated 30 December 2019. Premium and international credit cards carry higher MDR. The ghost residue pattern depends on the card path: a card-based ₹1 test leaves ~98 paise, a UPI-based ₹1 test should leave zero MDR but often leaves a small residue from failed-refund paths or reversal partials. Reconciliation platforms must apply the correct MDR schedule per card type when validating each settlement line, or else legitimate MDR deductions will be confused with ghost residues.

GSTR-1 and GSTR-3B alignment. Every credit in the settlement file that the merchant recognises as revenue must appear as an outward supply in GSTR-1 with a matching invoice number. Absorbing ghost residues into revenue means booking revenue with no invoice — either impossible in the ERP (which requires an invoice reference for every credit) or, if the ERP allows misc-credit entries, immediately flagging as an outward supply that has no invoice. GSTR-1 rejects this at filing. Absorbing into a “miscellaneous income” P&L line without invoice creation is possible but creates a permanent GSTR-1 vs settlement drift that GST officers query at audit.

Section 34 credit-note requirement. For legitimate refunds, Section 34 of the CGST Act requires a credit note against the original invoice. Ghost transactions have no original invoice — so there is no credit note obligation, but there is also no ITC reversal to claim. This asymmetry means ghosts sit outside the refund reconciliation workflow entirely and need their own handling path.

Section 194O TDS. For e-commerce-operator paths, TDS at 0.1% applies on the gross amount facilitated. A ₹1 test transaction on an e-commerce path could technically trigger a 0.1-paise TDS obligation on the aggregator’s side — negligible in isolation but conceptually important because it demonstrates that ghost transactions are not consequence-free even at the paise scale.

A worked example — illustrative numbers

Take an illustrative mid-scale streaming platform running on Razorpay. During a routine dev cycle, an engineer misconfigures an integration test to hit production. Over three weeks — the time it takes for QA to notice the settlement anomalies — the following flows through the pipe:

• Day 1, 14:22 IST: 47 test transactions of ₹1 each on the Razorpay production credentials. Refunds initiated at 14:45 IST. Settlement file for Day 1 shows 47 × ₹1 gross capture, 47 × ₹1 refund, 47 × 2p MDR retention, 47 × ~0p GST-on-MDR. Net residue: ~46.06 paise absorbed by Razorpay as fee, so merchant sees settlement reduced by ~₹0.94 (47 × 2p). Wait — the direction depends on booking convention. Let’s be precise:

  • Merchant nodal account: +₹47 (captures) − ₹47 (refunds) − ₹0.94 (MDR fees) − ₹0.17 (GST on fees, 18% of ₹0.94) = −₹1.11 net residue in the merchant’s favour, but on the fee side.
  • Settlement file appearance: the merchant sees 47 gross-capture lines, 47 refund-deduction lines, 47 MDR-fee-deduction lines, and 47 GST-on-fee-deduction lines. If the merchant’s ERP only ingests the net-settled amount, it sees −₹1.11 for the day with no offsetting invoice.

• Day 6, 09:15 IST: 128 test transactions of ₹1 each during a load-test rerun (the engineer thought they had switched to sandbox — they had not). Same pattern. Net residue: −₹3.02.

• Day 14, 17:40 IST: 89 test transactions during a CI/CD deployment probe. Net residue: −₹2.10.

• Day 20, 11:30 IST: 71 further test transactions before QA flags the anomaly. Net residue: −₹1.68.

Total residue over three weeks: −₹7.91 across 335 ghost transactions. The merchant’s settlement file has 1,340 individual line items (335 × 4 lines each) with no corresponding invoice. Month-end variance grows to −₹7.91.

At this scale, the finance team’s temptation is to absorb −₹7.91 into “settlement variance” and move on. Six months of similar occurrences at other environment misconfigurations grows this to −₹58 or more.

The correct handling:

1. Detection at Day 1. The reconciliation platform’s amount-range filter flags all 47 lines because the gross is ₹1 (below the ₹10 threshold). The no-invoice check confirms none of the payment_ids match any order in the subscription master. The no-customer check confirms none of the synthetic emails exist in the CRM. All 47 lines quarantine automatically.
2. Quarantine ledger entry. Each of the 47 lines is written to a dedicated ghost_quarantine table with fields: settlement_date, payment_id, gross_amount, mdr_amount, gst_on_mdr, net_residue, root_cause_tag (initially null), resolution_status (initially “open”).
3. Alert to engineering within 24 hours. The reconciliation platform’s alerting flags 47 ghosts on Razorpay production keys on Day 1. Engineering traces the root cause to the misconfigured integration test. The root_cause_tag is updated to env-misconfig-integration-test. The credential-leak point is patched.
4. Resolution. For Razorpay, gross-fee refund is possible via a support ticket if the volume justifies it — Razorpay can, on request, refund the MDR + GST-on-MDR component for test transactions confirmed as environment-misuse. Alternatively, the residue is written to a specific p&l:test_transaction_ghost line with documentation attached (integration-test logs, root-cause report, engineering sign-off). Either resolution is auditable.
5. Prevention. Engineering adds a hard guard: production API keys are gated behind a separate vault namespace that test harnesses cannot access. Sandbox keys are the only ones available to CI/CD and integration-test flows.

Under this handling, the settlement file’s main reconciliation loop never sees the 335 ghost lines. Month-end variance for the payment gateway is zero, because the ghosts are captured and resolved separately. GSTR-1 reconciles cleanly to settlement because no ghost residue is masquerading as revenue.

Common reconciliation breakages

• Ghosts absorbed into month-end variance. Finance treats sub-₹5 unexplained lines as “residual” and closes the period without investigation. Six months later, aggregate variance is large enough to require investigation, but the daily-level evidence trail is gone.

• Ghosts booked as miscellaneous income. ERP allows a misc-credit journal entry. Ghost residues are booked to a “gateway miscellaneous” income account. This creates a permanent GSTR-1 vs settlement drift because there is no invoice for the misc income. GST officer at audit asks: what supply generated this income? No answer possible.

• Ghosts booked as gateway fee variance. The ghost residue on the merchant side is negative — the merchant sees a ₹1.11 deduction with no matching capture credit. Finance books it as “additional gateway fee.” Now the P&L shows inflated payment gateway fee — which flows into gross margin analysis, unit economics reporting, and CFO reviews. The gateway fee looks worse than it actually is.

• Refund reconciliation confusion. The refund reconciliation workflow assumes every refund has an original invoice. Ghost refunds break this assumption. Reconciliation platforms that do not distinguish ghost refunds from real refunds pull ghosts into the credit-note obligation workflow — creating phantom credit-note requirements against nonexistent invoices.

• UPI ghost mistaken for a settlement break. UPI has zero MDR, so a ₹1 UPI test should leave zero residue. But failed refund paths or partial UPI reversals can leave a paise-level break. Without the ghost-detection filter, this appears as a genuine UPI settlement break — triggering an incorrect escalation to the UPI settlement reconciliation team.

• Same-value burst absorbed as noise. 200 × ₹1 transactions in a ten-minute window is a signature pattern of load-test misuse. Without burst detection as a fourth signal, each ₹1 line looks like a possibly-real small subscription trial. Only in aggregate does the pattern reveal itself.

• Chargeback simulation ghosts. Engineering runs a genuine chargeback flow to test the dispute workflow. The test involves a real refund followed by a real chargeback. Without documentation in the reconciliation ledger, the test appears as a genuine chargeback-loss reconciliation case — potentially triggering a customer-service investigation and dispute-desk escalation for an event that was engineering-initiated.

• Cross-gateway ghost blindness. A platform running Razorpay for cards and Cashfree for UPI runs test transactions on both. Each gateway’s ghost residue has a different pattern. Reconciliation platforms that apply a single ghost-detection rule miss one or the other.

• Legacy transaction file gaps. Ghost residues from months ago sit in an “unmatched” bucket. Attempting to reconcile them retrospectively is expensive because the gateway’s dispute window may have closed (Razorpay’s fee-refund window is typically 90 days). Early quarantine matters more than late investigation.

• Multiple test-account confusion. Some platforms have multiple gateway accounts for A/B testing, geographic segmentation, or currency-specific routing. A ghost in one account can look like a legitimate transaction in another. The no-invoice signal must apply per-account, not globally.

How a reconciliation platform handles this

A ghost-aware reconciliation workflow implements the three-signal detector as the first step in settlement file ingestion — before any other matching logic runs. Every settlement line with net absolute value below ₹5 and gross absolute value below ₹10 is a candidate. Each candidate is checked against the ERP order master, the subscription database, and the CRM. Candidates that fail all three lookups are routed to the ghost-quarantine ledger, not the main reconciliation queue.

The quarantine ledger is not a black hole. Every entry carries a root_cause_tag (initially null, populated by engineering-review workflow), a resolution_status (open, root-cause-identified, reversed-at-source, written-off-documented, false-positive), and links to the underlying settlement lines. A ghost that turns out to be a real (albeit tiny) transaction — for example, a genuine ₹1 subscription trial from a real customer with a matching invoice discovered later — is moved out of quarantine and back into the main flow. False positives happen and the workflow accommodates them.

The alerting layer flags ghosts by volume and by pattern. A single ghost is quarantined silently. Ten ghosts on the same gateway within a 24-hour window trigger a Slack alert to the engineering-liaison. A hundred ghosts trigger an escalation. Same-amount bursts (many ₹1 transactions in a narrow window) trigger burst-pattern alerts regardless of aggregate volume.

For each ghost, the platform generates a resolution record with three fields: root-cause description, action taken, evidence attached. If the resolution is “reversed at source,” the reversal reference from the gateway is attached. If the resolution is “written off,” the P&L line and the approval chain (engineering manager sign-off, finance controller sign-off) are attached. The Razorpay settlement reconciliation, PayU settlement reconciliation, and Cashfree settlement reconciliation workflows each carry their own ghost-detection thresholds because MDR and fee patterns differ per gateway.

The platform integrates with the MDR fee reconciliation workflow because ghost residues are almost always MDR-shaped — the ghost detection filter and the MDR validation filter share the same fee schedule per card type. A misconfigured MDR schedule that inflates the expected fee for a genuine ₹1 subscription is the mirror-image failure of ghost detection — legitimate small transactions get quarantined as ghosts. Correct configuration of both filters requires the canonical MDR schedule from the gateway.

Beyond the individual settlement platform, ghost-aware reconciliation feeds an evidence pack that closes the loop between engineering environment discipline and finance audit posture. Every ghost has an owner (engineering team), a root cause (env-misconfig or the equivalent), a resolution (reversed or written off with sign-off), and a preventative measure (vault namespace separation, sandbox-only credentials for CI). Six months of clean ghost handling produces a defensible position at both RBI-triggered PA audits and GST department audits: the merchant demonstrates that paise-level anomalies are captured, traced, and resolved — not absorbed into noise.

Structured payment gateway reconciliation implements the ghost-detection layer as part of the ingestion pipeline for every gateway file. Reconciliation software India automates the three-signal filter across high-frequency settlement volumes without requiring finance-team review of every paise-level residue.

The Reserve Bank of India’s Payment Aggregator framework is the regulatory anchor: every credit in the escrow-linked settlement flow must be traceable to a real merchant obligation. Ghost transactions — captured, quarantined, and resolved — meet the traceability standard. Absorbed into variance, they fail it.

The five FAQs below cover the residue calculation, quarantine rationale, detection logic, and UPI-specific variation.

Frequently Asked Questions

Terra Insight Editorial Team Reconciliation Infrastructure

Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →

Published 1 July 2026

Domain expertise

TDS Reconciliation GST Input Credit Platform Settlements NACH Batch Matching Bank Reconciliation Form 26AS Matching ERP Integrations Enterprise Finance Ops

Reviewed by

NK

Navin Krishnan

Managing Director & Founder — Terra Insight

Ex Amazon India · Intuit QuickBooks · Tata nexarc

ISO 27001:2022 Patent Pending Incorporated 2024