PIING
How a store visit reaches your connected tools
What a check-in contains, which systems receive it, and why reading a loyalty balance is different from awarding points.
In this article
Record the visit once.
When a member is recognised in store, Piing records who checked in, where, when and through which recognition route. That visit can then be used by the destinations the merchant has configured.
A destination receives its own payload. The customer identifier, enabled event types and provider credentials need to be agreed during setup. Connecting a tool does not mean every event should be sent to it.
One customer, online and in store.
Read customer and order details. Write selected visit fields to Shopify customer metafields for POS, segments and Flow.
Keep the source of truth clear.
The commerce platform owns the customer and order records. A connected loyalty provider owns its points balance and tier rules. A wishlist tool owns the products a customer has saved.
Piing reads selected context from those systems and sends the configured visit events or updates back. Reading a loyalty balance for the pass is not permission to award points. Visit rewards are a separate configuration.
Wallet updates also depend on the pass provider and device. Avoid designing a store workflow that assumes every change appears instantly on every phone.
Send an outcome, not just an arrival.
A recognised visit followed by an eligible order is different from a visit without a purchase. Piing can record those outcomes within the attribution window the merchant chooses.
Sofia Smith
- Store
- Soho
- Last visit
- Today, 12:04
Two possible outcomes.
Each can start a different flow.
A purchase follows.
A qualifying order within your attribution window.
- Event
- Purchase event
- Your flow
- Post-purchase care
No purchase follows.
No qualifying order after your chosen no-purchase window.
- Event
- No-purchase event
- Your flow
- A helpful follow-up
Your reward rules apply. Klaviyo controls who receives a message and when.
Your CRM can use selected events in its own flows, with its existing consent, suppression and frequency rules. Sometimes the right follow-up is no message.
Make delivery problems visible.
Each configured destination is handled separately. A provider outage or an invalid credential should be investigated as a delivery issue, not treated as evidence that the store visit never happened.
During setup, test the expected customer match, inspect a sample payload, confirm receipt at the destination and rehearse a failed delivery. Check the destination's plan and API access as well as the settings in Piing.
Signed webhooks provide a route to other systems. Implement only the documented event contract, verify signatures on the receiving server and handle repeat deliveries safely.
Start with the connection you will use.
For a first pilot, that might be Shopify customer recognition plus one CRM destination. Add loyalty reads, wishlist context or further event types when there is an agreed use for them.
Changing a provider can require new credentials, identifiers, mappings and a fresh acceptance test. It should not be treated as a switch that needs no validation.
Explore the integration directory and event catalogue. For a non-Shopify platform or a custom staff workflow, scope the connection through Retail ID.