# Freelancer credit cards ## Introduction With Solaris credit cards for freelancers, you can offer credit cards to freelancers and their employees via an automated onboarding flow. To onboard a freelancer, they must complete the standard onboarding flow, including customer identification (KYC) and specific credit card setup steps. ### How does it work? Using Solaris credit cards, freelancers can offer their employees credit cards. The freelancer acts as the account owner, while employees are cardholders who only have access to funds allocated by the freelancer. **Freelancers can apply for a credit card through your solution by doing the following:** 1. Fulfill all legal and compliance requirements. 2. Submit the required data points and documents. 3. Pass the credit scoring process. 4. Complete the customer identification flow (KYC). 5. Onboard their employees who will be issued a credit card. 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 in the [Types of credit cards](/guides/cards/credit-cards#types-of-credit-cards) section. * This page covers the specific integration steps for freelancer credit cards. See the [Credit Cards Overview](/guides/cards/credit-cards) for general product logic. * For sole proprietors, use the [Business credit cards onboarding guide](/guides/cards/credit-cards/business-credit-cards). ## System prerequisites Before starting the onboarding process, implement the following requirements: ### 1. Technical setup Before starting, ensure your environment is configured for the **Digital Banking** product scope. * **Authentication:** Retrieve your client credentials and set up your OAuth flow. * **Webhooks:** Configure your endpoint to receive event notifications (e.g., incoming transfers, status changes). [View the Technical Setup Guide](/guides/get-started/technical-setup) ### 2. Legal & Compliance screens You must integrate specific consent screens into your signup flow *before* initiating the API onboarding process. **Required Screens:** 1. **Terms & Conditions:** Collect explicit consent to Solaris T&Cs. 2. **Customer Information:** verify personal details. 3. **Economic Interest:** Confirm the customer is acting on their own behalf. 4. **Tax Information:** Collect Tax ID (required for Germany). 5. **FATCA/CRS:** Determine US tax liability. 6. **PEP Declaration:** Self-declaration for Politically Exposed Persons (Required for FR, IT, ES). **Data Storage:** For every consent screen, you must capture a **UTC timestamp** (e.g., `2023-10-27T10:00:00Z`). These timestamps are mandatory fields when creating the `person` resource. | Consent Type | API Field (Person Resource) | | --- | --- | | Terms & Conditions | `terms_conditions_signed_at` | | Data Processing | `data_terms_signed_at` | | Economic Interest | `own_economic_interest_signed_at` | | FATCA/CRS | `fatca_crs_confirmed_at` | [View the Legal Screens Guide](/guides/get-started/onboarding-requirements/1-legal-compliance-screens) ### B2B SDD mandate Create a 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](/guides/digital-banking/sepa-transfers/sepa-direct-debit-transfer/#sdd-mandate) (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 * This guide includes the onboarding requirements for both charge and revolving cards for freelancers in Germany. * The following integration uses [IDnow video identification](/guides/kyc/videoident) 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. ```mermaid flowchart TD %% --- Chart Structure --- subgraph P1 ["Phase 1: Freelancer Registration"] A1("Step 1:
Collect Data &
Create Person") --> A2("Step 2:
Verify Mobile Number") A2 --> A3("Step 3:
Create Tax Identification") A3 --> A4("Step 4:
Upload Proof of
Profession & Mandate") end subgraph P2 ["Phase 2: Application"] A4 --> B1("Step 5:
Create CC Application") B1 --> B2{Scoring
Check} B2 -->|Pre-Approved| C1("Step 6:
Trigger KYC &
CDD Checks") end subgraph P3 ["Phase 3: Identification"] C1 --> C2{KYC/CDD
Successful?} end subgraph P4 ["Phase 4: Finalization"] C2 -->|Yes| D1("Step 7:
Finalize Application") D1 --> D2("Step 8:
Create Reference Account
& Set Limit") end subgraph P5 ["Phase 5: Employee Onboarding"] D2 --> E1("Step 9:
Onboard Employees") end subgraph P6 ["Phase 6: Activation"] E1 --> F1("Step 10:
Create & Activate Cards") F1 --> F2("Step 11:
Card Servicing") end G[Decline / Abort] %% --- Connections for Failure Cases --- B2 -->|Declined| G C2 -->|No| G %% --- Inline Style Definitions --- style A1 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style A2 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style A3 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style A4 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style B1 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style B2 fill:#dedbd3,color:#1b2230,stroke:#5e6a7a,stroke-width:2px style C1 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style C2 fill:#dedbd3,color:#1b2230,stroke:#5e6a7a,stroke-width:2px style D1 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style D2 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style E1 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style F1 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style F2 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style G fill:#ffc2ad,color:#1b2230,stroke:#5d5746,stroke-width:2px %% --- Clickable Links --- click A1 "#step-1-collect-customer-data-and-create-person-resource" click A2 "#step-2-create-and-verify-mobile-number" click A3 "#step-3-create-customer-tax-identification" click A4 "#step-4-upload-documents" click B1 "#step-5-create-credit-card-application" click C1 "#step-6-complete-the-customer-identification-and-due-diligence-process" click D1 "#step-7-finalize-credit-card-application" click D2 "#step-8-create-reference-account-and-set-credit-card-limit" click E1 "#step-9-onboard-employees" click F1 "#step-10-create-and-activate-credit-card" click F2 "#step-11-servicing-credit-cards" ``` br You can integrate the Solaris freelancer credit card product by completing the 11 steps explained in the following sections. | Category | Step | Description | | --- | --- | --- | | **Customer registration** | [Step 1](#step-1-collect-customer-data-and-create-person-resource) | Collect the mandatory data points and create a person resource for your customer. | | **Customer registration** | [Step 2](#step-2-create-and-verify-mobile-number) | Create and verify the customer's mobile number. | | **Customer registration** | [Step 3](#step-3-create-customer-tax-identification) | Collect the customer's tax information and create a tax identification resource. | | **Customer registration** | [Step 4](#step-4-upload-documents) | Collect the customer's proof of profession and upload it along with the signed B2B SDD mandate. | | **Credit card application** | [Step 5](#step-5-create-credit-card-application) | 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](#61-customer-identification) | 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](#62-customer-due-diligence) | Ensure that all persons pass the customer due diligence process before proceeding with the following steps. | | **Customer identification** | [Step 6.3](#63-screening-for-fatca-indicia) | Ensure that all persons pass the FATCA checks. | | **Credit card confirmation & reference account** | [Step 7](#step-7-finalize-credit-card-application) | Finalize the credit card application to trigger the account creation. | | **Credit card confirmation & reference account** | [Step 8](#step-8-create-reference-account-and-set-credit-card-limit) | Create a reference account for the customer and attach the credit limit to the credit card account. | | **Employee onboarding** | [Step 9](#step-9-onboard-employees) | **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](#91-create-person-resources-for-all-cardholders). **9.2** Collect and confirm the mobile number of each employee who will be issued a credit card as explained in [Step 9.2](#92-create-and-verify-mobile-numbers-of-all-cardholders). **9.3** Create and trigger the identification for each employee by completing [step 9.3](#93-identify-employees). | | **Card creation, activation & servicing** | [Step 10](#step-10-create-and-activate-credit-card) | Create and activate the credit card for the customer. | | **Card creation, activation & servicing** | [Step 11](#step-11-servicing-credit-cards) | Implement all endpoints related to servicing credit cards. | ### Sequence diagram The following sequence diagram gives an overview of the integration flow: Diagram: Freelancer credit cards flow In the following sections, you can find descriptions of these steps and their related endpoints. ### Webhooks Subscribe to the following webhook events to automate your integration. For implementation details, check the [webhooks documentation](/api-reference/webhooks/). ### Identity and person data * [`IDENTIFICATION`](/api-reference/onboarding/webhooks/webhook-events/paths/identification/post) * [`PERSON_CHANGED`](/api-reference/onboarding/webhooks/webhook-events/paths/person_changed/post) * [`PERSON_DELETED`](/api-reference/onboarding/webhooks/webhook-events/paths/person_deleted/post) * [`PERSON_MOBILE_NUMBER_CREATED`](/api-reference/onboarding/webhooks/webhook-events/paths/person_mobile_number_created/post) * [`PERSON_MOBILE_NUMBER_DELETED`](/api-reference/onboarding/webhooks/webhook-events/paths/person_mobile_number_deleted/post) * [`PERSON_TAX_IDENTIFICATION_CHANGED`](/api-reference/onboarding/webhooks/webhook-events/paths/person_tax_identification_changed/post) ### Accounts and bookings * [`BOOKING`](/api-reference/onboarding/webhooks/webhook-events/paths/booking/post) * [`ACCOUNT_BLOCK`](/api-reference/onboarding/webhooks/webhook-events/paths/account_block/post) * [`ACCOUNT_CLOSURE`](/api-reference/onboarding/webhooks/webhook-events/paths/account_closure/post) * [`ACCOUNT_CLOSURE_REQUEST`](/api-reference/onboarding/webhooks/webhook-events/paths/account_closure/post) * [`POTENTIAL_ACCOUNT_BLOCKING`](/api-reference/onboarding/webhooks/webhook-events/paths/potential_account_blocking/post) * [`POSTBOX_ITEM_CREATED`](/api-reference/onboarding/webhooks/webhook-events/paths/postbox_item_created/post) ### Cards * [`CARD_LIFECYCLE_EVENT`](/api-reference/onboarding/webhooks/webhook-events/paths/card_lifecycle_event/post) * [`CARD_AUTHORIZATION`](/api-reference/onboarding/webhooks/webhook-events/paths/card_authorization/post) * [`CARD_AUTHORIZATION_DECLINE_V2`](/api-reference/onboarding/webhooks/webhook-events/paths/card_authorization_decline_v2/post) * [`CARD_AUTHORIZATION_RESOLUTION`](/api-reference/onboarding/webhooks/webhook-events/paths/card_authorization_resolved/post) * [`CARD_FRAUD_CASE_PENDING`](/api-reference/onboarding/webhooks/webhook-events/paths/card_fraud_case_pending/post) * [`CARD_FRAUD_CASE_TIMEOUT`](/api-reference/onboarding/webhooks/webhook-events/paths/card_fraud_case_timeout/post) ### Compliance and seizures * [`PERSON_SEIZURE_CREATED`](/api-reference/onboarding/webhooks/webhook-events/paths/person_seizure_created/post) * [`PERSON_SEIZURE_DELETED`](/api-reference/onboarding/webhooks/webhook-events/paths/person_seizure_deleted/post) * [`PERSON_SEIZURE_FULFILLED`](/api-reference/onboarding/webhooks/webhook-events/paths/person_seizure_fulfilled/post) * [`PERSON_SEIZURE_UPDATED`](/api-reference/onboarding/webhooks/webhook-events/paths/person_seizure_updated/post) ### Authentication * [`SCA_CHALLENGE`](/api-reference/onboarding/webhooks/webhook-events/paths/sca_challenge/post) * [CREDIT_CARD_APPLICATION](/api-reference/onboarding/webhooks/webhook-events/paths/credit_card_application/post) ### Mandatory features You must integrate all the mandatory features for Digital Banking & Cards highlighted in the [Onboarding requirements guide](/guides/get-started/onboarding-requirements/6-mandatory-features) before going live with your solution **except for** Account Closure. Credit cards have their own termination process, which is [described below](#step-12-terminating-credit-cards). ## 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](#system-prerequisites). Afterward, pass all the data points to Solaris by creating a [person resource](/guides/get-started/onboarding-requirements/2-data-collection) 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](/api-reference/onboarding/persons/#tag/Persons) - [POST Create person](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons/post) - [GET Retrieve a person](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons~1%7Bid%7D/get) - [PATCH Update person](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons~1%7Bid%7D/patch) **Related webhook events** - [`PERSON_CHANGED`](/api-reference/onboarding/webhooks/webhook-events/paths/person_changed/post) - [`PERSON_DELETED`](/api-reference/onboarding/webhooks/webhook-events/paths/person_deleted/post) Important points about data collection - Review the special requirements in the [Onboarding requirements guide](/guides/get-started/onboarding-requirements/2-data-collection/#important-considerations-for-data-collection). - Submit information exactly as it appears in official documents. - **Sandbox Testing:** 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. - **Privacy:** Do not use real personal data when testing in 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` - `line_1` - `line_2` - `postal_code` - `city` - `country` ([ISO 3166-1 alpha-2 codes](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2)) - `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](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2)) - `nationality` ([ISO 3166-1 alpha-2 codes](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2)) - `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](https://nacev2.com/en). - `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** ```json // 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. ```json { "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](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons/post) #### 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` Important **Restricted Updates:** * Fields not mentioned in this list can only be updated via Customer Support. **Freelancer & Self-Employed Requirements (B2C):** * If a customer changes their `employment_status` to `FREELANCER` or `SELF_EMPLOYED`, you must include **one** of the following in the request to avoid an error: 1. The customer's `nace_code` (Recommended for data quality). 2. Set `industry` and `industry_key` to `null`. **Request URL** ```shell PATCH /v1/persons/{id} ``` **Request example** * [API Reference: Update person](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons~1%7Bid%7D/patch) ## 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. - [Mobile number resource API reference](/api-reference/onboarding/persons/#tag/Person-mobile-numbers) **Related webhook events** - [PERSON_MOBILE_NUMBER_CREATED](/api-reference/onboarding/webhooks/webhook-events/paths/person_mobile_number_created/post) - [PERSON_MOBILE_NUMBER_DELETED](/api-reference/onboarding/webhooks/webhook-events/paths/person_mobile_number_deleted/post) 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. You must include the customer's `person_id` in the request URL. **Request URL** ```shell POST /v1/persons/{person_id}/mobile_number ``` **Request example** ```json { "number": "+15550101" } ``` **Response example** The API returns a `mobile_number` resource with a unique `id` and attaches it to the `person` resource. ```json { "id": "91e4d939d781b8eb30d1ee86809761c2cmno", "number": "+15550101", "verified": false } ``` [Click here to view the full API reference.](/api-reference/onboarding/persons/#tag/Person-mobile-numbers/paths/~1v1~1persons~1%7Bperson_id%7D~1mobile_number/post) #### 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 URL** ```shell POST /v1/persons/{person_id}/mobile_number/authorize ``` **Request example** ```json { "number": "+15550101" } ``` **Response example** ```json { "id": "91e4d939d781b8eb30d1ee86809761c2cmno", "number": "+15550101", "verified": false } ``` [Click here to view the full API reference.](/api-reference/onboarding/persons/#tag/Person-mobile-numbers/paths/~1v1~1persons~1%7Bperson_id%7D~1mobile_number~1authorize/post). #### 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 URL** ```shell POST /v1/persons/{person_id}/mobile_number/confirm ``` **Request example** ```json { "number": "+15550101", "token": "212212" } ``` **Response example** ```json { "id": "91e4d939d781b8eb30d1ee86809761c2cmno", "number": "+15550101", "verified": true } ``` [Click here to view the full API reference.](/api-reference/onboarding/persons/#tag/Person-mobile-numbers/paths/~1v1~1persons~1%7Bperson_id%7D~1mobile_number~1confirm/post) For more information about how to manage mobile numbers (e.g., changing or deleting a number), check the related [mobile number management guide](/guides/digital-banking/mobile-number-management). ## Step 3: Create customer tax identification In this step, collect the relevant [tax information](/guides/get-started/onboarding-requirements/3-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, 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](/guides/get-started/onboarding-requirements/3-tax-information#tax-identification-number-tin-per-country) 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: - [Person tax identifications API reference](/api-reference/onboarding/persons/#tag/Person-tax-identifications): - [POST Create person tax identification](/api-reference/onboarding/persons/#tag/Person-tax-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1tax_identifications/post) - [GET Retrieve person tax identification ](/api-reference/onboarding/persons/#tag/Person-tax-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1tax_identifications~1%7Bid%7D/get) - [PATCH Update person tax identification ](/api-reference/onboarding/persons/#tag/Person-tax-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1tax_identifications~1%7Bid%7D/patch) **Related webhook events** - [PERSON_TAX_IDENTIFICATION_CHANGED](/api-reference/onboarding/webhooks/webhook-events/paths/person_tax_identification_changed/post) #### 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:** ```shell POST /v1/persons/{person_id}/tax_identifications ``` [Click here to view the full API reference.](/api-reference/onboarding/persons/#tag/Person-tax-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1tax_identifications/post) ### 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](https://testingdatagenerator.com/doi.html) | ## Step 4: Upload documents In this step, you must do the following: 1. Collect proof of profession from the freelancer in your sign-up flow and upload it to Solaris. 2. 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 [Document collection guide](/guides/get-started/onboarding-requirements/4-document-collection) 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`. [View Create a person document API reference](/api-reference/onboarding/persons/#tag/Person-documents/paths/~1v1~1persons~1%7Bperson_id%7D~1documents/post) ## 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. 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** ```json // 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. [View full API reference](/api-reference/digital-banking/credit-cards/#tag/Credit-cards/paths/~1v1~1persons~1%7Bperson_id%7D~1credit_card_applications/post) ### 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** ```shell GET /v1/credit_card_applications/{id} ``` [Click here to view the full API reference.](/api-reference/digital-banking/credit-cards/#tag/Credit-cards/paths/~1v1~1credit_card_applications~1%7Bid%7D/get) ### 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](/guides/get-started/onboarding-requirements/5-kyc), 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 [Video identification guide](/guides/kyc/videoident) for instructions on how to create an identification resource and trigger the identification process for your customer, starting from step 2. 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](/guides/kyc/cdd). ### 6.3 Screening for FATCA indicia To comply with the [Foreign Account Tax Compliance Act (FATCA)](https://www.irs.gov/businesses/corporations/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](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons~1%7Bid%7D/get) - [GET Retrieve person identification](/api-reference/identity/identifications/#tag/Person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications~1%7Bid%7D/get) #### 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. Important 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** ```shell POST /v1/credit_card_applications/{id}/finalize ``` [Click here to view the full API reference.](/api-reference/digital-banking/credit-cards/#tag/Credit-cards/paths/~1v1~1credit_card_applications~1%7Bid%7D~1finalize/post) ### 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. - 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](/guides/cards/credit-cards/#credit-card-usage) section to know about allowed transactions. Check the [account management guide](/guides/digital-banking/account-management/) 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](/api-reference/digital-banking/account-management/#tag/Reference-accounts): - [POST Create a reference account for a person](/api-reference/digital-banking/account-management/#tag/Reference-accounts/paths/~1v1~1persons~1%7Bperson_id%7D~1accounts~1%7Baccount_id%7D~1reference_accounts/post) - [GET Index reference accounts for a person](/api-reference/digital-banking/account-management/#tag/Reference-accounts/paths/~1v1~1persons~1%7Bperson_id%7D~1accounts~1%7Baccount_id%7D~1reference_accounts/get) #### 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** ```json // 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](/api-reference/digital-banking/account-management/#tag/Reference-accounts/paths/~1v1~1persons~1%7Bperson_id%7D~1accounts~1%7Baccount_id%7D~1reference_accounts/post). After creating the reference account, you must attach the credit limit approved by Solaris to the credit card's account using the following endpoint. 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** ```json // 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.](/api-reference/digital-banking/credit-cards/#tag/Credit-cards/paths/~1v1~1credit_card_applications~1%7Bid%7D~1limit/patch) ## 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** ```shell POST /v1/persons ``` [View full API reference](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons/post) ### 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](#step-2-create-and-verify-mobile-number) 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](#61-customer-identification). All other cardholders will be identified using a light KYC method, such as [IDnow AutoIdent](https://docs-autoident.idnow.io/?version=latest#107f6d04-34a7-4ac7-a8b4-e0243b9f4450). 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: ```json // POST /v1/persons/:person_id/identifications { "method": "idnow_autoident" } ``` [View full API reference](/api-reference/identity/identifications/#tag/Person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications/post) #### PATCH Request an identification for a cardholder via AutoIdent Call this endpoint to trigger the KYC flow. ```json // POST /v1/persons/:person_id/identifications { "idnow_autoident" } ``` [View full API reference](/api-reference/identity/identifications/#tag/Person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications~1%7Bid%7D~1request/patch) ## 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](/api-reference/digital-banking/cards/) #### 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](/guides/cards/creation-and-servicing/#cardholder-name-and-address-generation). - `type`: The card type. View [here](/guides/cards/creation-and-servicing/#appendix-i-card-types) a list of possible card types for each customer segment. **Request URL:** ```shell 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`. ```json { "id": "8febdba4912a747808ccc6f95f82aaa4", "status": "PROCESSING" } ``` [Click here to view the full API reference.](/api-reference/digital-banking/cards/#tag/Cards-servicing/paths/~1v1~1persons~1%7Bperson_id%7D~1accounts~1%7Baccount_id%7D~1cards/post) #### 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:** ```shell GET /v1/cards/{card_id} ``` [Click here to view the full API reference.](/api-reference/digital-banking/cards/#tag/Cards-servicing/paths/~1v1~1cards~1%7Bid%7D/get) #### 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:** ```shell POST /v1/cards/{card_id}/activate ``` [Click here to view the full API reference.](/api-reference/digital-banking/cards/#tag/Cards-servicing/paths/~1v1~1cards~1%7Bcard_account_id%7D~1activate/post) ### Cards servicing For more information about cards servicing, check the [Card creation and servicing guide](/guides/cards/creation-and-servicing/). ### 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](/guides/cards/push-provisioning). See the [Cards overview page](/guides/cards/credit-cards) 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). 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** ```json // 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.](/api-reference/digital-banking/credit-cards/#tag/Credit-cards/paths/~1v1~1credit_card_applications~1%7Bid%7D/patch) ### GET Index a credit card bill Call this endpoint to retrieve a credit card bill. 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** ```shell GET /v1/credit_card_bills/{bill_id} ``` [Click here to view the full API reference.](/api-reference/digital-banking/credit-cards/#tag/Credit-cards/paths/~1v1~1credit_card_bills~1%7Bbill_id%7D/get) ## 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](/api-reference/onboarding/webhooks/webhook-events/paths/credit_card_application_termination/post) 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](/api-reference/digital-banking/credit-cards/#tag/Termination-requests/paths/~1v1~1credit_card_applications~1%7Bapplication_id%7D~1termination_requests/post) 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](/api-reference/onboarding/webhooks/webhook-events/paths/credit_card_application_termination/post) 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:** ```shell 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.](/api-reference/digital-banking/credit-cards/#tag/Termination-requests/paths/~1v1~1credit_card_applications~1%7Bapplication_id%7D~1termination_requests/post) ### POST Revoke a termination request This endpoint revokes a request to terminate a credit card. **Request URL:** ```shell POST /v1/credit_card_terminations/{id}/revoke ``` [Click here to view the full documentation.](/api-reference/digital-banking/credit-cards/#tag/Termination-requests/paths/~1v1~1credit_card_terminations~1%7Bid%7D~1revoke/post) ## What's next? Congratulations! You've successfully integrated the 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](/api-reference/digital-banking/credit-cards/#tag/Credit-cards) * [Reference accounts API reference documentation](/api-reference/digital-banking/account-management/#tag/Reference-accounts) * [Video Identification](/guides/kyc/videoident) * [Account management guide](/guides/digital-banking/account-management) * [Card creation & servicing guide](/guides/cards/creation-and-servicing) * [SEPA Transfers Overview](/guides/digital-banking/sepa-transfers) * [SEPA Direct Debit Transfers](/guides/digital-banking/sepa-transfers/sepa-direct-debit-transfer) ## 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 company's annual financial statement. | | `KYC_REPORT` | The KYC report generated after successful customer identification. | | `ID_DOCUMENT` | A person's identification document, such as a passport or ID card. | | `SIGNATURE` | A signature sample. | | `PICTURE` | A picture or 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_APPLICATION` | A document proving the application for registration (Gründungsurkunde), used for companies "in formation". | | `REGISTER_CHECK` | A register check. | | `REGISTER_EXTRACT` | A commercial register excerpt or similar document. | | `FOUNDATION_DOCUMENT` | The foundation document of a company or business. | | `SCHUFA_COMPACT_REPORT` | A compact SCHUFA report. | | `SCHUFA_GWG_REPORT` | A GWG (Money Laundering Act) 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 shareholder agreement. | | `SHAREHOLDERS_LIST` | A list of shareholders. | | `TRADING_LICENSE` | A trading license. | | `TRANSPARENCY_REGISTER_EXTRACT` | An extract from the 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 have been generated. Redirect the customer to the URL to complete the identification. | | `pending_failed` | The identification is currently under review by the provider. You **cannot** offer banking services to the customer at this stage. | | `successful` | The video identification was successful. The customer can be onboarded. Note that the customer's data might have been updated during the identification session. | | `aborted` | The customer aborted the identification process. They can retry using the same URL. | | `canceled` | The provider canceled the video identification. The customer should retry using the same URL. | | `failed` | The identification was unsuccessful. You **cannot** onboard the customer or offer any banking services to them. | | `expired` | The identification link has expired (validity period passed). You must create a new identification request. | IDnow provides a reason whenever the identification has a `canceled` or `aborted` status. No reason is disclosed for the final `failed` status.