An integrator that wishes to further ease the Digiteal registration process can use an API provided by Digiteal to pre-register a company. This API enables the integrator to send all the information required to perform a complete KYC of the company in Digiteal. The following information is mandatory: vat number, company name, company creation date, email of the contact person. The details of the data to send is described in the CompanyCustomerKYCInfo. The integrator is invited to complete as much information as he can using the following methods:

• Pre-register the company that takes a CompanyCustomerKYCInfo as JSON payload
• Send the various documents that takes a multipart/form-data payload to receive documents of type: ID (front and back of the identity document of the contact person), SELFIE_WITH_ID (picture of the contact person with the front of her ID document), BY_LAWS (latest by laws of the company describing the persons that can represent it)

After this information has been provided, the contact person will receive an email inviting her to activate their account. Three reminders will be sent to invite the user to activate his account. The contact person will be able to choose a password and complete her KYC process. Every information missing will be asked during the KYC process. Every information provided will be available after the KYC process to allow the user to review it.

Company national identifiers

The official scheme id spec from ISO is ISO 6523 but we reused the Peppol version which is a simplified version. A Company identification number is composed of two main parts: SCHEME_ID and NUMBER. The representation is done by separating the SCHEME_ID and NUMBER by a column (':'): 'SCHEME_ID:NUMBER'.

The SCHEME_ID is the type of identifier used (can be broken down into country code and type). Available SCHEME_IDs are:

• 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

The NUMBER is the actual number, unique only by SCHEME_ID (and following the syntactic rules of the SCHEME_ID).

An integrator that wishes to further ease the Digiteal registration process can use an API provided by Digiteal to pre-register a person. This API enables the integrator to send all the information required to perform a complete KYC of the person in Digiteal. Only the email address is mandatory in order to pre-register a person. The details of the data to send is described in the PersonCustomerKYCInfo. The integrator is invited to complete as much information as he can using the following methods:

• Pre-register the person that takes a PersonCustomerKYCInfo as JSON payload
• Send the various documents that takes a multipart/form-data payload to receive documents of type: ID (front and back of the identity document of the person), SELFIE_WITH_ID (picture of the person with the front of her ID document)

After this information has been provided, the person will receive an email inviting her to activate their account. Three reminders will be sent to invite the user to activate his account. The person will be able to choose a password and complete her KYC process. Every information missing will be asked during the KYC process. Every information provided will be available after the KYC process to allow the user to review it.

An company or an integrator can transfer the management of their mandates to Digiteal with the SDD Transfer API. This API enables the integrator to send all the information required to perform a complete KYC of a person or a company in Digiteal including the transfer of the mandate. The SEPA Direct Debit (SDD) mandate will be transformed into an automatic payment to give more control to the customer on the withdrawals he will accept. The integrator is invited to complete as much information as he can to further ease the onboarding process of the customer. After this information has been provided, the person/company will receive an email inviting her to activate their account. Three reminders will be sent to invite the user to activate his account. The person/company will be able to choose a password and complete her KYC process. Every information missing will be asked during the KYC process. Every information provided will be available after the KYC process to allow the user to review it.

To speed up the process, you can collect the customer consent. In order to collect a valid consent, the following conditions need to be fulfilled:

• The following text (legal mention) needs to be presented to the customer:
  • en: By signing this mandate form, you authorise (A) {NAME OF MERCHANT} to send instructions to your bank to debit your account and (B) your bank to debit your account in accordance with the instructions from {NAME OF MERCHANT}. As part of your rights, you are entitled to a refund from your bank under the terms and conditions of your agreement with your bank. A refund must be claimed within 8 weeks starting from the date on which your account was debited. Please complete all the fields marked.
  • fr: En signant ce formulaire de mandat, vous autorisez (A) {NOM DU CREANCIER} à envoyer des instructions à votre banque pour débiter votre compte, et (B) votre banque à débiter votre compte conformément aux instructions de {NOM DU CREANCIER}. Vous bénéficiez d’un droit à remboursement par votre banque selon les conditions décrites dans la convention que vous avez passée avec elle. Toute demande de remboursement doit être présentée dans les 8 semaines suivant la date de débit de votre compte.
  • nl: Door ondertekening van dit formulier geeft u toestemming aan (A) {NAAM VAN INCASSANT} om doorlopende incasso-opdrachten te sturen naar uw bank om een bedrag van uw rekening af te schrijven en (B) aan uw bank om doorlopend een bedrag van uw rekening af te schrijven overeenkomstig de opdracht van {NAAM VAN INCASSANT}. Als u het niet eens bent met deze afschrijving kunt u deze laten terugboeken. Neem hiervoor binnen 8 weken na afschrijving contact opmet uw bank. Vraag uw bank naar de voorwaarden.
• You need to collect the date of the consent, the IP address and the user agent of the browser of the customer.

