Apply for AI Grants India

Offline verifiable receipts are digitally signed records that can be checked without contacting the system that issued them. They are useful when connectivity is intermittent, devices are shared, transactions must be audited later, or a recipient needs immediate proof of payment or entitlement.

For Indian businesses, public programmes, fintech platforms, mobility operators, healthcare providers, and AI startups, this pattern can solve a practical problem: how to make a receipt trustworthy at the point of service while keeping verification possible in rural, low-bandwidth, or disconnected environments.

What Are Offline Verifiable Receipts?

An offline verifiable receipt is a portable record containing transaction details and cryptographic proof from an issuer. The verifier uses a public key, embedded software, or a previously distributed trust list to check whether:

• The receipt was issued by an authorised organisation.
• Its contents have not changed since signing.
• It is within its validity period.
• It has not already been redeemed, where replay protection is available.

A receipt may be represented as a QR code, NFC payload, barcode, signed PDF, compact text string, or record stored in a mobile wallet. Unlike a screenshot or ordinary PDF, it includes machine-verifiable evidence of authenticity.

The word “offline” usually means verification does not require a live API call. The issuer may create the receipt online or offline, and the verifier can validate it locally. Synchronisation can happen later when connectivity returns.

Why Offline Verification Matters

A conventional receipt is often a visual document. It may show a merchant name, amount, date, and reference number, but a verifier must contact the issuer or inspect the record manually to establish trust. That approach becomes fragile when a network is unavailable or the central service is overloaded.

Offline verifiable receipts provide several advantages:

• Resilience: Transactions can continue during outages or in low-connectivity areas.
• Lower operating cost: Routine verification need not trigger an online API request.
• Privacy: A verifier can validate a signature without uploading personal data.
• Auditability: The signed payload preserves what the issuer actually attested to.
• Interoperability: Standardised formats can work across vendors and applications.
• Faster service: Staff can validate a receipt at a checkpoint, clinic, warehouse, or field location in seconds.

In India, these benefits are relevant to rural commerce, public distribution, transport, last-mile delivery, agricultural procurement, education credentials, insurance claims, and offline-first digital public infrastructure.

How Offline Verifiable Receipts Work

A secure implementation normally has five components:

1. Issuer: The merchant, platform, government agency, or service provider that creates the receipt.
2. Payload: Structured data describing the event or transaction.
3. Signing system: A protected private key that signs the payload.
4. Verifier: An app, scanner, browser, or device that checks the signature.
5. Trust registry: The public key and rules needed to determine whether the issuer is authorised.

The basic flow is:

1. The issuer creates a canonical receipt payload.
2. The payload is hashed and signed with the issuer’s private key.
3. The signed payload and signature are encoded into a QR code or other transport format.
4. A verifier scans or imports the receipt.
5. The verifier reconstructs the exact payload, checks the signature using the issuer’s public key, validates timestamps and policy rules, and displays the result.
6. If needed, the verifier records the receipt locally and synchronises redemption status later.

The central design principle is that the verifier must not merely decode the receipt. Decoding shows what the data says; cryptographic verification shows whether an authorised issuer signed that exact data.

Receipt Data Model

A receipt should contain only the fields required for the business and verification task. A typical JSON payload might include:

{
  "version": "1.0",
  "issuer_id": "merchant-4821",
  "receipt_id": "rcpt-2026-000184",
  "issued_at": "2026-10-10T09:30:00Z",
  "valid_until": "2026-10-17T23:59:59Z",
  "currency": "INR",
  "amount_minor": 125000,
  "purpose": "service_payment",
  "subject_reference": "masked-customer-reference",
  "key_id": "issuer-key-03"
}

Use integer minor units, such as paise, rather than floating-point currency values. Define a canonical serialisation rule, including field ordering, character encoding, whitespace handling, and number formats. Without canonicalisation, the issuer and verifier may calculate different hashes for semantically identical data.

Avoid embedding unnecessary Aadhaar numbers, full bank account details, health information, or other sensitive personal data. Prefer tokenised references, selective disclosure, or encrypted fields where the verifier genuinely needs additional information.

