# Settings

The settings used in all integration modes are detailed below.

The settings specific to the integration by plugin are detailed there.

The settings specific to the integration by redirection are detailed there.

# Required settings per Payment type

Name	Payment type	Type	Details
`amountCents`	all	`integer`	Purchase amount in cents
`merchantUid` or `companyUid`	all	`string`	Your merchant (1 single payment solution) or company id (1 to N payment solution(s)).
`email`	all	`string`	Email of the client
`firstName`	all except SPLIT	`string`	First name of the client. Some controls on length, restricted words, etc... may apply
`lastName`	all except SPLIT	`string`	Last name of the client. Some controls on length, restricted words, etc... may apply
`reference`	all	`string`	Unique reference of the purchase in the system of the merchant (note: if the merchant calls the solution with a given reference and if the purchase is successfully completed, the merchant cannot call the solution with the same reference anymore)
`title`	all	`string`	Title of the purchase

# B2B settings

The following settings have to be used for b2b transactions.

Name	Type	Details
`b2bCompanyName`	`string`	Required - Client company name (FR: raison sociale de l'entreprise acheteur)
`b2bCompanyNationalId`	`string`	Required - Unique ID in the French company registry (.i.e: SIREN or SIRET code)
`b2bCompanyNationalIdType`	`string`	Optional - Type of ID used (SIREN (default), or SIRET)

# Contractual settings

The settings below can be required or optional, depending on the configuration of the merchant defined contractually.

Name	Type	Details	Scoring
`metadata`	`Object`	Merchant-specific data (typically, a tour operator may set `{"departure_date": "2019-02-01"}` in this field)	Used
`phoneNumber`	`string`	Customer phone number (E164)	Used
`address`	`{street: string, city: string, stateProvince: string, zipcode: string, country: string}`	Customer billing address The country must be an ISO 3166-1 alpha-2 code If the street is split on several lines (e.g. "line1" and "line2"), it is recommended to join them in a single string with a comma (i.e. "line1, line2")	Used
`birthDate`	`string`	Customer birth date (`YYYY-MM-DD`)	Used
`birthCity`	`string`	Customer birth city	Used
`birthCountry`	`string`	Customer birth country (ISO 3166-1 alpha-2 code)	Used
`birthZipcode`	`string`	Customer birth zip code, required only if `birthCountry` is FR	Used

# Optional settings

Name	Type	Details	Scoring
`subtitle`	`string`	Subtitle of the purchase (use `\\|` as line separator)	Not Used
`currency`	`string`	Currency of the amount (EUR by default - only EUR and GBP are supported)	Not Used
`language`	`string`	Language to be used (de_DE, en_GB, es_ES, fr_FR, it_IT, nl_NL and pt_PT only - fr_FR by default)	Not Used
`paymentNotificationUrl`	`string`	Merchant URL (https://www.example.com) or email address (mailto:[email protected]) to call at the payment end	Not Used
`errorNotificationUrl`	`string`	Merchant URL (https://www.example.com) to call when the purchase fails after the payment screen	Not Used
`countryCode`	`string`	Can be used to override merchant `Country code` settings for a purchase	Not Used
`balancePaymentDate`	`string`	Date of payment of the balance (`YYYY-MM-DD`). Only for DOWN_PAYMENT payments. The latest possible date of balance payment is always today + the delay in days specified in the configuration. If `balancePaymentDate` is set, it is the balance payment date, and it must be before the latest possible one. If `balancePaymentDate` is not set, the balance payment date is the latest possible one.	Not Used
`deferredPaymentDate`	`string`	Date of deferred payment (`YYYY-MM-DD`). Only for DEFERRED payments. The latest possible date of deferred payment is always today + the delay in days specified in the configuration. If `deferredPaymentDate` is set, it is the deferred payment date, and it must be before the latest possible one. If `deferredPaymentDate` is not set, the deferred payment date is the latest possible one.	Not Used
`secondInstallmentPaymentDate`	`string`	Date of the second installment (`YYYY-MM-DD`). Only for INSTALLMENT payments with 5 or more installments. Delays the second installment at the specified date. All the following shares will start from `secondInstallmentPaymentDate` and be monthly separated. See details below.	Not Used
`signature`	`string`	Signature of all the parameters except, of course, the signature itself (see Signature).	Not Used
`showCloseButton`	`boolean`	Indicates whether the red cross on the upper right corner should be displayed (true by default).	Not Used
`civility`	`string`	Customer civility (`Mr` or `Ms`)	Used
`birthLastName`	`string`	Customer birth last name	Not Used
`nationality`	`string`	Customer nationality	Not Used
`shippingAddress`	`{street: string, city: string, stateProvince: string, zipcode: string, country: string}`	Customer shipping address The country must be an ISO 3166-1 alpha-2 code If the street is split on several lines (e.g. "line1" and "line2"), it is recommended to join them in a single string with a comma (i.e. "line1, line2")	Used

# Signed only settings

Name	Type	Details	Scoring
`paymentMethodId`	`string`	A psp identifier for the client payment method. Add this parameter to the signature only without sending it in the body	Not Used

If secondInstallmentPaymentDate is lower than payment created date we do not consider secondInstallmentPaymentDate value.

For regulation purpose, the funding duration cannot exceed 12 months. Thus, if secondInstallmentPaymentDate is too far from created date, we aggregate the exceeding installments into one (see example below).

Examples:

A 5 installments payment of 500€ created on 2020-01-01 with no secondInstallmentPaymentDate:
- 1st share: 100€, due the 2020-01-01
- 2nd share: 100€, due the 2020-02-01
- 3rd share: 100€, due the 2020-03-01
- 4th share: 100€, due the 2020-04-01
- 5th share: 100€, due the 2020-05-01
A 5 installments payment of 500€ created on 2020-01-01 with secondInstallmentPaymentDate = "2020-05-15":
- 1st share: 100€, due the 2020-01-01
- 2nd share: 100€, due the 2020-05-15
- 3rd share: 100€, due the 2020-06-15
- 4th share: 100€, due the 2020-07-15
- 5th share: 100€, due the 2020-08-15
A 5 installments payment of 500€ created on 2020-01-01 with secondInstallmentPaymentDate = "2020-11-15":
- 1st share: 100€, due the 2020-01-01
- 2nd share: 100€, due the 2020-11-15
- 3rd share: 300€, due the 2020-12-15

# Metadata

In addition to the parameters described in the previous section, the field metadata contains a JSON with:

scoring data about the session
scoring data about the account
vertical-specific scoring data

The names of the fields are in lower case and in underscore case.

The fields with a name ending with _date represent a date, expressed as specified in ISO 8601 (opens new window) (i.e. with the format YYYY-MM-DD).

The fields with a name ending with country represent a country, expressed as Alpha-2 code as specified in ISO 3166-1 (opens new window) (i.e. FR for France).

For marketplaces, please fill in the reseller_data section(s) where appropriate.

The scoring data has the following structure:

# Scoring data about the session:

The possible values for the field session.channel are the following: desktop, mobile, call_center, point_of_sale.

{
    "session": {
        "duration_seconds": 4612,
        "channel":  "desktop"
    }
}

# Scoring data about the account:

{
    "account": {
        "creation_date": "2019-06-13",
        "number_of_purchases": 14,
        "loyalty_card_number": "XYZ64"
    }
}

# Vertical-specific scoring data:

Travel merchants : The possible values for the field travellers.document.type are the following: passport, visa, identity, driver_licence.

The fields with a name ending with _airport are IATA airport codes (opens new window). These fields also support IATA railway station codes (opens new window).

Example 1 : Paris -> Milano then Milano -> Paris (Return Flight)

{
    "travel": {
        "number_of_travellers": 3,
        "departure_date": "2019-06-14",
        "departure_city": "Paris",
        "departure_airport": "CDG",
        "departure_country": "FR",
        "return_date": "2019-06-30",
        "destination_city": "Milano",
        "destination_airport": "MXP",
        "destination_country": "IT",
        "buy_date": "2019-05-10",
        "insurance": true,
        "reseller_data": {
           .../...
           <please refer to `reseller_data` in _Service & Ticketing merchants_ section below>
           .../...
           }
    },
    "travellers": [{
            "id": "xxx1",
            "buyer": true,
            "birth_date": "1980-01-21",
            "document": {
                "type": "passport",
                "validity_date": "2020-02-18",
                "country": "FR"
            }
        },
        {
            "id": "xxx2",
            "buyer": false,
            "birth_date": "1982-03-17",
            "document": {
                "type": "passport",
                "validity_date": "2021-10-18",
                "country": "ES"
            }
        },
        {
            "id": "xxx3",
            "buyer": false,
            "birth_date": "2019-03-15"
        }
    ]
}

Example 2 : Paris -> Milano (One Way Flight)

{
    "travel": {
        "number_of_travellers": 3,
        "departure_date": "2019-06-14",
        "departure_city": "Paris",
        "departure_airport": "CDG",
        "departure_country": "FR",
        "return_date": "none",
        "destination_city": "Milano",
        "destination_airport": "MXP",
        "destination_country": "IT",
        "buy_date": "2019-05-10",
        "insurance": true,
        "reseller_data": {
           .../...
           <please refer to `reseller_data` in _Service & Ticketing merchants_ section below>
           .../...
           }
    },
}

Accommodation merchants : merchant_data value is any merchant-specific data in JSON format.

{
    "stay": {
        "reference": "Edenarc",
        "duration_days": 7,
        "name": "2 single beds - standard category",
        "amount_cents": 99700,
        "merchant_data": {
            "category": "apparthotel"
        },
        "insurance": true,
        "arrival_date": "2019-06-14",
        "departure_date": "2019-06-14",
        "country": "FR",
        "location": "Les Arcs",
        "number_of_adults": 2,
        "number_of_children": 2,
        "reseller_data": {
           .../...
           <please refer to `reseller_data` in _Service & Ticketing merchants_ section below>
           .../...
           }
    }
}

Retail merchants : The possible values for the field delivery_mode are the following: home, relay, clickAndCollect.

The field delivery_mode_reference is linked to delivery_mode. Please follow these recommendations:
- if delivery_mode = home : express, standard, appointment, etc...
- if delivery_mode = relay : Mondial relay, La Poste, etc...
- if delivery_mode = clickAndCollect : 2h, 3h, etc...
The type of the delivery_delay field is integer and represents the delay in days between the order and the estimated time of receipt by the customer.

The possible values for the field type are the following: physical, virtual.

The possible values for the field category are the following:
- 1 : Food & Gastronomy
- 2 : Auto & Moto
- 3 : Culture & Entertainment
- 4 : Home & Garden
- 5 : Home appliance
- 6 : Auctions and Group Purchases
- 7 : Flowers & Gifts
- 8 : Computers & Software
- 9 : Health beauty
- 10 : Particular services
- 11 : Professional services
- 12 : Sport
- 13 : Clothing & Accessories
- 14 : Travel & Tourism
- 15 : HiFi, Photo & Videos
- 16 : Telephony & Communication
- 17 : Jewelry & Precious Metals
- 18 : Baby items and accessories
- 19 : Sound & Light
```
{
    "products": [{
        "reference": "5025155081754",
        "type": "physical",
        "quantity": 1,
        "name": "Vacuum cleaner Dyson V15 Detect Absolute",
        "unit_amount_cents": 59900,
        "category": 5,
        "sub_categories": ["electronic home & comfort", "vacuum cleaner", "broom vacuum cleaner", "cordless stick vacuum cleaner", "..."],
        "brand": "Dyson",
        "size": "126cm",
        "color": "purple",
        "stock": false,
        "delivery_mode": "home",
        "delivery_mode_reference" : "standard",
        "delivery_delay": 84,
        "reseller_data": {
           .../...
           <please refer to `reseller_data` in _Service & Ticketing merchants_ section below>
           .../...
           },
    }]
}
```

Service & Ticketing merchants:

{
    "event": [
       {
       "description": "String",
       "category": "String", (e.g: concert, match, theater)
       "sub_category": "String", (e.g: rock, tennis ...)
       "ticket_nb": 4, (number of participants, type integer) 
       "ticket_class": "String", (e.g: VIP / 1 / 2 ...)
       "reference": "String",
       "beginning_date": "2022-06-18",
       "duration_days": 3, (event duration, type integer)
       "reseller_data": {
          "name": "String",
          "national_id": "123456789",
          "national_id_type": "SIREN", (Must be part of the supported types of national ids, e.g: SIREN for France)
          "country_code": "FR", (The country code of the company: UK, FR, BE, CH, .../...)
          "email": "[email protected]",
          "phone": "+33612345678",
          "address": "3 rue Saint-Lazare 75009 Paris"
          }
       }
       ]
}

# Signature of the parameters

The settings can be signed through an additional setting called signature which contains a JSON Web Token (JWT).

This token is generated with a secret shared between Pledg and the merchant. The merchant uses this secret on its backend to generate the token, and Pledg uses the same secret to decode it.

The merchant can also specify a validity period when generating the token.

The payload of the token is a JSON containing all the settings normally passed to the solution, except:

The parameter signature itself
The callbacks (in integration by plugin)
The parameter containerElement (if any, in integration by plugin)

The code below illustrates how to generate the JWT on the backend of the merchant. More precisely, the JWT is based on the data sent by the frontend, computed on the backend and returned to the frontend.

app.post('/generate-signature', function (req, res) {
    data = req.body
    var jwt = require('jsonwebtoken');
    var signature = jwt.sign(
        {
            data:data,
        },
        process.env.SECRET,
        { expiresIn: '1d' }
    );
    res.send(JSON.stringify(signature))
});

In this particular example:

It is written in JavaScript, but it could be any other backend language (Python, PHP, Java, etc.)

The library jsonwebtoken used here to generate the signature must be installed on the backend. It can be found there (opens new window) with the instructions to install it.
req is the request sent by the frontend, which body contains the parameters of the purchase (amounCents, title, etc.)
res is the response sent back to the frontend, which body contains the JWT.
The frontend is then supposed to call the URL of the backend related to the code above, retrieve the JWT from the response and set it in the field signature..

Finally the response of this request is a JSON web token so when your frontend will call '/generate-signature' it will get as a response "signature" which has to be injected in the field "signature" of the plugin.

Many technical resources related to JWT (documentation, validation tools, etc.) are available on https://jwt.io.

Environments →