Panel | ||
---|---|---|
| ||
|
...
Drawio | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Product Synchronization can be achieved using CRM.COM Web API methods that a POS system can call periodically in order to synchronize products information that exists in the POS with the ones in CRM.COM, resulting into creating new products or update existing ones. Prior product synchronization, the merchant that owns the POS system should map correctly the POS product information with the CRM.COM product information (a suggested mapping was described previously, where we presented the various product attributes)
Drawio viewerToolbar true border true fitWindow false diagramName product_sync width 600 simpleViewer false revision 1
Before you begin
Prior jumping into proceeding to the actual integration implementation, let's walk through a few basic API concepts that will be required on each subsequently method
...
Step 1 - Customer Identification | |||||||||||||||||||
No | Description | Web API Example | POS Conceptual Examples | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | The customer is identified on the POS system by providing an identification mean. Such identification can be 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 | ||||||||||||||||
2 | Once a customer is identified in CRM.COM, then the full information of the customer is returned
The following information can be displayed on the POS screen
|
| After Customer Identification | ||||||||||||||||
Step 2 - Preview Award and Spend Information (Optional) | |||||||||||||||||||
No | Description | Web API Example | POS Conceptual Examples | ||||||||||||||||
1 | 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. In addition, the preview method will determine whether the purchase customer event that will be submitted can be redeemed 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 | ||||||||||||||||
2 | Once a customer is identified in CRM.COM, then the full information of the customer is returned
The following information can be displayed on the POS screen
|
| After Preview
| ||||||||||||||||
Step 3 - Submitting Sales Transaction for Awarding Customer | |||||||||||||||||||
No | Description | Web API Example | POS Conceptual Example | ||||||||||||||||
1 | 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
|
| Not Applicable | ||||||||||||||||
2 | Once the sales transaction submission is performed (purchase customer event creation), the POS system can proceed to the redemption step
The following information can be displayed on the POS screen
|
| After Customer is Awarded | ||||||||||||||||
Step 4 -RedeemRedeeming Awarded Amount | |||||||||||||||||||
No | Description | Web API Example | POS Conceptual Example | ||||||||||||||||
1 | Customer may want to spend some of the available wallet amount on the previously created transaction, 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 | ||||||||||||||||
2 | 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 | ||||||||||||||||
Step 5 - Closing the sales transaction | |||||||||||||||||||
No | Description | Web API Example | POS Conceptual Example | ||||||||||||||||
1 | Once the sales transaction (purchase customer event) and spend transaction (spend request customer event) are submitted successfully , then the POS system can calculate the redemption amount, reduce it from the total amount of the sales transactions, and close the sales transaction with the customer's payment
The redemption amount is calculated as the sum of the following attributes
The calculated redemption 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 |
Product Synchronization Flow
The flow described below is an example of synchronizing products from a POS in 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 parameterNote that there is a
Note |
---|
The maximum number of products that can be synchronized per call |
...
is |
...
1,000 |
Additional Documentation
...
Step 1 - Synchronize Products | |||||||||||||||||||
No | Description | Web API Example | POS Conceptual Examples | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Product synchronization on a POS system can 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
|
| Not Applicable | ||||||||||||||||
2 | 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)
|
| Not Applicable |
Additional Documentation
Visit CRM.COM Manual in order to find more information related to the areas / concepts mentioned in above scenarios
...
Rewards Participating Merchants are merchants that have a partnership with the business that owns the Rewards platform and can participate in the provided Reward Schemes
Reward Participating Merchants contribute to the amount awarded to Rewards Participants, based on rules which are agreed and defined between the Merchant and the business
The Reduction Method that will be used to process the sales it is defined through the Participating Merchant
...
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 |
...