Cryptographic Design Choices

Digital signatures

Digital signatures are the foundation of offline verifiability. The issuer signs the receipt with a private key, while verifiers use the corresponding public key. Common options include Ed25519, ECDSA, and RSA, although the choice should align with the platform’s libraries, compliance requirements, and hardware support.

For QR-based receipts, compact signature schemes are often preferable because QR capacity is limited. The signature algorithm alone is not enough: the implementation must also define key sizes, hashing, encoding, canonicalisation, and key rotation.

Hashes and identifiers

A cryptographic hash can create a stable receipt fingerprint and help detect changes. However, a hash without a trusted signature does not prove who created the record. Use hashes for integrity and deduplication, and digital signatures for issuer authenticity.

Public-key distribution

A verifier must know which public key to trust. Options include:

• A periodically updated signed trust list.
• Keys provisioned in a verifier application.
• A certificate chain or public-key infrastructure.
• A government or industry registry.
• A previously synchronised issuer directory.

The trust list itself must be authenticated and should include key identifiers, issuer status, validity periods, and revocation information.

Replay, Fraud, and Revocation Controls

A valid signature does not automatically mean a receipt is still redeemable. An attacker could copy a genuine QR code and present it multiple times. Systems that represent money, subsidies, tickets, inventory, or access rights need replay controls.

Useful controls include:

• A globally unique receipt ID.
• A short validity window.
• A nonce or transaction sequence number.
• Device-bound or recipient-bound claims where appropriate.
• Local redemption logs.
• Signed revocation or suspension lists.
• Post-connection reconciliation with the issuer.
• Risk limits for offline transactions.

There is an unavoidable trade-off: if a verifier is completely offline and has never synchronised, it cannot know that a receipt was redeemed elsewhere after the last update. High-value use cases should therefore limit offline authority, require periodic synchronisation, or use hardware-backed counters and controlled devices.

QR Codes, NFC, and Signed Documents

QR codes

QR codes are practical because low-cost Android phones can scan them and paper copies can carry them. Keep the payload compact by using short field names, binary encodings, or a standards-based compact serialisation. Include an error-correction level suitable for printed material, but test readability under glare, low light, damaged paper, and inexpensive cameras.

NFC

NFC can provide a faster tap-based experience and may support secure elements or tamper-resistant tags. It is useful for transit, access control, asset tracking, and reusable cards, but requires compatible hardware and stronger operational controls against tag replacement.

Signed PDFs and printed receipts

A signed PDF can preserve human-readable information while carrying an embedded machine-readable payload. For paper receipts, print both the readable summary and a QR code. Never treat a logo, stamp, or reference number as a cryptographic proof.

India-Specific Implementation Considerations

Indian deployments must account for multilingual users, Android device diversity, intermittent mobile data, and highly variable power and hardware conditions. Design for Hindi and regional languages where users interact with the receipt, while keeping the signed payload language-neutral and consistently encoded.

For payments and financial records, distinguish a merchant receipt from proof of settlement. A signed merchant receipt may confirm that a merchant issued a claim, but settlement status may require a bank, card network, UPI participant, or other authorised source. Do not imply regulatory approval merely because a record is digitally signed.

Data protection also matters. Under India’s Digital Personal Data Protection framework, organisations should minimise personal data, define a legitimate purpose, control retention, and protect records from unauthorised access. Offline storage creates additional risks because lost phones, shared devices, screenshots, and exported files may expose data.

For government or regulated workflows, check applicable requirements from the relevant ministry, sector regulator, payment network, electronic-record rules, and procurement standard. Use open documentation and clear governance so that another authorised verifier can validate the receipt without depending on a single vendor.

Security Architecture and Key Management

Private-key compromise is one of the most serious failure modes. Store issuer keys in a hardware security module, cloud HSM, trusted execution environment, or secure element where feasible. Restrict signing access, separate development and production keys, and require approval for key creation and rotation.

A production key-management plan should define:

