Mandate transfer

KYC

After having obtained the user consent, you can add this information during the transfer process. You are able, if desired, to have a silent mandate transfer with a simplified KYC process (light KYC). Meaning: no mandatory manual interaction with Digiteal required. However this will cap the maximum withdrawal limit to 200€/month. We grant you this ability after careful review of your activities and the risks associated with them.

Mandatory information for the simplified KYC includes:

A signed mandate document
Persons
- first name + last name
- physical address
- email address
Companies
- first name + last name
- physical address
- email address
- company name
- company identification number

Also note that the maximum withdraw amount should also match (read: equal or less) the limit assigned to your company by Digiteal.

SDD transfer

Transfer a SDD mandate for a person

Transfer person

Here you can find an example of the request body in JSON we would use for the light KYC flow:

{
  "complete": false,
  "configuration": {
    "currency": "EUR",
    "executionType": "DUE_DATE",
    "periodicity": "MONTH",
    "thresholdInCents": 20000
  },
  "contractApproval": {
    "approvalDate": "2022-05-02",
    "ipAddress": "string",
    "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 Safari/537.36 OPR/85.0.4341.72"
  },
  "creditorVatNumber": "BE0000000001",
  "customerInternalId": "MyCustomer1",
  "debtor": {
    "address": {
      "city": "Gembloux",
      "country": "Belgium",
      "countryCode": "BE",
      "houseNumber": "C",
      "streetName": "Rue du moulin",
      "zipCode": "29650"
    },
    "birthDay": "1999-11-27",
    "birthPlace": "Gembloux",
    "email": "[email protected]",
    "firstName": "Salem",
    "gender": "MALE",
    "language": "FR",
    "lastName": "BEN",
    "ibans": [
      "BE26817697538429"
    ]
  },
  "debtorIBAN": "BE26817697538429",
  "notificationSettings": {
    "autoPayment": true,
    "autoPaymentThreshold": true,
    "invoice": false,
    "issuer": false,
    "mail": false,
    "paymentIssue": false,
    "push": false,
    "reminder": false
  }
}

Important to know:

customerInternalId is a unique identifier the integrator can choose refer to a client. This will be useful f.e. for the SDD payments later on.
According to the chosen KYC flow:
- Light KYC: set { complete: false } in the request body
- Complete KYC: set { complete: true} in the request body
The debtorIBAN field must also be present in the ibans array
For the configuration object: setting the executionType to DUE_DATE will give you the most flexibility regarding payment collection (see: the SDD Payment section)

Transfer a SDD mandate for a company

Transfer company

Here you can find an example of the request body in JSON we would use for the complete KYC flow:

{
  "complete": true,
  "contractApproval": {
    "approvalDate": "2019-11-30",
    "ipAddress": "ipsum",
    "userAgent": "Mozilla/5.0 (Linux; Android 7.0; SM-G892A Build/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Mobile Safari/537.36"
  },
  "configuration": {
    "currency": "EUR",
    "executionType": "DUE_DATE",
    "periodicity": "MONTH",
    "thresholdInCents": 20000
  },
  "creationDate": "YYYY-MM-DD",
  "custumerInternalId": "MyCustomer1",
  "creditorVatNumber": "BE0000000097",
  "debtor": {
    "address": {
      "city": "Bruxelles",
      "countryCode": "BE",
      "houseNumber": "tempor esse elit",
      "streetName": "Rue de la Loi",
      "zipCode": "veniam quis nisi eu",
      "country": "Belgique"
    },
    "companyName": "Your COmpany",
    "contact": {
      "address": {
        "city": "Bruxelles",
        "countryCode": "BE",
        "houseNumber": "dolore aliqua",
        "streetName": "Rue de la Loi",
        "zipCode": "et adipisicing Lorem id",
        "country": "Belgique"
      },
      "email": "[email protected]",
      "birthDay": "1990-12-31",
      "birthPlace": "Cook, NZ",
      "firstName": "John",
      "gender": "MALE",
      "idDocumentValidityEnd": "2030-12-31",
      "language": "EN",
      "lastName": "Doe",
      "nationalities": [
        "BE"
      ],
      "pep": true,
      "pepCustomerExplanation": "Prime minister of New Zeland",
      "sectors": [
        {
          "type": "STUDIES",
          "details": "Part-time"
        },
        {
          "type": "STUDIES",
          "details": "Part-time"
        }
      ]
    },
    "identificationNumber": "BE:VAT:BE0000010097",
    "creationDate": "2012-12-31",
    "ibans": [
      "BE74735471499507"
    ],
    "settlementGrouping": "PER_MONTH",
    "integratorIdentificationNumber": "BE:VAT:BE0000000001",
    "ubos": [
      {
        "birthDay": "1990-12-31",
        "birthPlace": "Cook, NZ",
        "firstName": "John",
        "gender": "MALE",
        "lastName": "Doe",
        "pep": true,
        "pepCustomerExplanation": "Prime minister of New Zeland"
      }
    ]
  },
  "notificationSettings": {
    "autoPayment": false,
    "autoPaymentThreshold": false,
    "invoice": false,
    "issuer": false,
    "mail": false,
    "paymentIssue": false,
    "push": false,
    "reminder": false
  },
  "product": "PAYMENT",
  "returnURL": "https://www.myportal.com/digitealRegistrationConfirmed",
  "welcomeMessage": "YourTelecom invites you to use Digiteal to pay all your invoices in one click."
}

