Users and Accounts Overview

This guide provides an overview of users and accounts, two primary resources on the Solaris platform. It covers how to create and manage these resources, as well as their most common statuses and workflows.

Users and accounts at a glance

• A user is anyone who holds an account or payment card on the Solaris platform. Users are created and managed via the Consumer API .
• An account is an e-money (EMI) account that allows a user to accept and make payments in the UK and EEA without the need for a bank account. EMI accounts come with addressable account numbers, sort codes, BICs, IBANs and Bank IDs. Accounts are managed via the Account API .
• All accounts are created with an associated agreement code which specifies the terms and conditions of the account including fees, charges and limits etc.

User and account lifecycle

Creating users and accounts

Users (referred to as "Consumers") are created via the Consumer/AddConsumers method, which will create both the consumer and the respective account simultaneously.

When creating a consumer, the IsSkipKYC parameter determines which KYC journey should be used:

• If KYC is to be conducted by Solaris EMI, the partner must pass this parameter as false . This will initiate the relevant KYC checks synchronously, and there will be a delay before a response from the API as these are run.
• If KYC is being undertaken by the partner on behalf of Solaris EMI, then this must be passed as true .

Closing accounts

Accounts can be closed either via the API or by directly requesting the account closure from Solaris.

Closing accounts via the API

To successfully action a closure via the API, the account must have:

• An account balance and available balance of zero.
• No pending settlement transactions.
• No currently active sub accounts.

Provided these conditions are met, the Consumer/SetConsumerAsLockout method can be used to close the account. When successfully called:

• The consumer's status will be set to Locked Out .
• The associated account status will be set to Closed .
• Any cards associated with the account will be set to Issuer Cancelled .

Notes on closing accounts via the API:

• If you are providing customer services directly to your end users and intend to use the API for account closures, you must provide your account closure process and procedures in your Customer Service Policies, which will need to be reviewed and approved by Solaris Partner Services.
• If you intend to close a Card Program, do not use the API to close individual accounts. Card Program closure activities must be handled by Solaris.

User statuses

User related webhook notifications

• The User status change notification provides a notification when the status of a user changes.
• The User contact update notification can notify you when a user's contact information - mobile number, address or email address has been updated by Solaris.
• The User login block/unblock notification can inform you when a user has been blocked or unblocked from accessing the Solaris platform.

Accounts

Account statuses

Account related webhook notifications

• The Account Balance change notification provides a notification when the balance of an account changes.
• The Account status change notification provides details of a change in account status.
• The Authorization notification and Transaction notification provide notifications on authorizations and transactions respectively, and can be used, for example, to build a record of pending transactions for a given account.

User address data

Partners are responsible for the collection of accurate and consistently formatted address data. In order to facilitate this, Solaris' recommendation is to use a specialized third party address retrieval/validation service. This is especially pertinent for partners intending to offer physical cards, in order to mitigate against failed card delivery.

Postcode validation

Postcode validation will always be be run when calling either of the following methods:

• Consumer/AddConsumers - to create a consumer
• Consumer/UpdateConsumerContactDetails - to update a consumer's contact information

This validation logic will be run against the PresentAddress object's Postcode parameter. The validation pattern will be based on the ISO 3166-1 numeric country code value specified in the respective ISOCountryCode parameter (shown below). An incorrectly matched post code will result in an error response with error code 3486.