• Key generation and custody.
• Role-based signing permissions.
• Key rotation schedules.
• Emergency revocation.
• Backups and disaster recovery.
• Compromise investigation.
• Audit logs for every signing operation.

Every receipt should identify the signing key or key version. Verifiers need deterministic rules for handling expired, revoked, or unknown keys. Test malformed payloads, altered amounts, changed dates, invalid encodings, truncated signatures, oversized inputs, and algorithm substitution attacks.

Offline-First User Experience

Cryptographic correctness is not enough if field staff cannot understand the result. A verifier should clearly display statuses such as:

• Valid: Signature and policy checks passed.
• Valid, redemption unknown: Authentic receipt, but no current online redemption information.
• Expired: Signature may be valid, but the allowed time window has ended.
• Already redeemed: Local or synchronised records show prior use.
• Unknown issuer or key: Trust information is missing or invalid.
• Tampered or invalid: The payload or signature failed verification.

Do not display a reassuring green tick for a signature that passed but whose business rules failed. Explain what was checked, when the trust list was last updated, and what action staff should take for exceptions.

Testing and Operational Metrics

Test the full lifecycle rather than only the cryptographic function. Important test areas include:

• Verification with no network, slow network, and captive portals.
• Clock drift on low-cost Android devices.
• Duplicate scans and concurrent redemption.
• Key rotation and revocation updates.
• Damaged, folded, blurred, or photocopied QR codes.
• Unicode, regional scripts, and non-ASCII merchant names.
• App upgrades and backward compatibility.
• Lost devices and local database extraction.
• High-volume reconciliation after connectivity returns.

Track verification latency, scan success rate, offline queue size, duplicate attempts, failed signatures, stale trust lists, reconciliation conflicts, and key-related incidents. These metrics reveal whether the system works in real field conditions rather than only in a laboratory.

Common Mistakes to Avoid

• Treating a QR code as security without a digital signature.
• Signing a mutable database ID instead of the actual receipt claims.
• Using floating-point amounts.
• Omitting expiry or replay protection.
• Embedding excessive personal information.
• Allowing verifiers to trust any key supplied inside the receipt.
• Failing to plan key revocation and rotation.
• Assuming offline verification can prove real-time settlement.
• Ignoring device theft, screenshots, and local database extraction.
• Designing only for reliable 4G and modern flagship phones.

A Practical Rollout Plan

Start with a narrow, low-risk use case such as service completion, delivery acknowledgement, or attendance confirmation. Define the claim, threat model, acceptable offline duration, and consequences of a duplicate or false receipt.

Next, implement a versioned payload, canonical encoding, signature verification, trust-list updates, and local audit logging. Pilot with real devices and printed receipts in the locations where connectivity is weakest. Measure operational failures and train staff to interpret every verification status.

Only then expand to high-value payments, benefits, tickets, or identity-linked records. Introduce stronger device security, reconciliation controls, independent security review, and formal governance as the risk level increases.

FAQ: Offline Verifiable Receipts

Can an offline receipt be verified without internet?

Yes. If the verifier already has the issuer’s trusted public key and validation rules, it can check the signature and receipt fields locally. Internet access may still be needed later for trust-list updates, revocation, or redemption reconciliation.

Is a screenshot a verifiable receipt?

A screenshot is verifiable only if it preserves a signed payload in a supported format and the verifier checks that signature. A visible transaction number or logo alone is not proof of authenticity.

Can offline receipts prevent double spending?

They can reduce fraud through unique IDs, expiry, local logs, device controls, and later reconciliation. Complete prevention is difficult when multiple verifiers remain disconnected and must accept the same value independently.

Are offline verifiable receipts legal in India?

Digital records and signatures may be usable in India, but legal effect depends on the transaction, sector, issuer, and applicable regulations. Obtain specialist legal and compliance advice for regulated or government workflows.

Apply for AI Grants India

Building an AI product for trustworthy offline transactions, digital public infrastructure, or resilient field operations? Apply to AI Grants India for support, funding opportunities, and guidance for Indian AI founders.