Invoice Cum Receipt
When a merchant approves a C Pay request, C Pay emails an Invoice Cum Receipt (ICR). It is a PDF record of that recharge payment. It is not a GST tax invoice. It exists so the customer and the merchant both have the same numbers: who paid, how much, which app, which UTR, and which shop handled it.
When it is sent
The PDF goes out on approve — from the merchant portal, from C Us approve, or from Telegram approve when that path is used. The same document can be resent later from the merchant Transactions screen (merchant login only). Resend does not approve a second time and does not deduct stock again.
Who is on the To line
C Pay sends one email. The To line lists the customer address and the merchant address together. There is no CC. Mail systems deliver a copy to each inbox. If the customer used a disposable mailbox, the merchant still receives the To copy. That design exists because merchants missed receipts when they were only CC.
What is inside
Typical fields: payer display name, customer profile name when different, mobile, app name, user ID, amount in rupees, UTR, coins, date, and merchant identity. If the merchant edited amount, app, or coins before approve, the PDF uses those saved values. If they edited after approve, the original receipt already left — use Resend after the edit only if your process needs a matching PDF; stock will not reverse automatically.
What to do if you did not get it
Check spam. Confirm the email on your C Pay profile. Ask the merchant to Resend. The merchant should not screenshot a private ledger instead of the official PDF when the customer only needs proof of the recharge payment. For Hub privacy wording see Privacy Policy. Product questions: info@conserworks.in.
What the PDF is not
The Invoice Cum Receipt is not GST output tax documentation. It does not replace a tax invoice from the live app, the shop’s GST registration, or a bank statement. It is Conserworks C Pay’s record of one approved recharge payment: the rupees the merchant accepted, the UTR they matched, and the app/user identity on that request. If a customer needs GST from the shop, that is a separate conversation with the merchant, not a button on this Hub.
Customer vs merchant copy
Both addresses are on the same To line so both parties see identical fields. The customer uses it as proof they paid this shop this UTR. The merchant uses it as a paper trail when a customer later claims a different amount. If the merchant’s mailbox rejects mail, the customer may still receive theirs — then the merchant should fix their profile email and use Resend, not invent a second PDF in Word.
Timing relative to coins
Email goes out when C Pay records approve. Live-app coins are credited by the shop’s recharge process. Those two clocks are related but not the same second. Do not treat a missing PDF as “coins failed”, and do not treat a received PDF as “coins already in the live app” until the shop confirms. If approve happened and mail is delayed, Resend is the supported path.
Edits after the first email
Pencil edits on App, Amount, Coins, or UTR after approve update the merchant database and sheet. They do not automatically fire a new PDF or reverse stock. Resend after an edit produces a PDF that matches the current saved row. Only do that when you intend the customer to see the corrected numbers. Accidental Resend is still one document, not a second payment.
See also merchant Transactions and customer flow.