Freelancer credit cards

Introduction

With Solaris credit cards for freelancers, you can offer credit cards to freelancers and their employees in an easy and automated onboarding flow. To onboard a freelancer on our credit card solution, the freelancer must go through the standard onboarding flow, including customer identification (KYC) and other steps related to the credit card setup.

In this guide, you will find all the onboarding requirements you need to integrate into your solution to offer this product to freelancers.

Available branches

This product is currently only offered to freelancers in Germany.

How does it work?

Using Solaris credit cards, your freelancers can offer their employees credit cards. The freelancer will be the account's owner, whereas employees, who will be issued a credit card, will be cardholders who only have access to the funds on their credit cards as allocated to them by the freelancer.

Freelancers can apply for a credit card through your solution by doing the following:

  • Fulfill all legal and compliance requirements.
  • Submit the required data points and documents.
  • Pass the credit scoring process.
  • Complete the customer identification flow (KYC).
  • Onboard their employees who will be issued a credit card.

Additionally, you can offer the customer the option to choose between charge and revolving credit cards. Read more about the difference between charge and revolving cards here.

note
  • This page covers the specific integration steps for freelancer credit cards. See the credit cards overview page for a general overview of how Solaris credit cards work.
  • For sole proprietors, use the Business credit cards onboarding guide.

System prerequisites

Before starting the onboarding process, implement the following requirements:

1. Technical setup:

Set up your environment and get your authentication keys. For step-by-step instructions, check the Technical setup guide.

2. Legal and compliance screens:

Build the necessary legal and compliance screens in your sign-up flow to collect your customers' consent to the necessary legal and compliance requirements. The Legal and compliance screens guide contains step-by-step instructions on how to create these screens and what they must contain.

The following screens are required to onboard B2C and freelancer customers for Digital Banking & Cards:

  1. Terms and Conditions
  2. Customer information
  3. Economic interest
  4. Person tax information (Only for customers in Germany)
  5. FATCA indication
  6. Self-declaration as a politically exposed person (PEP). (Only for customers in France, Italy, and Spain)
  7. Compliance screen

Record the customer's consent on each screen as a UTC timestamp (e.g., 2019-01-01T00:00:00Z). Afterward, you must pass each timestamp in its respective field to Solaris.

  • Collect the customer's consent to Solaris's Terms and Conditions and store the timestamp in the terms_conditions_signed_at field.
  • Collect the customer's consent to data processing and store the timestamp in the data_terms_signed_at field.
  • Collect the customer's economic interest declaration and store the timestamp in the own_economic_interest_signed_at field.
  • Collect the customer's FATCA indication and store it in the fatca_relevant field. Store the timestamp in the fatca_crs_confirmed_at field.
note

The mentioned fields are part of the person resource in which all the customer data points are stored.

B2B SDD mandate

You need to create an B2B SDD mandate and collect the customer's signature on it to allow Solaris to charge the freelancer's reference account for credit card repayments each month.

The SEPA Direct Debit (SDD) mandate is the customer's authorization for Solaris to collect funds from their account in the future.

During your sign-up, you need to collect the IBAN of the reference account from the the customer, and create a B2B SDD mandate and collect the customer's signature on it.

How to create the SDD mandate?

You must generate a unique SDD mandate number. The mandate_number must contain 35 characters and the first 6 must be a partner-specific string agreed upon by you and Solaris during the implementation phase. The remaining 29 may only contain the following: [A-Z], [a-z], [0-9].

Additionally, make sure to display the following information to the customer before they sign the mandate:

  • Full name (First_name + last_name)
  • IBAN
  • Generated mandate reference
  • Name of Payee: Solaris SE
  • Legal text containing authorization for the mandate

Integration overview

attention
  • This guide includes the onboarding requirements for both charge and revolving cards for freelancers in Germany.
  • The following integration uses IDnow video identification as the identification method. Other identification methods are also possible. Contact your Partner Manager for more information.

The following diagram gives a high-level overview of the integration process for freelancer credit cards. Click on each step to go to its dedicated section for full instructions:

Freelancer registration
Legal & compliance requirements
Legal & compliance requir...
Step 1:
Collect freelancer data
and create
person resource
Step 1:...
Step 2:
Create and verify

mobile number
Step 2:...
Step 3:
Create tax
identification
Step 3:...
Step 4.1:
Upload proof
of profession
Step 4.1:...
Step 4.2:
Upload B2B SDD
mandate
Step 4.2:...
Credit card application 
Step 5:
Create credit card
application
Step 5:...
Scoring
Scoring
Abort onboarding
Abort on...
DECLINED
DECLINED
PREAPPROVED
PREAPPROVED
Customer identification (KYC) & Due diligence (CDD)
Step 6.1:
Create & trigger
 freelancer identification (KYC)
Step 6.1:...
Step 6.2:
Verify CDD statuses
Step 6.2:...
KYC/
CDD
KYC/...
failed
failed
Abort onboarding
Abort on...
successful
successful
Credit card finalization & reference account
Step 7:
Finalize credit card application
Step 7:...
Step 8:
Create reference
account and set
credit limit
Step 8:...
Card creation & mandatory features
Step 10:
Create and activate
credit card
Step 10:...
Step 11:
Implement all
servicing endpoints
Step 11:...
Employees onboarding
Step 9.1:
Collect data and create
person r
esource for
each employee
Step 9.1:...
Step 9.2:
Create and verify
mobile number for
each employee
Step 9.2:...
Step 9.3:
Create & trigger
identification (KYC) for
each employee
Step 9.3:...
Text is not SVG - cannot display

