PIING
Reading Apps and platformsHow Piing fits your stack
Apps and platforms
- The Piing platform
- How Piing: Intelligence fits your stack
- Retail ID for non-Shopify retailers
- Supported platforms and integrations
- How Piing fits your stack
In this guide
- What each system owns
- What Piing adds
- The flow
- Current connections
- Data boundary
- A practical example
- Next steps
Search or browse documentation
Apps and platforms 5 / 5
How Piing fits your stack
Piing adds a known physical visit, a Wallet channel and measurable outcomes while commerce, loyalty and CRM keep their existing roles.
Piing is a recognition and Wallet layer between the physical store and the systems the retailer already runs. It does not ask the retailer to replace commerce, loyalty or CRM. It gives those systems a known visit and the context needed to act on it.
What each system owns
- Commerce remains the primary customer and order record.
- Loyalty continues to own points, tiers, rewards and programme rules.
- CRM and messaging continue to own journeys and channel consent.
- Wishlist tools continue to own saved-item intent.
- Piing owns the in-store recognition routes, Wallet experience, visit record, attribution workflow and delivery of configured events.
- Piing: Intelligence writes selected analysis output to Shopify metafields.
- Piing: Alerts owns the notification feed rendered inside a Shopify theme and its first-party engagement and attribution records.
What Piing adds
A known visit
A kiosk, Piing reader, printed QR sign or Shopify POS action creates a check-in with the store, time, source and customer reference. The same event model applies across all four routes.
A useful pass
The Apple or Google Wallet pass can show loyalty values, Shopify store credit, merchant-controlled tiers, visit milestones or simple membership status. Merchant-configured Wallet messages keep the pass useful after installation.
A measurable outcome
The merchant configures the window used to relate a later order to the visit. Piing distinguishes a visit followed by an attributed order from one whose window closes without a purchase. That gives the CRM and reporting layer two different signals rather than treating every visitor as the same.
The flow
- The customer identifies themselves in store.
- Piing resolves the context needed for the configured route.
- The visit lands in Piing with its source and location.
- The staff view, Wallet pass, Shopify metafields and enabled destinations receive the relevant output.
- A later order or the end of the attribution window creates the appropriate outcome.
- The merchant can report on visits, routes, locations, attributed orders and attributed revenue.
Current connections
- Shopify and Shopify POS
- Klaviyo, Attentive, Ometria and HubSpot
- LoyaltyLion, Rivo, Yotpo and Antavo
- Swym Wishlist Plus, Wishlist King and supported customer metafields
- signed webhooks for custom destinations
Retail ID scopes non-Shopify and bespoke commerce connections. Fuego can work alongside Piing as a mobile-commerce layer and is not presented as the loyalty engine.
Data boundary
The merchant remains controller of customer data. Piing processes the identifiers, customer context and events required for the enabled features and stores the operational records needed to run the service. Selected outputs return to Shopify or the connected destinations. Piing does not process payment card details or use biometric recognition. See Security.
A practical example
A Gold member checks in at the Soho kiosk. The staff view shows the tier, current points, store credit, recent visits and selected saved-item context. Piing records the visit and sends the configured check-in event to Klaviyo. If the same customer buys within the merchant's attribution window, the order becomes an attributed purchase. If the window closes without an order, the no-purchase event can trigger a different, consent-aware journey.
Next steps
Related guides
Was this guide helpful?
You’ve reached the end of Apps and platforms.
Still need a hand? Contact us