How to Signups

In order to carry out the subscription registration process, it will be necessary to build a JSON that must have certain elements depending on the type of registration we want to give (new numbering / portability, Online / Offline, residential / business, etc) …

The different sections that will need to be reported in the sale process are detailed below:

Type of sale and associated information

One of the fundamental values ​​that must be informed in the sale process is the type to which it is related. Currently, by default, the value " telecommunications" must be reported , but the idea is that this field can accommodate another type of sale:
'sales_type' : "telecomunications",

On the other hand, within the “sales_info” object, all the information to which the sale is to be associated will be collected, which is directly related to the channel and associated logistics:

Client data

Customer data is a vitally important section in the registration process, as it will serve to define its structure at different hierarchical levels.

• Customer data, represented in the "client" object
• Data of the holder of the shipment, represented in the object "send"
• Data of the contract holder, is collected under the object "account", which is the natural container of the subscription (s)

It is necessary to pay special attention to the "type" field, since it will define the level to which the information collected below will be associated, in the request itself. This is:

Example of body, where differentiated data is incorporated for the holder "client" and sending "send":

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

{
  "sales_type": "telecomunications",
  "sales_info": {
    "dealer_id": "string",
    "logistic": true
  },
  "clients": {
    "sector_id": 1,
    "attributes": [
      {
        "type": "client",
        "name": "Nombre",
        "middlename": "Apellido",
        "lastname": "Apellido2",
        "document_type_id": 1,
        "document_value": "60881137E",
        "email": "email@email.es",
        "birthdate": "2020-03-03",
        "nationality_id": 63,
        "contact_phone": "666777666",
        "gender": "F",
        "language_id": 90,
        "address": {
          "street_name": "ALcala",
          "number": "202",
          "state_id": 28,
          "locality": "Madrid",
          "postal_code": "28028",
          "country": "Madrid"
        }
      },
      {
        "type": "send",
        "name": "Nombre 2",
        "middlename": "Apellido1",
        "lastname": "Apellido2",
        "document_type_id": 1,
        "document_value": "01221608D",
        "email": "mail@mail.es",
        "birthdate": "1998-04-12",
        "nationality_id": 63,
        "contact_phone": "666666777",
        "gender": "F",
        "language_id": 90,
        "address": {
          "street_name": "Alcala",
          "number": "202",
          "state_id": 28,
          "locality": "Madrid",
          "postal_code": "28028",
          "country": "Madrid"
        }
      },  

Master data

In the registration process, MasterData will be used, in order to extract certain information that generally does not undergo modifications and that it is necessary to inform in the process itself. For example, information on the different types of documents, nationalities, language associated with the client, etc. This service will be accessible from the URL:

Payment information

The payment data allowed in the MasCustomers API are differentiated into Prepaid and Postpaid. These values ​​are collected within the field:

"billing_type_id": Where (2=Prepaid; 1=Postpaid)

Below is an example of a body for a prepaid registration . In the vast majority of cases, in addition to the "billing_type_id" , the data returned by the POS will be needed to collect shipping costs, rate value and / or vouchers purchased during registration.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

  {
  "payment": {
        "billing_type_id": 2,
        "tpv_response": {
            "amount": "2000",
            "order": "UNjiNJiwSIp",
            "merchant_code": "223252065",
            "currency": "978",
            "transaction_type": "1",
            "merchant_url": "",
            "authorisation_code": "227861",
            "merchant_identifier": "",
            "card_number": "454881******0004",
            "signature": "YCspgyKVDRF1G_JUiJ72XBStf3L5FkyvozwyfYe-eKA=",
            "expiry_date": "1234",
            "confirm_transaction": 0
        }
    }
  }

In the case of post-paid sales , the client must go through a prior scoring process, where a value will be obtained that will be decisive to continue with the sale process. This information must be included within the “scoring” object. The bank details will also be included, which will later be used to charge the invoices that are generated in each customer’s billing cycle.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

  {
    "payment": {
        "billing_type_id": 1,
        "scoring": {
            "id_value": 1,
            "scoring_value": 71,
            "up_front": 1,
            "forced_value": 0
        },
        "info": {
            "bank_account": "11111111301111111111"
        }
    }
  }
    

Signups products (mobile)

The signups of products will be included within the object "products" . The products that can be contracted will be included in the commercial catalog and may be included in the different categories established within the catalog itself. Currently, the MasCustomers API covers the sale of mobile ( "type": "mobile" )

The sale of a mobile type product can have two clearly different origins, these are renumbering and portability. In addition, both requests must be constructed differently, considering whether the registration is Online or Offline. Below are examples of bodysuits for each of them:

Signup with portability - Online

In those cases, in which the origin of the sale is portability, the body must contain the object "portability_info" , within this, all the necessary information associated with portability will be included, as shown in the example below The MasCustomers API allows for future portability to be programmed, to do so, use the "scheduled_date" field where the date on which the portability is to be made effective will be indicated.

On the other hand, there is the possibility of configuring the sending of commercial communications to the client, using the "wants_communications" field . In the event that the client does not want to receive commercial information, this field will contain the value "false"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

{
  "products": {
    "mobile_lines": [
      {
        "type": "mobile",
        "product_id": 234,
        "portability_info": {
          "scheduled_date": "2021-04-22",
          "iccid": "8934040000000000002",
          "operator_id": "0",
          "operation_type": 1,
          "initial_date_operation": "2021-03-10",
          "donor_line_type": "C"
        },
        "msisdn": "string",
        "fabrication_type_sim_id": 1,
        "wants_communications": false 
      }

Signup without portability - Online

Selling a renumbering line, you will need to provide the associated number (msisdn). This can be extracted from the service /orgs/{orgId}/signups/available-msisdns/{host_cfg}: which will provide a list of MSISDNs available for sale.

On the other hand, there is the possibility of configuring the sending of commercial communications to the client, using the "wants_communications" field . In the event that the client does not want to receive commercial information, this field will contain the value "false"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "products": {
    "mobile_lines": [
      {
        "type": "mobile",
        "product_id": 34,
        "msisdn": "666555444",
        "fabrication_type_sim_id": 1,
        "wants_communications": false
    }
  

Signup with portability - Offline

In the case of face-to-face sales (offline), it will be necessary to provide the ICCID information associated with the MSISDN in the interface, so that the sales process can follow its natural process. This field determines the international identifier of the card and is associated with the dealer who makes the sale.

On the other hand, there is the possibility of configuring the sending of commercial communications to the client, using the "wants_communications" field . In the event that the client does not want to receive commercial information, this field will contain the value "false"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

  {
    "products": {
    "mobile_lines": [
      {
        "type": "mobile",
        "product_id": 0,
        "portability_info": {
          "scheduled_date": "2021-04-22",
          "iccid": "8934040000000000002",
          "operator_id": "0",
          "operation_type": 1,
          "initial_date_operation": "2021-03-10",
          "donor_line_type": "C"
        },
        "msisdn": "733444555",
        "iccid": "8934046660005430002"
        "fabrication_type_sim_id": 1,
        "wants_communications": false
     }

Signup without portability - Offline

In the case of face-to-face sales (offline), it will be necessary to provide the ICCID information associated with the MSISDN in the interface, so that the sales process can follow its natural process. This field determines the international identifier of the card and is associated with the dealer who makes the sale.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
"products": {
    "mobile_lines": [
      {
        "type": "mobile",
        "product_id": 0,
        "msisdn": "string",
        "iccid": "8934040000000000002"
        "fabrication_type_sim_id": 1,
        "wants_communications": false
    } 

Signup with portability - Data of another donor holder

There are scenarios, where we want to make a sale with portability, where the data of the donor holder is different from the ones we want to provide in the new registration process. In this case, it will be necessary to fill in the information of the donor_user object , as shown in the following example body:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

  {
      "products": {
    "mobile_line": {
      "type": "mobile",
      "product_id": 45,
      "msisdn": "763333444",
      "iccid": "8934046660005430002",
      "fabrication_type_sim_id": 1,
      "wants_communications": false,
      "portability_info": {
        "scheduled_date": "2021-04-04",
        "iccid": "89340400000000002",
        "operator_id": "1",
        "donor_line_type": "C",
        "operation_type": 1,
        "initial_date_operation": "2021-03-03",
        "donor_user": {
          "type": "client",
          "company_name": "INTEL",
          "document_type_id": 5,
          "document_value": "F18153106",
          "language_id": 90,
          "nationality_id": 63,
          "contact_phone": "788777666",
          "email": "mail@mail.com",
          "address": {
            "street_name": "alcala",
            "state_id": 23,
            "locality": "Madrid",
            "postal_code": "28028",
            "country": "Madrid"
          }
        }
      }
    },
  }

Signup with additional bonuses, promotions and campaigns

In the registration process itself, it is possible to include other associated products, such as bonuses, promotions and campaigns. These must be defined in the commercial catalog and in the case of promotions, they must be accompanied by the name of the promotion, reported in the "value" field , as shown in the following example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

  {
    "bonuses": [
      {
        "id": 45
      }
    ],
    "promotions": [
      {
        "id": 123,
        "value": "PROMO AMIGO"
      },
      {
        "id": 345
      }
    ]
  }