Getting Started
The Point of Sale (POS) integration guide includes extensive and reference materials to aid POS system's developers for integrating any POS system with CRM.COM Rewards platform, using a set of recommended Web API methods provided by CRM.COMtest
CRM.COM Rewards application is designed to cover any business operations that aim to identify and award their loyal customers, via numerous reward offers. Such offers award loyal customers with conditional (or not) cashback that can be consumed on specific products, units (different merchant' stores), and specific days/hours or at the customer's discretion (with no conditions) without having any dedicated operations on the POS side (awards are agnostic to the POS system) CRM.COM supports two reduction methods that define how the amount that is requested to be consumed (spend) by the customer will be reduced from the total amount that should be paid Point of Sale (POS) is the system that is used by an agent (cashier) to sell goods to a customer and collect the due amount in usually a face to face (over the counter) manner The following section lists a number of definitions that describe the key points in a POS & CRM.COM Rewards integration flow The customer is identified on the POS system by providing an identification mean, such as email address, phone number or card number A customer's basket is closed when the last intended product to be purchased is submitted in the POS (i.e. cashier counter) and no other adjustments (i.e. add/remove product) will be made Award is the amount that will be provided to the customer in the form of cashback when closing a customer's basket (given that the purchased products are eligible for an award based on a valid reward offer) Spend is the awarded amount that will be deducted from the basket's total amount that the customer should pay for. The amount that a customer can spend is the total amount that the customer was awarded from previous purchases During the process of awarding a customer's purchased products, some products may do not exist in CRM.COM yet (due to a time-frame gap with the product synchorisation runs) Such products can be handled entirely by CRM.COM using a default purchased product without interrupting the POS flow, and once the related record is created in CRM.COM the merchant can retrieve the intended purchased products for further analysis The steps bellow describe a common scenario how to integrate a POS system with CRM.COM Rewards Prior closing the customer's basket, the POS agent can preview the behavior of the award and spend (automatic, instant, and additional) based on the customer's basket The following diagram illustrates the integration architecture and key points CRM.COM Product Synchronization allows a POS system to add or update a group of products that exist in the POS with the ones in CRM.COM usually through a background batch process, resulting into creating new products or update existing ones (e.g. name, description, category) in the CRM.COM Products are physical goods that can be used by any type of business transaction within CRM.COM software. Products are classified into services and physical goods. They can be sold rented or simply used by customers through multiple business events such as subscriptions, jobs, activities, direct sales and can also be awarded to reward participants through rewards In addition, Products in CRM.COM have a set of attributes (type, brand, family, categories) that are used to determine their operational characteristics, define trademarks and group products based on common physical characteristics Product Type is used to determine the operational characteristics of products, and classify a product as a physical good or a service and what kind of a good or service is (i.e. termed, usage, traceable, non-traceable). For POS integration purposes, all products should have a product type that classifies products as non-traceable physical goods Product Brand is used to define trademarks or distinctive names that serve to identify a specific Product Product Family is used to group products that derive from a common product platform and have similar physical characteristics Product Categories are used to classify products into generic groups based on specified shared attributes Putting it all together Now that we have laid out all product attributes, let's put them together and present a couple examples of Products in CRM.COM Smartphone, Android phone, Octa-core processor TV, QLED, 4K resolution Brownie, Chocolate, Diary Product Synchronization can be achieved using CRM.COM Web API methods that a POS system can call periodically in order to synchronize product information between POS and CRM.COM The following diagram illustrates the integration architecture and key pointsCRM.COM Rewards & POS Ecosystem
What is CRM.COM Rewards?
What is Point of Sale?
Important Key Definitions
Identify Customer Create Customer Basket A customer's basket is created when a set of products that is intended to be bought by the customer is presented to the POS (i.e. cashier counter) for submission Close Customer Basket Complete Payment Completing a payment is the process where the customer is prompted to pay for the purchased products via any form of payment, such as cash, credit cards, and awarded cashback Award Spend Default Purchased Product How to integrate your POS system to CRM.COM
CRM.COM & POS Product Synchronization
What is a CRM.COM Product?
Product Type
Product Brand
Product Family
Product Categories
No. Product Product Type Product Brand Product Family Product Categories 1 Galaxy Note 9 Technology Samsung Smartphones 2 Samsung MU6070 Technology Samsung QLED TV 3 Brownie Comestibles Yummy Chocolates Chocolates 4 Croissant Double Comestibles 7 Days Croissant Croissant, Chocolate, Vanilla 5 Iced Caramel Latte Coffee Coffee Brewers Coffee Coffee, Milk, Latte, Syrup How Product Synchronization between POS and CRM.COM works
Setup and Integration
Prior proceeding to the integration implementation, let's walk through a few basic API concepts that will be required on each subsequently method
The following sections include extensive and reference materials to aid POS system's developers for integrating any POS system with CRM.COM Rewards platform, using a set of recommended Web API concepts and methods provided by CRM.COM Before performing any logical unit of work, an authentication token must be acquired and subsequently will be used by all other Web API methods in order to access and performed any operations in the system. All API requests must be made using a valid authentication token, otherwise such requests will fail Acquiring an authentication token can be accomplished by using one of the following methods Recommended Authentication Method The recommended method of authentication is using Web API Keys of a "System Key" classification. Web API Keys are assigned to specific users in order to access a specific organization and can be used to authenticate users through Web API, resulting to an authentication token that can subsequently be used by other Web API calls, without any data restrictions The authentication Web API call that should be performed is POST authentication/web_api_key/token (based on HTTP Basic Auth) Web API Key Method Example CRM.COM Web APIs offer the ability to select the fields that will be retrieved from each API method by specifying the "fields_set" input parameter Using this parameter developers have the ability to filter the response object and retrieve only the fields that will be used for the desired implementation. If "fields_set" is not specified, then all fields of the response will be retrieved The "fields_set" attribute is used for each call throughout the entire integration guide There are some API methods that retrieve a large number of entities, such as list API methods. Some of these CRM.COM API methods provide the option to apply pagination on the results retrieved In such cases the API call should be constructed using the following input parameters The flow described below is an example of a POS integration with CRM.COM Rewards The customer is identified on the POS system by providing an email address, a phone number, a card number, etc Identifying a customer in CRM.COM (also referred as rewards participant) should be performed using the POST rewards_participants/show method The following identification means can be used to identify a customer in CRM.COM Prior Customer Identification Once a customer is identified in CRM.COM, then the full information of the customer is returned back to the POS system The following information can be displayed on the POS screen After Customer Identification POS Conceptual Examples Prior completing the sales transaction on POS, customer may request to know their available balance and the amount that are eligible to spend on the related transaction. The preview method will determine whether the purchase customer event that will be submitted can be performed (spend) by the Front-End System (i.e. POS) or by a Back-End System Previewing such information should be performed using the POST customer_events/purchases/preview method, and the following information should be passed to CRM.COM Not Applicable Once performing such action is completed, the POS system can display the related award and spend amount information that are eligible for the current customer's basket products that were submitted to the POS The following information can be displayed on the POS screen The reduction method (reduction_method) The amount that will be spend automatically, without the customer's request (the sum of total_instant_spend_amount and total_automatic_spend_amount) The amount to be awarded (total_award_amount) After Preview Once all products are registered in the POS, the sales transaction should be submitted in CRM.COM in the form of a purchase customer event. Creating such customer event, CRM.COM will validate whether the purchased items are eligible to be awarded by a reward offer and credit the customer's wallet balance Submitting a purchase event in CRM.COM should be performed using the POST customer_events/purchases/create method, and capture the following information Products should already exist in CRM.COM in order for the POS to make transactions for them. In the event that a POS integration requires to perform transactions for such items, CRM.COM provides the ability to allow such transaction submission using a default product (everything is handled by CRM.COM without additional changes from the POS system) Once the sales transaction submission is performed (purchase customer event creation), the POS system can proceed to the spend step The following information can be displayed on the POS screen After Customer is Awarded Customer may want to spend some of the available wallet amount Spending a specific or the full awarded amount can be achieved by submitting a spend customer event in CRM.COM The following information can be displayed on the POS spend request form Submitting a spend request in CRM.COM should be performed using the POST customer_events/spend_requests/create method, and capture the following information Spend Request Form Once the spend request is performed, it will return back the actual amount that was spent, which might be different than the amount that was requested to be spend The following information will be used in the next step of reducing and closing the sales transactions After Spend Request Once the sales transaction (purchase customer event) and spend transaction (spend request customer event) are submitted successfully , the POS system can calculate the total spend amount, reduce it from the total amount of the sales transactions, and close the sales transaction with the customer's payment The total spend amount is calculated as the sum of the following attributes The total_spend_amount is also the sum of total_instant_spend_amount, total_additional_spend_amount and total_automatic_spend_amount as retrieved by the "purchases/create" (all these three values are retrieved from the same method as well) The calculated total spend amount is deducted from the POS sales transaction by applying a discount on the sales transaction Upon completion, the following information is displayed and printed on the customer's receipt Not Applicable Receipt The customer is identified on the POS system by providing an email address, a phone number, a card number, etc and list all previous purchases Retrieving such information from CRM.COM should be performed using the POST customer_events/purchases/list method The following identification means can be used to identify a customer in CRM.COM and retrieve all his purchases Not Applicable Once a customer is identified in CRM.COM, then the full information of the customer's purchases is returned back to the POS system The following information for each purchase can be displayed on the POS screen Not Applicable POS Conceptual Examples Cancelling a customer's purchase will result into amending the award and spend amounts that were related to that purchase Performing such action should be executed using the POST customer_events/purchases/cancel method and provided the related purchase that should be cancelled The following information should be passed to CRM.COM Not Applicable Once the purchase is cancelled, CRM.COM will return all related information to that transaction The following information can be displayed on the POS screen The flow described below is an example of synchronizing products from a POS system into CRM.COM Product Synchronization can be achieved using existing CRM.COM Web API methods, where product information (as described previously) can be passed through a product parameter set The maximum number of products that can be synchronized per call is 1,000 Product synchronization on a POS system can be implemented as a batch process that is performed on a repeated basis (i.e. every day at 2 am), where product information is sent to CRM.COM Submitting a product synchronization request in CRM.COM should be performed using the POST products/synchronise method, and capture the following information The maximum number of products that can be synchronized per call is 1,000 Once the product synchronization request is submitted and upon completion processing from the CRM.COM, the following information is returned (and handled accordingly by the POS system)Setup and Integration
Configuration
Authentication
Using Fields Set
Using Pagination
Integration Scenarios
Award and Spend Flow
Step 1 - Customer Identification
No Description Web API Example POS Conceptual Examples 1 https://hostname/crmapi/rest/v2/rewards_participants/show
2 Step 2 - Preview Award and Spend Information (Optional)
No Description Web API Example 1 https://hostname/crmapi/rest/v2/customer_events/purchases/preview
2 Step 3 - Submitting Sales Transaction and Award Customer
No Description Web API Example POS Conceptual Example 1 https://hostname/crmapi/rest/v2/customer_events/purchases/create
Not Applicable 2 Step 4 - Spend Awarded Amount
No Description Web API Example POS Conceptual Example 1 https://hostname/crmapi/rest/v2/customer_events/spend_requests/create
2 Step 5 - Closing the sales transaction
No Description Web API Example POS Conceptual Example 1 Amend Award and Spend Flow
Step 1 - Customer Identification
No Description Web API Example POS Conceptual Examples 1 https://hostname/crmapi/rest/v2/customer_events/purchases/list
2 Step 2 - Amend Award and Spend
No Description Web API Example 1 https://hostname/crmapi/rest/v2/customer_events/purchases/cancel
2 Product Synchronization Flow
Step 1 - Synchronize Products
No Description Web API Example POS Conceptual Examples 1 https://hostname/crmapi/rest/v2/products/synchronise
Not Applicable 2 Not Applicable
Additional Documentation
Visit CRM.COM Manual in order to find more information related to the areas / concepts mentioned in above scenarios
Module | Description | Manuals' Link |
---|---|---|
Rewards Participant | Manage the customers who have signed up for Rewards or have been automatically selected to participate | Managing Rewards Participants |
Rewards Offers | Reward Offers are used to
| Managing Rewards Offers |
Purchase Customer Events | Events linked with the purchase of goods | Purchase Customer Event |
Spend Request Customer Events | Events linked with the spending of awarded amount | Spend Request Customer Event |
Access Tokens | Access Tokens are used to identify and authenticate customers | Managing Access Tokens |
Products | Products are goods that used by business transactions in the System | Managing Products |