POS integration fundamentals

How digital receipts work with a POS system

A POS digital receipt flow connects an approved sale event to authenticated receipt creation, a customer QR and an optional Wallet claim.

Start with the completed POS event

The POS remains responsible for billing and the underlying sale. Receipt creation should begin only when the business has the facts needed for a valid customer receipt. A digital-receipt request is not a substitute for the POS transaction state.

Authenticate the business connection

An approved integration uses a POS connection key issued for its business context. Keep the key out of URLs, browser storage, source repositories, screenshots and support messages. Connection keys identify API clients; they are not customer passwords. [11]

Test before production receipt creation

The connection test confirms whether the supplied connection access is accepted. It consumes zero receipt credits. A successful test shows connectivity and access readiness; it does not prove every POS workflow, device or network condition. [1]

Use one stable operation identity

When the same receipt request must be retried, reuse the same idempotent operation identity. This allows the service to recognise the same intended operation instead of treating each retry as a new sale. Do not generate a new identity merely because a response was delayed.

Create the receipt and present the QR

After authenticated creation, the POS can show the customer the supported QR or receipt code. The POS must not place the connection key or another secret inside the QR or receipt fields.

Wallet claim and usage

A customer may claim the created receipt in TGT User Wallet. That claim consumes no additional receipt credit. Receipt creation is the usage-accounted operation under the current plan model; teams should monitor plan status and handle exhausted or inactive states safely. [1]

Business isolation and operational responsibility

Every request must remain bound to the authorised business context. POS teams should test negative cases, prevent cross-business references and treat audit information as operational evidence rather than a guarantee that fraud is impossible. [11]

Practical checklist

  • Complete business approval and plan activation.
  • Store the connection key in an appropriate secret store.
  • Run the zero-credit connection test.
  • Use a stable operation identity for the same sale.
  • Handle timeouts without creating a new receipt blindly.
  • Test disabled, expired and unauthorised responses.

Limitations

  • Detailed endpoints and private integration material are supplied only to approved partners.
  • No public guide can guarantee fraud prevention or uninterrupted availability.
  • POS teams remain responsible for their billing and local device behaviour.

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.