Security and shared responsibility

Digital receipt security for POS integrations

Protect digital receipt workflows with controlled identity, reveal-once connection keys, business isolation, safe retries and auditable operations.

Identity and access come first

Authorise people and POS clients for the functions and business records they actually need. Administrative and customer routes require separate access decisions. Deny-by-default testing is more reliable than assuming obscurity protects an endpoint. [11]

Handle connection keys as secrets

A POS connection key is revealed for controlled handling and should then be stored in an appropriate secret store. Do not place it in query strings, client-visible code, screenshots, public logs or receipt fields. The current business limit is two active connection keys. [1]

Test the connection safely

Use the supported connection test before receipt creation. It confirms access readiness and consumes zero receipt credits. Rotate or revoke access when custody is uncertain rather than continuing to share the same key informally. [1]

Maintain business isolation

Receipt creation, usage and administration must remain bound to the authorised business. Test that identifiers from another business cannot be read or acted on. Access control must be enforced by the service, not trusted from a client-supplied label. [11]

Use idempotent receipt creation

A stable operation identity helps the service recognise a retry of the same intended receipt. It reduces unintended duplicate creation; it does not make the entire system duplicate-proof under every misuse or external failure.

Protect QR and claim integrity

Display only the supported customer claim data. Do not embed merchant credentials. Customers should claim their own receipt, and support teams should investigate unexpected states without asking for passwords or connection keys.

Audit with honest limits

Operational logs can support diagnosis and accountability, but logs alone do not prove that fraud is impossible. Protect logs, minimise sensitive content and define who reviews unusual activity.

Practical checklist

  • Map person and POS-client roles.
  • Store and rotate keys under controlled custody.
  • Test cross-business denials.
  • Reuse the same operation identity for the same retry.
  • Keep secrets out of QR and receipt fields.
  • Review logs without claiming fraud-proof operation.

Limitations

  • No security control eliminates all risk.
  • The public guide omits private endpoints and key-generation internals.
  • Merchant devices, networks and staff practices are shared responsibilities.

Next steps

Report a correction

Sources and limitations

  1. TerraGridTech. Current product answers and operating limits (opens in a new tab). 2026-07-17. Accessed 2026-07-17.

    Scope: Current TerraGridTech production product scope. Limitation: Product operating facts, not environmental evidence; recheck after any plan or backend contract change.

  2. OWASP Foundation. OWASP API Security Top 10 – 2023 (opens in a new tab). 2023. Accessed 2026-07-17.

    Scope: International. Limitation: Awareness guidance, not a security certification and not proof that any product is invulnerable.