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.

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.

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

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:

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:

Sequence diagram

The following sequence diagram gives an overview of the integration 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.

• ACCOUNT_BLOCK
• ACCOUNT_CLOSURE
• ACCOUNT_CLOSURE_REQUEST
• BOOKING
• CARD_LIFECYCLE_EVENT
• CARD_AUTHORIZATION
• CARD_AUTHORIZATION_DECLINE_V2
• CARD_AUTHORIZATION_RESOLUTION
• CARD_FRAUD_CASE_PENDING
• CARD_FRAUD_CASE_TIMEOUT
• IDENTIFICATION
• PERSON_CHANGED
• PERSON_DELETED
• PERSON_SEIZURE_CREATED
• PERSON_SEIZURE_DELETED
• PERSON_SEIZURE_FULFILLED
• PERSON_SEIZURE_UPDATED
• PERSON_MOBILE_NUMBER_CREATED
• PERSON_MOBILE_NUMBER_DELETED
• PERSON_TAX_IDENTIFICATION_CHANGED
• POSTBOX_ITEM_CREATED
• POTENTIAL_ACCOUNT_BLOCKING
• SCA_CHALLENGE

• CREDIT_CARD_APPLICATION

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:

• Person resource API reference:

  • POST Create person
  • GET Retrieve a person
  • PATCH Update person

Related webhook events

• PERSON_CHANGED
• PERSON_DELETED

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:

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

  • line_1
  • line_2
  • postal_code
  • city
  • country (ISO 3166-1 alpha-2 codes)
• 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

// 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.

{
    "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

Request URL

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).

API reference

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

• Mobile number resource API reference

Related webhook events

• PERSON_MOBILE_NUMBER_CREATED
• PERSON_MOBILE_NUMBER_DELETED

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:

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.

{
    "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:

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

Response example:

{
    "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:

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

Response example:

{
    "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

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

• Person tax identifications API reference:

  • POST Create person tax identification
  • GET Retrieve person tax identification
  • PATCH Update person tax identification

Related webhook events

• PERSON_TAX_IDENTIFICATION_CHANGED

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:

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:

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.

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

// 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

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:

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.

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:

• GET Retrieve person
• GET Retrieve person identification

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.

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

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.

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.

• Reference accounts resource API reference:

  • POST Create a reference account for a person
  • GET Index reference accounts for a person

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

// 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.

PATCH Attach credit limit to credit card account

Request example

// 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

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:

// 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.

// 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.

• Cards API reference

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:

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.

{
  "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:

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:

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.

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).

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

Request example

// 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.

Request URL

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.

   • If Solaris initiated the termination, then you will receive a notification on the CREDIT_CARD_APPLICATION_TERMINATION webhook event and you must immediately notify the customer about the termination.
   • If the customer initiated the termination, then your application must call the POST Terminate a credit card application endpoint. This will create a credit card application termination resource.

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:

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:

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:

• Credit cards API reference documentation
• Reference accounts API reference documentation
• Video Identification
• Account management guide
• Card creation & servicing guide
• SEPA Transfers Overview
• SEPA Direct Debit Transfers

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.

Document types

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

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.

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