Skip to main content

Introduction

Introduction to Affiliation​

The Affiliations service allows the onboarding process for one or more products to be associated with an (external) party that introduces prospect clients to Fabrick for the purpose of subscribing to new products. Affiliation is based on the issuance of an Affiliation Code to the affiliator (e.g. MYCODE123), who can use a dedicated API to obtain the redirect URLs where prospect clients will find the dedicated onboarding process. The Affiliations service supports integration with the Carts and Offers services for managing cart models in which it is possible to pre-populate:

  • the set of products to be pre-added to the cart (with optional constraints on selectability and possible dependencies).
  • the set of economic conditions applicable to the pre-added products (optionally including selectable alternatives at the customer's discretion).

Each affiliator can have multiple Affiliation Codes to support different cart pre-selection scenarios and/or related pricing offers.

The features of the Affiliation service can be complemented with the Personification service to allow personification grants to be issued to the affiliating party directly within the onboarding process.

Use Case​

The Affiliation service underpins scenarios where an external party promotes Fabrick products/services to its own customer base. For example, an online management platform for SMEs may integrate Fabrick Pass Pay by Bank Collection features into its platform, allowing its customers to collect invoice payments by initiating payment directly from the debtor's account. In this scenario, the management platform requests a redirect link from Fabrick to direct its customers to, where they will find an onboarding process pre-populated with the Pass Pay by Bank Collection product and its associated pricing conditions. In this case, the Affiliation service is combined with the Personification service so that the management company is granted the usage grant on behalf of the end customer.

The FPP that develops the product is called the affiliator (TTPP or Technical Party), while all other FPPs that use the service are called affiliates (or Grantors).

Returning to the previous example with the Pass Pay by Bank product, the advantage is that each FPP will be able to offer Pass payments products to its own customers and activate them in a completely autonomous manner. Furthermore, for end customers this will be completely transparent from a technical standpoint — no integration or development is required on their part.

Below is a simple illustrative diagram:

affiliation_simple_schema

The affiliator FPP's apiKey is enabled only to make calls for managing the affiliation process, while the affiliates' apiKeys will be enabled to make calls for the contracted products, such as Pass Pay by Bank and/or Pass AIS & PIS Services for Corporates.

The diagram above is intended only to convey the general idea of the flow. In practice, the affiliates' apiKeys are not visible. Indeed, the affiliate will not see any apiKey within their user portal (except, of course, for other products outside of the affiliation product).

The affiliator will be able to create, via API, a token to simulate the behaviour of each of the affiliates' apiKeys. The generated tokens have a limited duration; further details will be provided later.

Naturally, the TTPP could optionally initiate an affiliation process for itself in order to also use the Pass payments products.

Contractual Obligation​

The contract between Fabrick and the technical intermediary (the so-called affiliator) requires the latter to display the following disclaimer on its platform:

Fabrick S.p.A. is a payment institution authorised by the Bank of Italy to operate as an Account Information Service Provider ("AISP") and Payment Initiation Service Provider ("PISP") pursuant to Directive 2015/2366/(EU) on payment services in the internal market, as subsequently implemented under national law, registered in the Register of Payment Institutions with effect from 16 March 2020 under code 36780.5. Redirection to the Fabrick website does not give rise to any obligation on the part of potential Customers to enter into a contract for Fabrick Services.

It is therefore required that the affiliate share with Fabrick the specifics of the method adopted to display the aforementioned disclaimer, attaching a screenshot.

Affiliation Process: Overview​

The TTPP will need to integrate the APIs described in this document.

The process can be divided into 3 phases:

  • Subscription

  • Grant verification (optional)

  • Personification request

Subscription​

In this phase, the TTPP will invite its customer to complete an onboarding phase in order to become a grantor.

The onboarding phase consists of an online form in which the end customer must enter information about their company and its owner (or a delegate). All steps in detail are described in the document Affiliation: Guide for Grantors.

Grant Verification​

Once the onboarding phase is complete, the TTPP will need to verify that it has been successfully and correctly completed. In particular, it will also need to verify that the customer has enabled the appropriate permissions (grants) for the TTPP in order to proceed with the next and final phase.

This step is currently optional as permissions are automatically included during the subscription phase.

Personification​

The Personification service enables the personification functionality between platform users. Through a granting mechanism, this function allows a technical user to use other services or products on behalf of the Consumer who has subscribed to them.

The Personification service is fundamental in building multi-tenant products, enabling the ability to impersonate the subscribing customer when using other platform modules. For example, if a product requires access to the Pass Pay by Bank APIs, the Personification service allows the product to consume those APIs without necessarily holding the customer's APIKey; by using an appropriate grant issued during the subscription phase, the product can dynamically obtain a personification token at runtime that allows it to effectively "be" the customer and securely consume the Pass Pay by Bank APIs.

After verifying that the appropriate permissions are in place, the TTPP will be able to make personification requests — that is, it will be able to use, for example, the PISP services while impersonating one of its own customers (grantors).

This is the phase in which the TTPP, via API, will obtain a token to use as an apiKey when invoking the contracted product's APIs. The token is naturally tied to a single, specific grantor, meaning that from Fabrick's perspective, the HTTP requests appear to originate directly from the grantor.

Example​

Suppose a customer has just completed the onboarding phase for the Pass Pay by Bank product, has therefore completed the subscription part, and has enabled the appropriate grants. At this point, the TTPP will be able to request a personification token associated with this grantor.

If the TTPP then calls POST SearchCreditors (standard Pass Pay by Bank product) with the above-mentioned token in the header, it will receive in response the grantor's credit account or accounts.

If at a later time the TTPP calls POST SearchCreditors with a new token generated via API for a different grantor in the header, it will receive in response that grantor's credit account or accounts.

It will therefore not be possible to retrieve the credit accounts of all grantors via a single call.