You can integrate Solaris' freelancer credit card product by completing the 11 steps explained in the following sections. Here's an overview of these steps:

Category Step Description
Customer registration Step 1 Collect the mandatory data points and create a person resource for your customer.
Customer registration Step 2 Create and verify the customer's mobile number.
Customer registration Step 3 Collect the customer's tax information and create a tax identification resource.
Customer registration Step 4 Collect the customer's proof of profession and upload it along with the signed B2B SDD mandate.
Credit card application Step 5 Collect the required data and create a credit card application for the customer.
Once the application status reaches PRE_APPROVED, proceed with the following steps.
Customer identification Step 6.1 Create an identification resource for the freelancer and specify the identification method.
Redirect the freelancer and at least 6 other employees to complete the video identification process with IDnow.
Customer identification Step 6.2 Ensure that all persons pass the customer due diligence process before proceeding with the following steps.
Customer identification Step 6.3 Ensure that all persons pass the FATCA checks.
Credit card confirmation & reference account creation Step 7 Finalize the credit card application to trigger the account creation.
Credit card confirmation & reference account creation Step 8 Create a reference account for the customer and attach the credit limit to the credit card account.
Employee onboarding Step 9 9.1 For each employee who will be issued a credit card, collect the required data and create a person resource by completing step 9.1.
9.2 Collect and confirm the mobile number of each employee who will be issued a credit card as explained in Step 9.2.
9.3 Create and trigger the identification for each employee by completing step 9.3.
Card creation, activation & servicing Step 10 Create and activate the credit card for the customer.
Card creation, activation & servicing Step 11 Implement all endpoints related to servicing credit cards.

Sequence diagram

The following sequence diagram gives an overview of the integration flow:

note

To view a larger version of this diagram, right-click on the image and click "Open in a new tab."

Diagram: Freelancer credit cards flow

In the following sections, you can find descriptions of these steps and their related endpoints.

Webhooks

Solaris recommends subscribing to the following webhook events to better automate your processes. For detailed instructions on implementing Solaris webhooks, check the webhooks documentation.

Mandatory features

You must integrate all the mandatory features for Digital Banking & Cards highlighted in the Onboarding requirements guide before going live with your solution.


Step 1: Collect customer data and create person resource

In this step, you must collect the mandatory data points from the customer in your sign-up flow, including all the timestamps of the customer's consent to the legal and compliance screens.

Afterward, pass all the data points to Solaris by creating a person resource to represent your customer.

API reference

For a complete list of endpoints, properties, and examples related to the person resource, visit the following links:

Related webhook events

Important points about data collection
  • Please consider the special requirements for data collection highlighted in the onboarding requirements guide.
  • You must submit the information exactly as it appears in official documents.
  • When testing the process on Sandbox, please ensure that each person you create has unique values for first_name, last_name, birth_city, and birth_date. If you create over 1000 identical person resources, the API will return a 400 error.
  • Don't use any personal data when testing this endpoint on Sandbox.

POST Create person

This endpoint creates a person resource for a freelancer. Add the following mandatory data points in the request body of this endpoint:

Important

The customer must submit the information exactly as it appears in official documents.

