PIING
Security and data boundary
Your customer record. Still yours.
Piing processes the customer and visit data needed for the features a merchant enables. The commerce platform remains the primary customer record, and every connected read and write is configured around a purpose.
Your customers and orders remain in your platform.
Visit records and selected data for the features you enable.
No facial recognition. No payment card details.
Data inventory
What Piing handles, and why.
Feature-dependent data may be processed or retained. The exact fields, retention and deletion rules depend on the product and configuration.
Store, time, source and the operational references needed for attribution
Settings needed to run readers, kiosks, Wallet passes and locations
Connected destinations, subscribed events and delivery status
Audience rules plus consent-gated impressions, opens, clicks and attributed orders
Account, administrative and delivery records used to operate and support the service
Selected Intelligence outputs are written to app-owned customer metafields in the merchant's store. The merchant chooses which fields are enabled.
The data path
One check-in.
Clear responsibilities.
Your commerce platform keeps the primary customer record. Piing identifies the customer, runs the features you have enabled and sends the agreed events to your connected tools.
A kiosk, printed QR, reader or staff action creates a request with the store, source and route identifier.
Piing matches through the connected system, records the visit and runs only the pass, staff, event and attribution workflows enabled.
Selected events and values return to commerce, CRM, loyalty or the retailer's own endpoint.
The identifier, event context and customer data required for the configured workflow
Pass updates, staff responses, signed events and selected values written back to the stack
Payment card details · facial templates · biometric profiles
Controls and governance
Review the service before rollout.
Use these controls alongside the product-specific data flows, access roles and contractual documents in your security review.
01Encryption
Connections to Piing services use HTTPS. Sensitive credentials and stored data use the controls provided by the infrastructure and platform services.
02Access
Administrative access is restricted to authorised people. Merchant and integration access is scoped to the relevant store or organisation.
03Store separation
Operational records and requests are scoped to the merchant, store and location they belong to.
04Integration security
Credentials are scoped to the connected service. Webhook signing and validation are used where the destination supports them.
05Consent
Piing: Alerts uses first-party storefront signals and records optional engagement only where the merchant's consent configuration permits it.
06Recognition
Piing recognises through Wallet, QR, linked NFC or a staff action. It does not use facial recognition.
01Roles
The merchant remains controller of its customer data. Piing acts as processor when handling that data to provide the contracted service.
02Data minimisation
Each product requests and uses the data needed for the features the merchant enables.
03DPA
The Data Processing Addendum sets out scope, security commitments, sub-processors and support for data subject requests.
04Retention
Retention depends on the record and product. Operational event and delivery logs are kept for defined support and analytics periods, then deleted or aggregated.
05Deletion
Merchants can request account deletion and assistance with customer data rights. Shopify-owned outputs can also be managed in the merchant's store.
06Payments
Shopify app subscriptions use Shopify Billing. Retail ID follows its direct agreement. Piing does not handle payment card details.
Security review
Bring the architecture questions before procurement.
We can walk through the data boundary, connected systems, product-specific flows and the documents needed by the retailer's security and privacy teams.