Create customers & load event register loadCustomerEvents

API. Create customers & load event register loadCustomerEvents
The command allows:
- creating a customer with certain characteristics
- transmitting a list of events with specific characteristics
Request:


{
    "events":[
        {
            "customerId":"5C5720C6-3BF9-49E1-927C-1E85EFF4D870",
            "customerEvent":"birhdate",
            "bankEvent":"registration",
            "customerType1":"debitCardHolder",
            "customerType2":"depositHolder",
            "customerType3":"creditHolder",
            "customerType4":"male",
            "customerType5":"goldSupport",
            "eventId":"123456",
            "eventDate":"2015-01-01T00:00:00+03",
            "eventType":"operation",
            "operationType":"purchase",
            "operationAmount":100.0000,
            "operationCurrencyRate": 1,
            "merchantId":123456,
            "terminalId":123456,
        },
        ......
   ],
   "typeOfCommand":"loadCustomerEvents"
 }

Request parameters:

events;Array[Event];yes;Array of events. customerId;String;yes;A unique identifier for the customer. The identifier can be a phone number, an email address or an arbitrary format string. If a phone number is transmitted as a login, it must start with + and a country code. customerEvent;String;no;Characterisation of an event is an event in the life of a customer. Random value. bankEvent;String;no;The characteristic of an event is a bank event. Random value. customerType1;String;no;The characteristic of the event is customer type. A random value defined by the user classification in your accounting system. customerType2;String;no;The characteristic of the event is customer type. A random value defined by the user classification in your accounting system. customerType3;String;no;The characteristic of the event is customer type. A random value defined by the user classification in your accounting system. customerType4;String;no;The characteristic of the event is customer type. A random value defined by the user classification in your accounting system. customerType5;String;no;The characteristic of the event is customer type. A random value defined by the user classification in your accounting system. eventId;String;yes;A unique identifier for the event. The identifier can be a randomly formatted string. eventDate;String;yes;The date of the event in ISO 8601 format. In case the string does not contain timezone information, the time is considered in UTC+0 format. eventType;String;yes;The event type is "operation" or "event". Operation - a trade operation. Event - all other events. operationType;String;yes, for operation;The "operation" event subtype is "purchase" or "reverse" or "return". operationAmount;Decimal;yes, for operation;Characteristic of "operation" event type is amount of trade operation. operationCurrencyRate;Decimal;yes, for operation;The currency exchange rate of the "operation" event relative to Roubles. If the amount transmitted is denominated in roubles, 1 is transmitted, otherwise, the rate by which operationAmount should be multiplied to get roubles is transmitted. merchantId;Int;yes, for operation;The identifier of the merchant where the "operation" event was created. terminalId;Int;yes, for operation;The identifier of the terminal where the "operation" event was created.

Response:


Success:
  
{
   "errors":[ ],
   "status":"Success",
   "error":null
}
  
Failure to execute the command as a whole:
{
   "status":"Failure",
   "error":{
      "typeOfError":"notAllowed",
      "description":"You cannot send a new command until the previous command has been processed"
   }
}
 
Failure when an error occurs in the transmitted commands:
{
   "errors":[
      {
         "eventId":"636554297092801053",
         "typeOfError":"wrongParam",
         "description":"Unknown customer type"
      }
   ],
   "status":"Failure",
   "error":{
      "typeOfError":"wrongData",
      "description":"Number of errors - 1"
   }
}

Response parameters:

Object Error:

Features of operation and use

1.Request processing procedure and the order in which the answers are generated

The command works in asynchronous mode. At the first stage, at the moment of command invoking, primary data validation is performed, which guarantees correct format of the transmitted information. The real enrollment and control of the command conformity with the application business logic (for example, absence of duplicated identifiers) is performed by the background process.
1.1. Step 1
1.1.1 Check if the format of the transferred command is correct.
1.1.2 Presence of required transmitted values - events, customerId, eventId, eventDate, eventType, operationType, operationAmount, operationCurrencyRate, merchantId, terminalId.
1.1.3 Initialisation of rule-related directories - terminalId, merchantId, customerEvent, bankEvent, customerType1, customerType2, customerType3, customerType4, customerType5.
1.1.4 Check that the previous command of this type has finished processing
1.1.5 The response of the result of step No1 is returned immediately
1.2. Step 2
1.2.1. Check if the eventId parameter is unique.
1.2.2 Generation of bonus accruals for events, to which the existing rules apply.
1.2.3. Bonus payments for events not complying with clause 2.1-2.2. are not calculated.
1.2.4 The result of step 2 is not returned as the procedure can take a long time. It is possible to get information about the results of event processing by using the getEventOperation command

2.Algorithm of response processing

2.2. A new loadCustomerEvents command must be sent 1 second after receiving a positive response to a previous command of this type and should not be sent in case of a negative response.

Back