Mandatory data points for freelancers in Germany

  • salutation: Note: MR for male, MS for female, null for gender-neutral.
  • first_name (including all middle names as printed on the ID document)
  • last_name (including all name parts as printed on the ID document)
  • address

  • contact_address (OPTIONAL To be used only if the customer's current address is younger than two years.)
  • mobile_number: Must be verified.
  • birth_date
  • birth_city
  • birth_country (ISO 3166-1 alpha-2 codes)
  • nationality (ISO 3166-1 alpha-2 codes)
  • employment_status (Should be either SELF-EMPLOYED or FREELANCER)
  • fatca_relevant
  • fatca_crs_confirmed_at (UTC timestamp)
  • terms_conditions_signed_at (UTC timestamp)
  • data_terms_signed_at (UTC timestamp)
  • own_economic_interest_signed_at (UTC timestamp)
  • tax_information

    • marital_status
  • iban: Only required for Bankident.
  • business_trading_name: The name of the freelancer's business.
  • Business Address The freelancer's business address (Street, Number, City, Postal Code, Country, State).
  • business_purpose
  • nace_code English.
  • website_social_media (if available)
  • expected_monthly_revenue_cents
  • vat_number: Mandatory for self-employed persons with an expected annual revenue of more than €17,500.

Request example

Copy
Copied
// POST /v1/persons
{
    "salutation": "MR",
    "first_name": "Peter",
    "last_name": "Mustermann",
    "nationality": "DE",
    "birth_date": "1972-12-14",
    "birth_city": "Berlin",
    "birth_country": "DE",
    "mobile_number": "+49301234567",
    "employment_status": "FREELANCER",
    "address": {
        "line_1": "Musterstraße 10",
        "line_2": "",
        "postal_code": "10409",
        "city": "Berlin",
        "country": "DE",
        "state": "BE"
    },
    "tax_information": {
        "marital_status": "MARRIED"
    },
    "business_trading_name": "My Business",
    "nace_code": "N 81.22",
    "business_purpose": "helping people to find themselves",
    "business_address_line_1": "StreetStrasse, 42",
    "business_address_line_2": "4th floor",
    "business_postal_code": "12345",
    "business_city": "Berlin",
    "business_country": "DE",
    "website_social_media": "http://social-network.com/my-company",
    "expected_monthly_revenue_cents": 20000,
    "vat_number": "DE999999999",
    "fatca_relevant": false,
    "fatca_crs_confirmed_at": "2017-01-01T00:00:00Z",
    "terms_conditions_signed_at": "2017-01-01T00:00:00Z",
    "data_terms_signed_at": "2017-01-01T00:00:00Z",
    "own_economic_interest_signed_at": "2017-01-01T00:00:00Z"
}

Response example

The API returns a person object with a unique id, which is the person_id. You will need this id to append the person resource with additional information in the remaining steps of this guide.

Copy
Copied
{
    "id": "6aeab6ab0146e0914edf335e6c1abce6cper",
    "salutation": "MR",
    "title": null,
    "first_name": "Peter",
    "last_name": "Mustermann",
    "address": {
        "line_1": "Musterstraße 10",
        "line_2": null,
        "postal_code": "10409",
        "city": "Berlin",
        "country": "DE",
        "state": "BE"
    },
   "email": null,
    "mobile_number": "+49301234567",
    "birth_name": null,
    "birth_date": "1972-12-14",
    "birth_city": "Berlin",
    "birth_country": "DE",
    "nationality": "DE",
    "employment_status": "FREELANCER",
    "job_title": null,
    "tax_information": {
        "tax_assessment": null,
        "marital_status": "MARRIED"
    },
    "fatca_relevant": false,
    "fatca_crs_confirmed_at": "2017-01-01T00:00:00.000Z",
    "business_purpose": "helping people to find themselves",
    "industry": "OTHER_PROPERTY_MANAGEMENT",
    "industry_key": "SERVICES_TO_BUILDINGS_AND_LANDSCAPE_ACTIVITIES",
    "terms_conditions_signed_at": "2017-01-01T00:00:00.000Z",
    "own_economic_interest_signed_at": "2017-01-01T00:00:00.000Z",
    "aml_follow_up_date": "2028-09-23",
    "aml_confirmed_on": "2022-03-23",
    "flagged_by_compliance": false,
    "expected_monthly_revenue_cents": 20000,
    "vat_number": "DE999999999",
    "website_social_media": "http://social-network.com/my-company",
    "business_trading_name": "My Business",
    "nace_code": "N 81.22",
    "business_address_line_1": "StreetStrasse, 42",
    "business_address_line_2": "4th floor",
    "business_postal_code": "12345",
    "business_city": "Berlin",
    "business_country": "DE",
    "screening_progress": "NOT_SCREENED",
    "risk_classification_status": "NOT_SCORED",
    "customer_vetting_status": "NOT_VETTED",
    "annual_income_range": null,
    "data_terms_signed_at": "2017-01-01T00:00:00Z",
    "branch": null,
    "birth_province": null,
    "birth_post_code": null,
    "socioprofessional_category": null,
    "purpose_of_account_opening": null,
    "main_income_source": null,
    "work_country": null,
    "work_province": null,
    "self_declared_as_pep": null,
    "international_operativity_expectation": [],
    "registration_number": null

}

Click here to view the full API reference

PATCH update person

This endpoint updates one or more properties on a person resource. You can only update the following properties using this endpoint:

  • title
  • salutation
  • address (line_1, line_2, postal_code, city, state, country)
  • contact_address (line_1, line_2, postal_code, city, state, country)
  • employment_status
  • job_title
  • email
  • tax_information (tax_assessment, marital_status)
  • fatca_relevant
  • fatca_crs_confirmed_at
  • business_purpose
  • industry
  • industry_key
  • own_economic_interest_signed_at
  • aml_confirmed_on (only with today or tomorrow's date)
  • expected_monthly_revenue_cents
  • vat_number
  • website_social_media
  • business_trading_name
  • nace_code
  • business_address_line_1
  • business_address_line_2
  • business_postal_code
  • business_city
  • business_country
  • annual_income_range
  • data_terms_signed_at
  • branch
  • birth_province
  • birth_post_code
  • socioprofessional_category
  • purpose_of_account_opening
  • main_income_source
  • work_country
  • work_province
  • self_declared_as_pep
  • international_operativity_expectation
  • registration_number
attention
  • Fields not mentioned in this list can only be updated via Customer Support.
  • Only for B2C customer: If a customer changes their employment_status to FREELANCER or SELF_EMPLOYED, please note that you must apply one of the following options to the same request to avoid getting an error:

    1. Collect the nace_code from the customer, or
    2. Set the fields industry and industry_key to null.
  • Solaris recommends collecting the nace_code from the customer for the sake of data quality.

Request URL

Copy
Copied
PATCH /v1/persons/{id}

Click here to view the full API reference


Step 2: Create and verify mobile number

In this step, collect the freelancer's mobile number in your sign-up flow and then create a mobile number resource and verify it by sending an SMS OTP to the customer's mobile number. Then, the customer enters the OTP in your frontend to verify their number.

Mobile number resource

Creating and verifying a mobile number for your customer is a crucial step in the customer onboarding process. With a verified mobile number, customers can use SMS OTPs to complete two-factor authentication (2FA) challenges, which is a requirement for Strong Customer Authentication (SCA).

info
  • In some use cases (e.g., stand-alone integrations, the mobile number is verified during the identification process).

API reference

Visit the following link to find all the endpoints related to the mobile number resource, including related properties and examples.

Related webhook events

Testing static values

To test the following endpoints on Sandbox, you can use the following static values:

  • Mobile number: +15550101
  • SMS OTP: 212212

POST Create mobile number

Collect the customer's mobile number and pass it to Solaris using the following API call, and include the customer's person_id in the request URL.

Request example:

Copy
Copied
POST /v1/persons/{person_id}/mobile_number
{
  "number": "+15550101"
}

Response example:

The API returns a mobile_number resource with a unique id and attaches it to the person resource.

Copy
Copied
{
    "id": "91e4d939d781b8eb30d1ee86809761c2cmno",
    "number": "+15550101",
    "verified": false
}

Click here to view the full API reference.

POST Authorize mobile number

Use the following endpoint to verify the ownership of the provided mobile phone number. The endpoint initiates a one-time-password (OTP) flow: Solaris sends a six-digit OTP to the customer's number, and then they must enter it in your UI.

Request example:

Copy
Copied
POST /v1/persons/{person_id}/mobile_number/authorize
{
  "number": "+15550101"
}

Response example:

Copy
Copied
{
    "id": "91e4d939d781b8eb30d1ee86809761c2cmno",
    "number": "+15550101",
    "verified": false
}

Click here to view the full API reference..

POST Confirm mobile number

Use this endpoint to submit the SMS OTP the customer received on their mobile number to finalize the mobile number authorization process. You must add the customer's number and token (i.e., the SMS OTP) in the request body. Afterward, the mobile number will be verified and can be used in the context of Strong Customer Authentication (SCA).

Request example:

Copy
Copied
POST /v1/persons/{person_id}/mobile_number/confirm
{
  "number": "+15550101",
  "token": "212212"
}

Response example:

Copy
Copied
{
    "id": "91e4d939d781b8eb30d1ee86809761c2cmno",
    "number": "+15550101",
    "verified": true
}

Click here to view the full API reference.

Mobile number management

For more information about how to manage mobile numbers, check the related guide.


Step 3: Create customer tax identification

In this step, collect the relevant tax information from the customer and create a tax identification resource for them.

API reference

Important points about tax information

Submitting the tax information of your customers is a requirement to open a bank account in all of Solaris branches. However, please note the following:

  • You can open the bank account for customers in Germany (DE branch) before they provide tax information. However, you must submit the customer's tax information to Solaris within 90 days of opening the account. Otherwise, Solaris will block the customer's account with the reason MISSING_TAX_INFORMATION until you submit the required tax information.
  • If a customer has multiple tax residencies (i.e., taxable in multiple countries), you must create a separate tax identification resource for each tax residency and specify only one of them as primary.
  • The first tax_identification to be submitted for a person or a business must be the primary tax identification. If another tax_identification with the value of primary set to true is created, it will set the primary value of the previously created tax_identification to false.
  • A person or business may only have one tax_identification per country.
  • When creating a tax_identification, explicitly collect the country value from the user and do not default to their physical residence (i.e., the country property of the person resource).
  • Check the Onboarding requirements guide for more information about the TIN requirements per country.

For a complete list of endpoints, properties, and examples related to the person tax identification resource, visit the following links:

Related webhook events

POST Create person tax identification

Call this endpoint to create a person tax identification for the customer with the person_id specified in the request URL. Collect the following tax information from your customers and pass them to Solaris in the request body:

  • number
  • country
  • primary

If the customer has not submitted their TIN to your solution yet (i.e., the value of number is null), then include the following properties in the request:

  • reason_no_tin: Possible values are NOT_ASSIGNED_YET, NOT_ASSIGNED_BY_COUNTRY, OTHER.
  • reason_description: Applies only if the reason_no_tin is OTHER.
  • tax_id_type: (Only for Spain) Possible values are NIE and NIF.

Request example:

Copy
Copied
POST /v1/persons/{person_id}/tax_identifications

Click here to view the full API reference.


Tax ID testing data

You can use the following test values for the TIN to test these endpoints on Sandbox:

Country TIN testing values
DE 48954371207
FR 3023217600053
IT SSSNNN31B28X000C
ES Test data can be generated from this website

Step 4: Upload documents

In this step, you must do the following:

  • Collect proof of profession from the freelancer in your sign-up flow and upload it to Solaris.
  • Upload the signed B2B SDD mandate to Solaris.

4.1 Collect proof of profession

The freelancer must submit a proof of profession in your sign-up flow. Check the onboarding requirements guide for more information on the accepted proofs of profession.

Afterward, call the POST Create a person document endpoint to upload the document and attach it to the freelancer's person resource, and set the document_type property to PROOF_OF_PROFESSION.

4.2 Upload the B2B SDD mandate

For B2B mandates, you also have to upload the SDD mandate signed by the freelancer in your sign-up flow to Solaris. Call the POST Create a person document endpoint to upload the signed mandate and attach it to the freelancer, and set the document_type property to B2B_MANDATE.


Step 5: Create credit card application

In this step, you must collect additional information from the freelancer related to the credit card application and pass it to Solaris using the following endpoint.

POST Create credit card application for a freelancer

This endpoint creates a credit card application for the customer. The application includes all the required information about the customer, such as their self-declared financial information, credit card type, and requested limit, which Solaris' credit scorer uses to initiate a series of credit checks.

attention

The following fields are just an indication. Solaris will share the mandatory fields based on your banking use case.

Mandatory fields

Add the following mandatory properties in the request body:

  • product_type: Credit card type. For freelancers, choose FREELANCER_CREDIT_CARD.
  • repayment_options: An object containing the repayment options of the credit card.

    • upcoming_type: The type of credit card (e.g., revolving or charge card). Options are FULL or PARTIAL.
    • minimum_amount: Minimum amount of the used limit to be repaid at the end of each billing cycle. Only relevant in case upcoming_type is set to PARTIAL.
    • minimum_percentage: Minimum percentage of the used limit to be repaid at the end of each billing cycle. Only relevant in case upcoming_type is set to PARTIAL.
  • scoring_options: An object containing different fields relevant for the credit scoring process:

    • customer_desired_limit: The credit card limit requested by the freelancer, subject to the scorer's decision.
    • number_of_dependents: The number of dependents (e.g., children or spouse) who depend on the freelancer's income.
    • marital_status
    • net_income: The freelancer's net income amount in EUR after tax deduction.
    • living_situation: The freelancer's living situation. Possible values are LIVING_WITH_PARENTS, LIVING_IN_RENTED_HOUSE, or LIVING_IN_OWN_HOUSE.
    • living_situation_expenses: The freelancer's living monthly expenses (e.g., rent or mortgage, utilities, health insurance, etc.)
    • existing_credit_repayment_excluding_mortgage: A field containing information about the freelancer's existing debt repayments (in EUR) (excluding mortgage payments).
    • other_credit_credit_limit: If the freelancer has existing credit cards, include the granted limit in this field.
    • employment_since: The date when the freelancer started their freelance business.
    • annual_turnover: The annual turnover of the freelance business.
    • monthly_business_costs: The monthly costs of the freelance business.
    • total_clients_12_months: The number of clients the freelancer had for the past 12 months.

Request example

Copy
Copied
// POST /v1/persons/{person_id}/credit_card_applications
{
  "product_type": "FREELANCER_CREDIT_CARD",
  "repayment_options": {
    "upcoming_type": "PARTIAL",
    "minimum_amount": {
      "value": 100,
      "unit": "cents",
      "currency": "EUR"
    },
    "minimum_percentage": 3
  },
  "scoring_options": {
    "customer_desired_limit": {
      "value": 50000,
      "unit": "cents",
      "currency": "EUR"
    },
    "number_of_dependents": 1,
    "marital_status": "MARRIED",
    "living_situation": "LIVING_WITH_PARENTS",
    "living_situation_expenses": {
      "value": 20000,
      "unit": "cents",
      "currency": "EUR"
    },
    "net_income": {
      "value": 30000,
      "unit": "cents",
      "currency": "EUR"
    },
    "credit_repayment_excluding_mortgage": {
      "value": 10000,
      "unit": "cents",
      "currency": "EUR"
    },
    "other_credit_card_limit": {
      "value": 100000,
      "unit": "cents",
      "currency": "EUR"
    },
    "employment_since": "2019-08-24",
    "annual_turnover": {
      "value": 500000,
      "unit": "cents",
      "currency": "EUR"
    },
    "monthly_business_costs": {
      "value": 25000,
      "unit": "cents",
      "currency": "EUR"
    },
    "total_clients_12_months": 10
  }
}

The API call returns an object with a unique id (the application_id), including the application status (initially set to PENDING) and the remaining attributes, which will be populated during the application lifecycle.

Additionally, the call automatically triggers Solaris' credit scoring system, which scores the application and provides its decision on the credit card application, including the limit.

Click here to view the full API reference.

GET Retrieve credit card application

This endpoint returns the current status and details of an existing credit card application. For a list of possible values of the application status and their descriptions, check the appendix.

Additionally, subscribe to the webhook event CREDIT_CARD_APPLICATION to receive status updates on the application.

Request URL

Copy
Copied
GET /v1/credit_card_applications/{id}

Click here to view the full API reference.

Application status flow

The following diagram shows the different statuses and transitions for a credit card application:

Diagram: Credit card application status


Step 6: Complete the customer identification and due diligence process

In this step, create and trigger the Know Your Customer (KYC) process for your customer and make sure the customer completes the KYC and the customer due diligence (CDD) process successfully.

6.1 Customer identification

All customers must be successfully identified using a suitable KYC method to be onboarded for any of Solaris' products.

Solaris offers different identification methods based on the product, region, and customer type. For an overview of the suitable KYC method per country, check the onboarding requirements guide, and consult with your Partner Manager about the identification method tailored to your banking use case.

This guide explains the integration process with video identification with IDnow as the identification method. IDnow is only available to customers, residing in Germany with a supported identification document. Check the KYC guide for instructions on how to create an identification resource and trigger the identification process for your customer, starting from step 2.

attention

Please note that the main freelancer along with at least 6 of their employees must be identified using video identification to fulfill the minimum legal requirements. The remaining employees can be identified using Autoident.


6.2 Customer due diligence

Solaris conducts risk screening and customer vetting checks, known as the Customer Due Diligence process, on new and existing customers. The result of this process is stored in different properties in the person resource.

All risk screening fields must have a green status for the customer to be onboarded. For more information, check the Customer Due Diligence guide.


6.3 Screening for FATCA indicia

To comply with the Foreign Account Tax Compliance Act (FATCA), Solaris is required to perform checks to determine whether the customer is subject to US tax law. These checks are in addition to the self-declaration during the Legal and Compliance screen.

To perform the FATCA checks, parse the person and identification resources using the following endpoints:

Hard criteria

To determine the customer's FATCA relevance, you must screen for the following hard criteria:

  • Has the customer provided a US passport as their identification document? Check the legitimation_country attribute on the identification resource.
  • Is the customer a citizen of the US? Check the nationality attribute.
  • Has the customer provided a residential address in the US, the US Minor Outlying Islands, or the US Virgin Islands? Check the country attribute.
  • Was the customer born in the US, the US Minor Outlying Islands, or the US Virgin Islands? Check the birth_country attribute.

When to reject the customer

If any of these hard criteria attributes have the value of US or USA, you must deny banking services to the customer and stop the onboarding process. Failure to screen for these hard FATCA criteria may cause ongoing operational burdens for Solaris customer support.

Soft criteria

To further determine the customer's FATCA relevance, screen for the following soft criteria:

  • Has the customer provided a US mobile number? Check the mobile_number attribute. US mobile numbers have a country code of +1.
  • Is the customer's only address a PO box or a c/o address? Check the address_line_1 and address_line_2 attributes.

When to reject the customer

  • If the answer is "Yes" to any of the soft criteria, ask the customer to clarify their phone number and/or address.

    • If the customer provides a non-US phone number and a physical address, you may onboard them.
  • If the customer does not provide a non-US phone number and a physical address, you may not onboard them.

Failure to screen for soft FATCA criteria may cause ongoing operational burdens for Solaris customer support.

attention

Note that Solaris periodically checks FATCA relevance for existing customers. If a customer's FATCA relevance changes to true, Solaris's Customer Support team will provide further instructions.

You can only proceed to the next steps when:

  • The identification status reaches successful.
  • All screening and risk checks in the CDD process have a green status.
  • The FATCA screening is completed to confirm the customer is not liable for taxes in the United States.

Step 7: Finalize credit card application

After successful customer identification process, finalize the credit card application by calling the following endpoint:

POST Finalize credit card application

Call this endpoint to finalize the credit card application. This API call triggers the creation of the credit card account by Solaris. The API response will return the account ID and IBAN and the application status changes to FINALIZED. Additionally, the billing cycle start and end date will be automatically calculated.

Request URL

Copy
Copied
POST /v1/credit_card_applications/{id}/finalize

Click here to view the full API reference.

Credit card account

The account ID and IBAN returned in the payload of the previous call is the account associated with the credit card to which the credit card limit will be attached.

note
  • For business and freelancer credit cards, the business or the freelancer will be the account holder and the approved credit card limit will be attached to this account. Afterward, the business or freelancer can request credit cards for their employees and attach spending limits to the cards. In this case, the employee is only a cardholder who can access and use the funds allocated to them through the usage of their issued credit card.
  • Please note that a credit card account is a restricted account. Check the credit card usage section to know about allowed transactions.

Check the account management guide to find details about how to manage and service accounts.


Step 8: Create reference account and set credit card limit

In this step, you must create a reference account for the customer. The reference account will be used as the account in the SDD mandate, from which Solaris will pull the SDD payments.

Reference accounts API reference

Visit the following link to find all the endpoints related to the reference account resource, including related properties and examples.

POST Create reference account

After creating the SDD mandate, you must create a reference account resource for the customer and link it to the internal account. You must add the customer's person_id and account_id in the request URL. You must add the external account details and the signed mandate information in the request body.

You must include the following properties in the request body:

  • name: The customer's name on their external bank account.
  • iban: The IBAN of the external bank account from which the SDD will be debited.
  • mandate_number: The number of the SDD mandate the customer signed.
  • mandate_signature_date: The date when the customer signed the SDD mandate.

Request URL

Copy
Copied
// POST /v1/persons/{person_id}/accounts/{account_id}/reference_accounts
{
 	"name": "Max Mustermann",
  "iban": "DE32110101001000000029",
 	"mandate_number": "SAMPAY7D226d32882d11Eb8DcD0242Ae2F4",
 	"mandate_signature_date": "2016-04-20"
}

The API call returns an object with a unique ID, which is the reference account ID. The status field refers to the reference account's status. Possible values are ACTIVE and INACTIVE.

Click here to view the full API reference.

After creating the reference account, you must attach the credit limit approved by Solaris to the credit card's account using the following endpoint.

note

You can set the credit card limit to the account as you see fit as long as it falls within or equals the limit approved by Solaris.

PATCH Attach credit limit to credit card account

Request example

Copy
Copied
// PATCH /v1/credit_card_applications/{id}/limit
{
  "limit": {
    "value": 1000,
    "unit": "cents",
    "currency": "EUR"
  }
}

The API call returns the details of the application and sets the current_limit to the limit defined by you. The limit will also be attached to the associated credit card account.

Click here to view the full API reference.


Step 9: Onboard employees

In this step, you need to collect the information of the freelancer's employees who will be issued a credit card.

9.1 Create person resources for all cardholders

For each employee (e.g., cardholder) that will be issued a credit card, collect the required data points and create a person resource using the following endpoint.

Required data points for a cardholder with full KYC

This person will be identified using video identification.

  • salutation
  • first_name (Including all middle names as printed on the ID document)
  • last_name (Including all middle names as printed on the ID document)
  • address
  • birth_date
  • birth_city
  • nationality
  • email
  • mobile_number
  • fatca_relevant
  • fatca_crs_confirmed_at

Required data points for a cardholder with light KYC

This person will be identified using Autoident.

  • salutation
  • first_name (Including all middle names as printed on the ID document)
  • last_name (Including all middle names as printed on the ID document)
  • address
  • birth_date
  • birth_city
  • nationality
  • email
  • mobile_number

Request URL

Copy
Copied
POST /v1/persons

Click here to view the full API reference

9.2 Create and verify mobile numbers of all cardholders

All employees who will be issued a credit card must have a verified mobile number. Repeat the same steps described in step 2 for each person who will be issued a credit card.

9.3 Identify employees

At least 6 persons must be identified using video identification as explained in step 6.1.

All other cardholders will be identified using a light KYC method, such as IDnow AutoIdent. For each person you've created, you must create and trigger an identification using the following endpoint:

POST Create an identification for a cardholder via AutoIdent

Call this endpoint to create an identification for the cardholder via IDnow's AutoIdent:

Copy
Copied
// POST /v1/persons/:person_id/identifications
{
  "idnow_autoident"
}

Click here to view the full API reference.

PATCH Request an identification for a cardholder via AutoIdent

Call this endpoint to trigger the KYC flow.

Copy
Copied
// POST /v1/persons/:person_id/identifications
{
  "idnow_autoident"
}

Click here to view the full API reference.


Step 10: Create and activate credit card

In this step, create and activate the credit card for all employees. The customer can choose between different card types, such as a physical or a virtual card, with the option to tokenize the card to be used in any e-wallet, such as Google Pay or Apple Pay.

API reference

Visit the following link to find all the endpoints related to cards, including related properties and examples.

POST Create a card

This endpoint initiates the card creation process for the customer. Include the account_id along with the person_id in the request URL. Additionally, include the following properties in the request body:

  • line_1: The cardholder's name which will be printed on the card. Pay attention to the special rules governing card names mentioned here.
  • type: The card type. View here a list of possible card types for each customer segment.

Request URL:

Copy
Copied
POST /v1/persons/{person_id}/accounts/{account_id}/cards

Response example:

A card will be created in the system, and Solaris will issue a card creation request with SIA. The API will respond with the ID of the card and the status of PROCESSING.

Copy
Copied
{
  "id": "8febdba4912a747808ccc6f95f82aaa4",
  "status": "PROCESSING"
}

Click here to view the full API reference.

GET Retrieve card details

Before you can activate the card, make the following API call to retrieve the details of the card. The status must have the value of INACTIVE. The status change may take a few seconds after the initial POST Create card request, as Solaris submits card creation requests asynchronously to SIA.

The API will respond with the card details when the status changes to INACTIVE. Until then, the response will look the same as the one from the previous call.

Request URL:

Copy
Copied
GET /v1/cards/{card_id}

Click here to view the full API reference.

POST Activate a card

Once the card is INACTIVE and you have retrieved the details using the previous API call, you can activate the card using the following endpoint:

Request URL:

Copy
Copied
POST /v1/cards/{card_id}/activate

Click here to view the full API reference.

Cards servicing

For more information about cards servicing, check the Card creation and servicing guide.

Card push provisioning

If your customer wants to use their card in a digital wallet, such as Google Pay, Apple Pay, or Samsung Pay wallet, implement the relevant endpoints in the Card Push Provisioning guide.

info

See the Cards overview page for more information about cards.


Step 11: Servicing credit cards

In this section, you can find endpoints related to servicing credit cards.

PATCH Update repayment option

Your customer can change the repayment option after initial onboarding (e.g., switching from charge to revolving and vice versa).

attention

The requested repayment option will be effective from the next billing cycle.

You can update the repayment option by calling the following endpoint:

Request example

Copy
Copied
// PATCH /v1/credit_card_applications/{id}
{
  "repayment_options": {
    "upcoming_type": "PARTIAL",
    "minimum_amount": {
      "value": 100,
      "unit": "cents",
      "currency": "EUR"
    },
    "minimum_percentage": 3
  },
  "statement_with_details": true
}

Click here to view the full API reference.

GET Index a credit card bill

Call this endpoint to retrieve a credit card bill.

note

Please note that Solaris generates credit cards statements and uploads them to Postbox. You can use this endpoint if you want to generate your own bills.

Request URL

Copy
Copied
GET /v1/credit_card_bills/{bill_id}

Click here to view the full API reference.


Step 12: Terminating credit cards

This section describes how credit card termination works and how to use the related API endpoints.

Credit card termination process

Here is a summary of the termination process:

  1. Either you, the customer (via your frontend), or Solaris initiates the termination.

  2. Solaris' system will trigger a termination and calculate a legal closure date for the credit card.

    • If the credit card has a negative balance, then Solaris will generate a final bill and trigger a SEPA Direct Debit (SDD) from the customer's reference account.
    • If the credit card has a positive balance, then Solaris will initiate a payout to the attached reference account.
  3. You will receive notifications on the CREDIT_CARD_APPLICATION_TERMINATION webhook event when the status of the credit card application termination changes. If the termination succeeds, the credit card will be closed. If it fails, then Solaris Customer Support will provide assistance.

Pre-termination checks

Solaris will check for the following criteria before terminating a credit card:

  • The credit card is in dunning.
  • The credit card has CARD_TRANSACTION or CARD_DIRECT_DEBIT bookings from the past 45 days.
  • The credit card has reservations with the status OPEN.
  • The credit card has bookings with a valuta date in the future.
  • The last SDD was triggered less than 56 days ago.

If any of these criteria are met, then the technical closure of the credit card may be delayed.

POST Terminate a credit card application

This endpoint initiates a termination request for an existing credit card.

Termination requests can be revoked within 5 business days of their initiation. After that, the termination can not be reversed. See the endpoint below for instructions on how to revoke a termination request.

Request URL:

Copy
Copied
POST /v1/credit_card_applications/{application_id}/terminate

Required properties:

  • reason: The reason for terminating the credit card.

Click here to view the full documentation.

POST Revoke a termination request

This endpoint revokes a request to terminate a credit card.

Request URL:

Copy
Copied
POST /v1/credit_card_terminations/{id}/revoke

Click here to view the full documentation.


What's next?

Congratulations! You've successfully integrated Solaris' Credit Cards product.

Check the following appendices section for additional information on enums and testing data.

Useful resources

Check the following links for additional related guides and API reference documentation:


Appendix I: Enums

Credit card application status

The following table includes the enums for the field status and their descriptions in the credit card application resource. For example, it's available when you call the GET Retrieve credit card application.

Status Description Actions
PENDING The credit card application has been created for the customer and is currently being validated. Wait for the scorer's result.
IN_SCORING The application has passed the initial validation checks. The scorer has been triggered and the application is currently under credit scoring. Wait for the scorer's result.
PRE_APPROVED The scorer approved the credit card application. Trigger the identification flow for the customer. Download the SECCI form and credit card contract. Get the customer's consent on the SECCI and contract and upload signed documents.
FINALIZED The customer identification is successful and the credit card application has been finalized. Set the credit card limit on the account. Set up the reference account.
DECLINED The scorer has rejected the application and/or identification has failed, and the credit card application is rejected. Notify the customer and abort the onboarding process.

Document types

The following table includes the possible values for the field document_type and their descriptions.

Enum Description
ANNUAL_FINANCIAL_STATEMENT A business or a company's annual financial statement.
KYC_REPORT The KYC report generate after a successful customer identification.
ID_DOCUMENT An person's identification document, such as passport or ID.
SIGNATURE A signature example.
PICTURE A picture or a scanned document of any other type.
QES_DOCUMENT A document related to a Qualified Electronic Signature (QES).
SIGNED_CONTRACT A signed contract of any kind.
SIGNED_QES_DOCUMENT A document signed by a Qualified Electronic Signature (QES).
REGISTER_CHECK A register check.
REGISTER_EXTRACT A business or a company's commercial register excerpt or a similar document.
FOUNDATION_DOCUMENT The foundation document of a company or business.
SCHUFA_COMPACT_REPORT A compact SCHUFA report.
SCHUFA_GWG_REPORT A GWG SCHUFA report.
SCHUFA_FULL_REPORT A full SCHUFA report about a person.
SCHUFA_SHORT_REPORT A short SCHUFA report about a person.
CREDIT_AGENCY_REPORT A report issued by a credit agency.
SHARE_HOLDERS_AGREEMENT A business or a company's shareholders agreement.
SHAREHOLDERS_LIST A business or a company's shareholders list.
TRADING_LICENSE A business or a company's trading license.
TRANSPARENCY_REGISTER_EXTRACT An extract of a transparency register.
INVOICE An invoice of any kind.
OTHER Any other type of document.
VIDEO A video of any kind.
VAT_CERTIFICATE VAT registration certificate

Idnow status

The following table includes the possible values for the field status for the video identification process carried out by IDnow and the related description of each status.

Status Description
created The identification resource has been created for the customer.
pending The identification process has been triggered and the video identification URL and reference are generated. You must redirect the customer to the URL to complete the identification process with IDnow.
pending_failed The identification is currently under review. You cannot offer banking services to the customer at this stage. The identification might eventually turn to successful, but it is unlikely.
successful The video identification was successful. The customer can be onboarded. Please note that the customer's data might have been updated during the identification session.
aborted The customer aborted the identification process. The customer can still video-identify using the same URL.
canceled The provider canceled the video identification. The customer should video-identify again using the same URL.
failed The identification was unsuccessful. You cannot onboard the customer or offer any banking services to them.

IDnow provides a reason whenever the identification has a canceled or aborted status. No reason can be disclosed for the final failed status.