Point of Sale Integration

The customer's experience using any POS system is a critical component of any purchasing journey, whether purchasing items online or at a checkout counter. The three key components of integrating into any POS system are identifying customers, facilitating rewards/offers, and ensuring transaction data is sent programmatically to the loyalty system where it can be captured in the customer's member history.

A POS system can contain multiple channels to represent a variety of integration paths. For example, a full-service restaurant might designate channels for the bar, the main dining room, and the patio. Or a pizza place might offer channels for online delivery and pickup.

Note that known customers do not have access a POS system because it cannot know the customers before they log into the system. They might be accessing a web location anonymously or even just showing up at a brick-and-mortar location. Once arrived, they would need to provide their phone number, which the POS system cloud then use to look up their identity. In short, the POS system must work to identify a customer it knows nothing about. In this context, it's more likely that the customer would have already acquired an offer via their phone and have stored it in their wallet before accessing a POS system.

The POS system provides a foundation for transactions occurring in the retail, QSR and airline industries. Over time, these systems capture important data pertaining to customer preferences and habits - much of which can be represented in the customer's profile. The integration under discussion in this topic is highlighted in the image below.

A POS integration handles systems containing data from customers and transaction systems. Once a system is integrated with SessionM, you can use platform APIs to make real-time calls for the communications and transactions required for a variety of use cases. The following core tasks are critical when implementing POS use cases:

Looking up customers, which searches for customers and returns customer details and available offers
Retrieving offers
Purchasing offers
Redeeming offers
Processing transactions

Key Integration Endpoints

While this topic does focus on the standard aspects of a POS integration, each implementation can contain specific transaction data points specific to business, or vertical, needs.

The diagram below depicts the key endpoints enabling a standard POS integration:

You can access technical details for each of the endpoints featured in this graphic using the links below:

Endpoint that specifies /lookup in its path
Endpoint that specifies /lock or /unlock in its path
Endpoint that specifies /redeem or /reinstate in its path
Endpoint that specifies /send_transaction in its path

Integration Best Practices

As you move forward with your integration, bear in mind several best practices that can help ensure a successful SessionM implementation.

Offer Lookups with or without Transaction Data

Consider that there are two ways to use payloads in offer lookups:

No transaction data included in the payload: In this case, all currently issued (un-expired) offers are retrieved and displayed in the customer's wallet. This approach is ideal for use cases in which customers identify themselves at the start of an interaction.
Transaction data is included in the payload: In this case, the transaction data filters the offers returned to only the ones applicable to the current basket. This approach is ideal for use cases that in which the lookup call is made near the end of the transaction, when the basket is being prepared and the customer is about to make the actual purchase.

If a transaction is being updated multiple times, bear in mind it's a heavy load; the lookup must do the following: get profile, get points, get offers and verify offers vs. transactions. When multiple updates are expected, it's best to use the lock route discussed below.

Lock/Unlock vs. Redeem/Reinstate

Lock/Unlock is a good model when expecting customers may abandon the transaction, walking away from it without warning. In this case, customers cannot be seen because they are online and are abandoning their carts without anyone knowing it. Remember that long locks keep things in cache for extended periods. So the default for a lock via SessionM is 15 minutes.

On the other hand, Redeem/Reinstate is an excellent model when customers CAN be seen in person or when there is a known and extended period of time between offer redemption and the final transaction being sent to SessionM. No need for the lock and corresponding unlock to ensure nothing gets locked and unusable for a prolonged period. When customers abandon their carts, it's because they leave the store.

Send or Redeem Transactions for Specifying Taxes

The tax_included field, which is in the payload's items section, specifies how much tax is associated with the item.

In the transaction header, there is a tax_total field. Note that this is not a summary. It could be either an item-level tax which is good for representing municipal and local taxes. Or, it could be a tax on the whole, which is appropriate for sales tax.

Send Transaction

A few best practices for sending transactions:

Use the actual SKUs associated with the transaction.
SessionM does not handle negative amounts for items or sub-items. Instead when updating a customer account, you can remove unwanted items.
Items and payment do have positive values. Sub transactions should be in the discount section of payload.
Ensure uniqueness in transaction ID. Doing so avoids overwriting existing transactions and results in an implementation's loyalty calculator.