Ecommerce Integration

In its simplest sense, ecommerce describes the process of buying and selling goods (along with services) online, over the internet. Most ecommerce happens over mobile phones in digital spaces represented by channels:

  • Mobile - Simple and quick shopping managed on hand held devices such as smart phones and tablets.

  • Social - Full shopping experiences - from browsing to checkout - conducted on sophisticated social media platforms.

  • Web - Well marketed and efficient web sites showcasing brands and products accessible via mobile phones or computer desktops.

These digital forms of retail shopping often culminate in products being delivered straight to the door of a customer's home.

The integration of an ecommerce system is particularly effective if it can rely on a previously integrated web or app vendor to handle the customer's (user's) point of entry. If a vendor app or site is already integrated, the customer can log in and be authenticated before they perform any transactions via an ecommerce system. When customers are validated as "known" users with known SessionM IDs, any associated ecommerce transactions are simpler to manage. No need to use a typically heavy API call to look them up along with their offers. Instead, you can get user offers (not reward store offers) directly and then support customer purchase decisions by unlocking, redeeming or even reinstating them. Once complete, the offers can be applied and sent as a transaction.

Via this approach, all of the customer's loyalty data is readily accessible, including their point balances, profile, campaigns, and offers. For example, consider this principle as it might be implemented in a sample app or on a web site. The customer would log in and be authenticated in a custom app. They would then navigate to a transaction page where they could view their available offers. Now they can simply pick one and place the order with a quick click of its corresponding "Order Now!" button. From the customer's perspective, the ecommerce opportunity is a seamless, embedded part of the web or app vendor integration. But, technically, it's a separate integration.

Bear in mind that ecommerce integrations don't have to rely on a previous web or app vendor integration to allow their customers to acquire and apply offers. A customer could have purchased an offer before performing a transaction with an ecommerce system.

The integration under discussion in this topic is highlighted in the image below.

An ecommerce integration provides customers with the ability to engage in transactions over a variety of internet environments. Once a system is integrated with SessionM, you can use platform APIs to make real-time communication and transactional calls for a variety of use cases. The following core tasks are critical when implementing ecommerce use cases for customers:

  • Get user offers
  • Locking offers
  • Unlocking offers
  • Redeeming offers
  • Reinstating offers
  • Sending transactions

Key Integration Endpoints

While this topic does focus on the standard aspects of an ecommerce 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 ecommerce integration:

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

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.