Important to know:

customerInternalId is a unique identifier the integrator can choose refer to a client. This will be useful f.e. for the SDD payments later on.
the fields identificationNumber and integratorIdentificationNumber are identifiers that uniquely identify the company and that we generate according to a standard ruleset:

The official scheme specification id is ISO 6523, be we use a simplified version introduced by PEPPOL. A company identification number is composed of two main parts: SCHEME_ID and NUMBER. The representation is done by separating these two parts using a colon: SCHEME_ID:NUMBER. The NUMBER is of course the actual value, unique by the SCHEME_ID. Here's the list of the supported SCHEME_ID's:

SCHEME_ID	Comment
AD:VAT
AL:VAT
AT:FN	Business Register Number (Firmenbuchnummer, FN), see official documentation. The NUMBER format is "[0-9]{1,6}[A-Za-z][0-9]{0,3}".
AT:VAT
AT:VAT
BA:VAT
BE:CBE
BE:EURN	Belgian Establishment Unit Registration Number. The NUMBER format is "[2-9][0-9]{9}."
BE:FASEI	School location based on the FASE "implantation" number of the French community. The NUMBER format is composed of the CBE/EURN number followed by 'F' and then the FASE implantation number ("[0-9]{10}F[0-9]+")
BE:VAT
BG:VAT
BY:VAT
CA:BN
CA:VAT
CH:VAT
CS	CreditSafe identifier. The NUMBER format is "^[A-Z]{2}-[X\d]-[A-Z0-9]{6,15}$".
CY:DRCOR	Αριθμός Εγγραφής στο Τμήμα Εφόρου Εταιρειών και Επίσημου Παραλήπτη (Registration number given by the Department of Registrar of Companies and Official Receiver)), see official documentation. The NUMBER format is "[COP][0-9]{0,8}".
CY:VAT
CZ:ICO	Czech registration ID (ex: CZ:ICO:12345678). The NUMBER format is "[0-9]{8}".
CZ:VAT
DE:HRA	HRA register for companies (ex: DE:HRA:12345-Hannover). The NUMBER format is "[0-9]{1,12}(-[0-9a-zA-Z]{0,30}(-[0-9]{2})?)".
DE:HRB	HRB register for companies (ex: DE:HRA:5678-Bonn). The NUMBER format is "[0-9]{1,12}(-[0-9a-zA-Z]{0,30}(-[0-9]{2})?)".
DE:VR	VR register for associations (ex: DE:VR:1234-Munchen). The NUMBER format is "[0-9]{1,12}(-[0-9a-zA-Z]{0,30})".
DE:VAT
DK:CVR	CVR-nummer, see official registry. The NUMBER format is "[0-9]{8}".
DK:VAT
EE:REG	Estonian company registration number (see registry). The NUMBER format is "[0-9]{8}".
EE:VAT
EL:VAT
ES:NIF	Fiscal Identification Number (see description, ex: A28015865). The NUMBER format is "[A-Z0-9]{9}".
ES:VAT
FI:OVT	Finland Business ID (ex: FI:OVT:12345678). The NUMBER format is "[0-9]{8}".
FI:VAT
FR:NIRA	Numéro d'Inscription au Registre des Associations: french association in Moselle, Bas-Rhin and Haut-Rhin. The NUMBER format is "[0-9]+V[0-9]+F[0-9]+".
FR:OCCE	Numéro de coopérative scolaire de l'OCCE: the number is composed of the french SIRET of the OCCE of the deparment followed by an "N" and then the cooperative number in that OCCE department. The NUMBER format is "[0-9]{14}N[0-9]+".
FR:RNA	French association. The NUMBER format is "W[0-9]{9}".
FR:SIREN	French company. The NUMBER format is "[0-9]{9}".
FR:SIRET	French establishment. The NUMBER format is "[0-9]{14}".
FR:VAT
GB:CRN
GB:VAT
GLN	See Global Location Number
GD:VAT
GR:VAT
HA:VAT
HR:MBS	Matični broj subjekta trgovačkog suda (MBS), see official registry. The NUMBER format is "[0-1][0-9]{8}".
HR:VAT
HU:CEG	Cégjegyzékszám (CEG), see official registry. The NUMBER format is "[0-9]{2}(-)[0-9]{2}(-)[0-9]{6}".
HU:VAT
IE:CRO	Companies Registration Office (CRO) number, see official registry. The NUMBER format is "[1-9][0-9]{1,6}".
IE:VAT
IT:FTI	Tax code number (ex: IT:FTI:12345678901). The NUMBER format is "[0-9]{11}".
IT:VAT
IL:EDI
LEI	Legal Entity Identifier (see registry)
LI:VAT
LT:LEC	Organization identifier number in Lithuania (ex: LT:LEC:123456789). The NUMBER format is "[0-9]{9}".
LT:VAT
LU:RCS	Trade and Companies Register number (ex: LU:RCS:B123456). The NUMBER format is "[A-Z][0-9]{1,12}".
LU:VAT
LV:REG	Legal entity identifier in Latvia (ex: LV:REG:12345678901). The NUMBER format is "[0-9]{11}".
LV:VAT
MC:VAT
ME:VAT
MK:VAT
MT:VAT
NL:KVK	KVK number (ex: NL:KVK:12345678). The NUMBER format is "[0-9]{8}".
NL:VAT
NO:ORG	Numerical identifier in the Norwegian Register for Legal Entities (ex: NO:ORG:123456789). The NUMBER format is "[0-9]{9}".
NO:VAT
PH:VAT
PL:KRS	National Court registry identifier in Poland (ex: PL:KRS:1234567890). The NUMBER format is "[0-9]+".
PL:REGON	REGON registry identifier in Poland (ex: PL:REGON:123456789 or PL:REGON:12345678901234). The NUMBER format is "[0-9]{9}\|[0-9]{14}".
PL:VAT
PT:VAT
SI:TIN	Slovenian company tax identification number (see registry). The NUMBER format is "[1-9][0-9]{7}".
SI:VAT
SE:ORGNR	Swedish Organization Number (ex: SE:ORGNR:1234567890). The NUMBER format is "[0-9]{10}".
SE:VAT
SK:VAT
SM:VAT
RO:VAT
RS:VAT
TR:VAT
VA:VAT

According to the chosen KYC flow:
- Light KYC: set { complete: false } in the request body
- Complete KYC: set { complete: true} in the request body
The debtorIBAN field must also be present in the ibans array
For the configuration object, setting the executionType to DUE_DATE will give you the most flexibility regarding payment collection (see: the SDD Payment section)

Upload the signed mandate document

Upload KYC document

Here’s an example of the JSON request body:

Content-Type: "multipart/form-data"

{
    "email": "[email protected]",
    "name": "Example Corp.",
    "requesterVAT": "BE0000001",
    "type": "BANK_MANDATE",
    "file": _FORMDATA_
}