• API. Create customers & load event register loadCustomerEventsExt
    The command allows:
    • creating a customer with certain characteristics
    • transmitting a list of events with specific characteristics, including the name of the merchant where the "operation" type event was created
    • transmitting a description of the event type

    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,
            "merchantName":"TSUM",
        },
        ......
   ],
   "typeOfCommand":"loadCustomerEventsExt"
 }

Request parameters:
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.