All this information will then be provided in the call to the perform the SDD transfer.

It is also possible to transfer mandates silently with no required customer interaction with Digiteal. Digiteal can authorize SDD withdrawals of maximum 200€/month per debtor with a simplified KYC/KYB process. The 200€/month is a maximum that can be granted after a careful review of Digiteal's risk department. The risk is evaluated based on the activity of the company requesting it and the associated risks. This is not a global possibility and it is granted case-per-case. There are two ways to enable this. Both require that this mandatory data be provided: first name, last name, postal address, email address (+ company name and company identification number for companies) and that the maximum amount is under or equal to the limit assigned to your company. Then, you should also provide one of the following

• birth date, birth place and consent confirmation
• signed mandate document (type = BANK_MANDATE)

When these conditions are met, you will receive a confirmation that the mandate has been activated through the AUTOPAY_CONFIGURATION_CREATED webhook. To enable this, please send an email to compliance@digiteal.eu so that the risk department can evaluate if this service can be granted to your company.

As an AIS integrator, when you wish to pre-register a customer to retrieve his bank statements, here is the proposed flow:

• The AIS integrator makes a call to Digiteal to pre-register the customers. He adds a return URL to this call. The more information you can provide the better at this step. Everything that you will provide will not need to be asked to the customer during Digiteal's KYC/KYB process. For a simple access to the bank statements, minimal information is require (first name, last name, date of birth and email address for a person, VAT number, company name and email address for a company).
• Digiteal sends an email to the customer with a link to choose their password. The email says that they are invited to Digiteal by the company mentionned in the Customer Info section of the pre-registration call.
• The AIS integrator makes a call to 01Financials to request access to the customer's bank account. They also provide a return URL to 01Financials.
• 01Financials checks that the customers are known in Digiteal (they are since we got the pre-registration call) and they return a URL to redirect the customer to this page to link their bank accounts.
• The customer clicks on the link in the Digiteal email, chooses his password.
• The customer is redirected to Digiteal if the integrator did not provide a redirect link and to the redirect link if it was provided. In this case, the redirection is to the integrators website that redirects to the 01Financials installation page.
• The customer links his accounts in 01Financials to the installation provided by the integrator.
• The customer chooses to return to the integrator and the return URL provided to 01Financials is used.
• The customer is back in the integrator portal/app and he can continue his flow with the linked bank accounts.

In order to create an invoice, Digiteal needs to receive information about

• An issuer (you)
• A bank account
• A customer
• Other invoice details

A invoice can have 2 statuses :

• DRAFT
• PUBLISHED

When not specified the default value is PUBLISHED which allows no updates.

The platform provides the possibility to introduce an invoice with a DRAFT status which can be updated later on. Users will not be notified for these invoices.

This service is used to attach a document (PDF, XML, RTF,...) to an invoice or a credit note. For example, this document can be a bill but it can also be some energy usage summary or the details of a telephone bill.

This documents should only be attached if the customer choose to receive his invoice/credit note in Digiteal (aka he did an optin). You know that he did an optin by checking if deliveryMethod = S2P in the header of the response to the creation of the invoice / credit note.

Multiple documents can be attached to one invoice/credit note. A document cannot be sent if it is not related to an existing invoice / credit note. Only the emitter of an invoice and his integrator can attach documents to it.

There are two services to send a document. The first one uses the UUID of the invoice/credit note as returned when the invoice / credit note was sent and the second one relies on the issuer's internal identifier.

This service is used to send a credit note linked to an invoice. For example, this credit note can be for 20 € out of a 100€ invoice.

This service is used to force an optin to Digiteal for a specific customer. The necessary parameters are:

• the VAT number of the company issuing the invoices
• the customer internal identifier
• the email address of the customer

The documentation for PEPPOL has been moved here.

Invoices API details provides an overview of the provided e-invoicing services and gives a detailed description of the input and output parameters.

The Digiteal platform not only allows the end user (your clients) to pay their invoices, it also allows you to integrate the interactive payment solution with your own software. Our platform provides 2 parts necessary to create and complete an interactive payment flow.

• a service to create a payment request hosted and implemented by Digiteal
• an api interface to receive payment notifications hosted and implemented by you

Besides the interactive payment (user input necessary to finalize the payment) our platform allows the end users to configure automatic payments (payments executed automatically upon receiving an invoice). In this documentation, this functionality is described as the autopayment service.

You can try it out using Digiteal's interactive payment demo application. This demo is linked to Digiteal's test environment so no actual payments will take place there.

This service will be called by the Digiteal platform to notify the requester that we received a confirmation to execute a payment request. The unique payment id generated during the payment request creation will be provided as input. This allows the requester’s system to link the corresponding payment request on his side. If the service of the requester is unreachable the digiteal platform will retry later on.

To generate a QR code anonymously, you can do it manually through the QR generator and you can use this base URL to generate them dynamically: https://app.digiteal.eu/api/v1/image-request/slip-image-anonymous (example: https://app.digiteal.eu/api/v1/image-request/slip-image-anonymous?iban=BE72000000001616&billerName=Red%20Cross%20of%20Belgium&amount=1&remittanceInfo=Urgency%20fund&format=qr&language=en). This method is great to showcase but the QR code that is generated can only be used by the mobile banking apps of bank that support the EPC QR code

To enable the payment by QR code for customers from whatever bank in the EU, you can use Digiteal's registered QR code generator. It will still generate a standard EPC QR code but it will also enable the payment from whatever bank in the EU through Digiteal. Here is the procedure to use Digiteal's registered QR code generator (must be done by someone having the signature right of Belfius or through a delegation of power):

• Create your company account on https://app.digiteal.eu
• Go through the KYC and pick a "Start" account (cost: 65€) if you do it on your own or a "Go" account (cost: 365€) if you want support.
• Add the various bank accounts on which you will want to collect
• Generate the QR code as described here above with the QR generator
• (optional) if you want, you can also add a payment button so that they can directly pay without going through the QR, for example if they only have a desktop or if they are reaching your donation page on their mobile phone. See the pay button documentation (even easier to integrate through two lines of HTML that you can use on you website but also in an SMS or an email)

The QR generator can interpret the parameters to be prefilled. Here are the various parameters you can use:

• creditorName: The name of the creditor
• bic: The BIC of the creditor bank account.
• iban: The IBAN of the creditor bank account.
• amount: The amount of the payment. If not provided or set to 0, the customer will be requested to fill in the amount. This can be used for donations to charity for example.
• creditorReference: The structured reference used to match the payment. This is also called the structured communication in Belgium. Both BBA (Belgium) and ISO (International) types are supported. It can be left empty if the remittanceInfo is defined.
• remittanceInfo: An unstructured code that is used as communication in the payment. This information is only used if there is no creditorReference. It can be left empty if the creditorReference is defined.
• email: The email of the person generating the QR code.
• purpose: The purpose 4 letter code based on the ISO 20022 standard.
• purposeName: The purpose name based on the ISO 20022 standard.
• info: The information that should be displayed by the bank based on the EPC guidelines (more info: http://goo.gl/S7LTri). The default value is https://www.scan2pay.info.
• dueDate: The date before which the payment must be performed. The payment slip will display this date as memo-date. The expected format is YYYY-MM-DD.
• language: The language in which to display the payment slip. The supported values are en, fr, nl, de. The default value is 'en'.
• format: Format of the image you want to receive. The supported values are QR, QR_BE, QR_NL, QR_TEXT, QR_URL, PAYMENT_SLIP, PAYMENT_SLIP_WITH_BANNER, BANNER, BANNER2, BANNER3, BANNER4, BANNER5, BANNER6 and NONE. The default value is QR.
• paymentInternalId: Your payment identifier that will be provided back to you when Digiteal will notify you through a webhook that this payment has been initiated.

Here are some sample renderings from the QR generator with the default resolution (minimum width is 250px):

• Payment slip (1622 x 770) :
  
• QR (800 x 800):
  
• QR_BE for a company not registered in Digiteal (800 x 600) :
  
• QR_BE for a company registered in Digiteal (800 x 600) :
  
• QR_NL for a company not registered in Digiteal (800 x 600) :
  
• QR_NL for a company registered in Digiteal (800 x 600) :
  
• QR_URL (600 x 600) :
  
• QR_TEXT:

  BCD
001
1
SCT
BPOTBEB1
Red Cross
BE72000000001616
EUR1
CHAR

Urgency fund
Sample EPC QR Code

• BANNER (1622 x 446):
  
• BANNER2 - text can be modified based on A/B testing to improve conversion, the QR code is an EPC QR code (1622 x 446):
  
• BANNER3 - text can be modified based on A/B testing to improve conversion, the QR code contains the payment URL (1622 x 446):
  
• BANNER4 - once the payment solution presented in Banner3 is not new anymore, the QR code contains the payment URL (1622 x 446):
  
• BANNER5 - small version of the banner including the Digiteal logo, the QR code contains the payment URL (541 x 301):
  
• BANNER6 - small version of the banner without the Digiteal logo, the QR code contains the payment URL (541 x 301):
  
• PAYMENT_SLIP_WITH_BANNER (1622 x 770):
  

https://app.digiteal.eu/#/qr-generator?creditorName=Les%20amis%20de%20Demoucelle%20Parkinson%20Charity&bic=BPOTBEB1&iban=BE10000000000404&amount=12.34&creditorReference=014134000443&email=support@digiteal.eu&purpose=CHAR&purposeName=Charity&info=https:%2F%2Fwww.scan2pay.info&dueDate=2030-12-31&language=en&format=PAYMENT_SLIP_WITH_BANNER