Payments

info

The types of payments supported on your program are dependent upon it's base currency and agreed scope.

Faster Payments (FPS)

  • Faster Payments (FPS) are GBP to GBP electronic payments that can be made from one FPS enabled account to another. These are offered on GBP programs.
  • Payments will typically arrive almost immediately (with a maximum delay of up to two hours).
  • Individual payments of up to £1 million can be made using FPS. Additional limits can however be set depending on the type of account(s) in your program.

SEPA Credit Transfers

  • SEPA (Single Euro Payments Area) is a payment integration initiative of the European Union, permitting bank transfers denominated in euros to be sent across the SEPA region as though it were a single domestic market. SEPA transfers must originate and settle in countries within the SEPA region.
  • SEPA payments are offered on EUR programs.
  • Solaris can provide partners and their users with their own International Bank Account Number (IBAN) which, along with Solaris' SEPA compliant Bank Identifier Code (UFPOLT21XXX), can be used to send and receive SEPA payments.

Payments integration at a glance

Beneficiary and Payment management

For GBP programs, beneficiaries and payments should be managed via the Confirmation of Payee flow.

Adding a beneficiary (recipient)

Before a transfer can be made, a beneficiary (recipient) to receive the transfer must first be added. Recipients are added via the Transfer/AddRecipient method. When calling this method, remember to include:

  • The recipient's name via BankAccountHolderName .
  • The correct BankAccountTypeID (UK or SEPA) of the recipient, as well as:
    • The AccountNumber and SortCode for recipients in the UK (GBP payments).
    • The IBAN and BIC for recipients in the SEPA area (EUR payments).

The response will include a RecipientBankReferenceID value which should be persisted, as it will be required when making a transfer to a recipient (see below).

Making a transfer

Once a recipient has been added, transfers can be made using the Transfer/BankTransfer method, which must include the following:

  • The RecipientBankReferenceID of the recipient.
  • The TransferTypeID to denote the type of payment, as well as:
    • The AccountNumber and SortCode for payees in the UK (GBP payments).
    • The IBAN and BIC for payees in the SEPA area (EUR payments).

Closed Loop Payments

User nominated accounts

It is the responsibility of the partner to ensure that all applicable controls and checks are in place regarding the user's selection of and amendments to nominated accounts. If you have any questions regarding this please contact Solaris.

Closed Loop Payments (CLP) provide the facility for partners to restrict the external accounts through which funds can be loaded onto, and unloaded from, your customer accounts. This is achieved by requiring users to specify "nominated" account(s) and limiting inbound and outbound payments to these accounts exclusively.

  • Closed Loop Payments are enabled by Solaris at program level. Once enabled, they apply to all user accounts on your program.
  • The maximum number of accounts a user can nominate is configurable. This limit applies similarly to all accounts on your program.
  • Closed Loop Payments currently apply only to Faster Payments and SEPA credit transfers.
  • User nominated accounts must be part of the domestic payments scheme provided in your program. For example, when implementing Closed Loop Payments for UK users, all nominated accounts must be able to send and receive Faster Payments. Similarly in the EEA, nominated accounts must be able to send/receive SEPA Credit transfers.

When Closed Loop Payments are enabled on your program, the following payment restrictions and checks will be applied:

  • Payments can be made to and received by a user via their nominated accounts only:
    • Outbound payments cannot be made from a user's account to non-nominated accounts.
    • Inbound payments to a user's account are checked to ensure they are from a nominated account. If not, the payment will be automatically returned to the sender.
  • For existing users, their current bank details will be converted into (and will constitute) one of their permitted nominated accounts.

Managing nominated accounts

Once Closed Loop Payments have been enabled and configured for your program, you can manage user-nominated accounts as below:

  • To nominate an account, use the Transfer/AddRecipient method. Please note: If the user has already nominated the maximum number of accounts permitted, this request will fail with the error code 6531 . A successful request will provide a RecipientBankReferenceId , which should be persisted for future reference.
  • To remove a nominated account, use the Transfer/DeleteRecipient method, supplying the respective RecipientBankReferenceID .
  • If changes are required to an existing nominated account, the account must first be removed (via Transfer/DeleteRecipient) and then re-added using the Transfer/AddRecipient method.

Confirmation of Payee

info

Confirmation of Payee (CoP) is currently available to verify UK based bank accounts when sending Faster Payments (FPS) and CHAPS payments.

Confirmation of Payee at a glance

Confirmation of Payee (CoP) enables users (senders) to verify the identity of a recipient (the payee) before the recipient is added and the respective payment made. This provides an additional check to better ensure the payment is going to the intended recipient. At a very high level, the CoP workflow is as follows:

  1. The user enters the recipient details - sort code, account number, account type and expected account owner name into your application.
  2. Your application calls the Solaris API, which checks these details against a directory, with the response indicating one of the following match types:
    • Positive match - the supplied details match exactly.
    • Partial (close) match - the name provided is a close match to that on the account.
    • Negative match - the name does not match that on the account.
  3. Depending on the match type received, your application directs the user through the appropriate workflow , permitting them to undertake the relevant (match dependent) actions, which may include:
    • Proceeding with adding the recipient and making the payment.
    • Cancelling the payment.
    • Amending the account details and re-trying the check.

Detailed information on all of these steps including API request and response, relevant workflows, user actions and appropriate messaging to display is outlined below.

Verifying recipients via the API

To verify the recipient details provided by the sender, call the Transfer/VerifyPayee method, passing:

  • The AccountNumber , SortCode and AccountOwnerName of the account to verify, as well as the LegalOwnerType (either "Personal" or "Business").
  • The ConsumerID of the user on behalf of whom the request is being made.

An example request is shown below:

Copy
Copied
{
    "ConsumerID": 227308,
    "AccountNumber": "00156880",
    "SortCode": "608387",
    "AccountOwnerName": "Jane Smith",
    "LegalOwnerType": "Personal"
}

Recipient verification API responses

The method response will contain the following parameters, the values of which denote the nature of the match:

  • Matched - denotes whether the provided details match exactly. Will be true for a positive match and false for either a partial (close) match, or negative match.
  • Reason denotes the reason for a partial or negative match (refer to the table below ). Always null for a positive match.
  • ReasonCode specifies the specific reason code for a partial or negative match (refer to the table below ). Always null for a positive match.
  • Name denotes the correct name of the account owner, and will only be returned in cases of a partial (close) match.

Examples of the match types are outlined below:

Positive match response

A positive match, where the details provided match those of the account exactly, is denoted by a Matched value of true:

Copy
Copied
{
    "Matched": true,
    "Name": null,
    "Reason": null,
    "MatchedBank": "FICTITIOUS BANK LIMITED",
    "ReasonCode": null,
    "ResponseWithinSla": true,
    "LegalOwnerType": "Personal",
    "ResponderRegistrationId": "100117",
    "Description": "Success",
    "ResponseCode": "000",
    "ResponseDateTime": "2024-01-30T13:36:34.342",
    "ClientRequestReference": "",
    "RequestID": 638422185943426515
}

Partial (close) match response

A partial (close) match, where the account owner name provided closely matches that of the account, is denoted by the presence of a populated Name parameter, which details the correct name of the account owner.

Copy
Copied
{
    "Matched": false,
    "Name": "Jane Smith",
    "Reason": "There may be a match on the Account name",
    "MatchedBank": "FICTITIOUS BANK LIMITED",
    "ReasonCode": "MBAM",
    "ResponseWithinSla": true,
    "LegalOwnerType": "Personal",
    "ResponderRegistrationId": "100117",
    "Description": "Success",
    "ResponseCode": "000",
    "ResponseDateTime": "2024-02-01T13:00:56.074",
    "ClientRequestReference": "",
    "RequestID": 638423892560746432
}

Negative match response

A negative match indicates the account owner name provided does not match that of the account. This is denoted by a Matched value of false and Name parameter value of null.

Copy
Copied
{
    "Matched": false,
    "Name": null,
    "Reason": "Account Name does Not Match",
    "MatchedBank": "FICTITIOUS BANK LIMITED",
    "ReasonCode": "ANNM",
    "ResponseWithinSla": true,
    "LegalOwnerType": "Personal",
    "ResponderRegistrationId": "100117",
    "Description": "Success",
    "ResponseCode": "000",
    "ResponseDateTime": "2024-01-30T13:37:22.721",
    "ClientRequestReference": "",
    "RequestID": 638422186427214187
}

Handling the verification response

Each response type (positive match, partial (close) match and negative match) need to be handled with a specific flow.

  • Positive matches, where the Matched parameter is true , must be handled via the Positive match flow .
  • Partial (close) matches, where the Name parameter is populated, must be handled with the Partial match flow .
  • All non-positive matches will contain a ReasonCode and/or Reason parameter. A full breakdown of these, along with the respective flow to handle the reason is available in the table below.

Response Reason Codes

Reason Code Reason Further Information Flow to Use
ANNM "Account Name does Not Match" Matching has returned a negative match. Negative match flow
MBAM "There may be a match on the Account Name" Matching has returned a close match. Partial match flow
BANM "Business account, name matches" The user intends to pay a personal account. The name matches, but the actual account is a business account. Partial match flow
PANM "Personal account, name matches" The user intends to pay a business account. The name matches, but the actual account is a personal account. Partial match flow
BAMM "Business account, name may be a match" The user intends to pay a personal account. The name is a close match, but the actual account is a business account. Partial match flow
PAMM "Personal account, name may be a match" The user intends to pay a business account. The name is a close match, but the actual account is a personal account. Partial match flow
AC01 "Incorrect Account Number" Account does not exist in the CoP Responder's books.

Please note. As outlined in the respective flow, the user should not be able to proceed with the payment in this scenario.
Account does not exist flow
IVCR "Invalid Customer Reference" The CoP Responder was unable to locate the user account based on the secondary reference data contained within the SecondaryIdentification field. Negative match flow
ACNS "Account type Not Supported for CoP" Can mean one of the following:
  • The recipient's account type doesn’t support CoP checks.
  • The bank the user is attempt to send the money to doesn't perform CoP checks.
  • The recipient may have switched their account to a new one.
Negative match flow
OPTO "Opted out of CoP Scheme" The intended recipient has been opted out of the CoP service. Negative match flow
CASS "Account has been switched" The recipient's account has been switched using the Current Account Switch Service (CASS). Negative match flow
SCNS "Sort code not supported at endpoint" The CoP Responder has incorrectly received a CoP request for a sort code that does not belong to them. Negative match flow
N/A "Account details could not be validated" This reason type is sent by Solaris directly and indicates an issue has prevented the account details from being verified by the CoP provider.

Please note in such cases, no ReasonCode will be populated.
Negative match flow

Confirmation of Payee Workflows

Adding Recipients

Assuming a positive match (or a match the user chooses to proceed with) the CoP flow needs to be run only once per recipient. Once added, the recipient does not need to be confirmed again, unless you choose to do so.

The key CoP workflows, including messaging and API calls are outlined below. This flow combines a number of actions in a single, user friendly journey:

  1. Verifying the recipient details.
  2. Creating and adding the recipient (for positive matches or if the user dismisses the advisory messages presented).
  3. Initiating the payment or transfer to the recipient.

Please note the below illustrates an outline only - your flows may include or require additional dialogs, confirmation screens etc.

Presenting match results to users

Non positive match payment initiation

For purposes of liability, where a positive match is not returned from the CoP check, you must record instances where the user has been presented with the relevant advisory message(s), dismissed these and continued to proceed with the payment. This recorded data may be requested from you by Solaris for auditing purposes.

  • Clear and appropriate advisory messaging must be provided to the user to indicate the nature of the CoP check match, and the paths/actions available to them.
  • In all instances, make the messaging wording clear and concise, using simple and easy to understand language. It is advised that you avoid using:
    • technical terminology or banking "jargon". For example, avoid terms such as "verify", "payee", "payer", "authorise" etc.
    • the use of T&Cs or any language regarding liability.
  • The exact wording of the user facing messages is at your discretion, Solaris will however need to view and verify the messages on all paths/flows.
  • For the various match outcomes below, example advisory messages are shown - their formatting, styling and content is for demonstration purposes only.

Positive match flow

  • The supplied account name is considered to be a match.
  • The user can now proceed to make the payment, or cancel the payment.

Example user facing message:

success

The account name is a match.

Partial (close) match flow

  • The account owner name supplied does not match that of the account, it is however a close match.
  • The correct account name will be provided to you via the Name parameter in the verification API response , and should be included in the message shown to the user.
  • At this stage the user must be able to:
    • Select the correct account name and proceed with the payment
    • Amend account details and perform another CoP check.
    • Cancel the payment.
    • Proceed with the payment using the supplied account details (including incorrect but closely matched name). If the user opts to proceed, they must actively dismiss the warning message. The second warning message must then be presented to the user.

Example user facing message: (replace "..." with the correct account name returned in the response)

Its a close match

The name you gave us is not the same as the name held on the Account. It's a close match, the name is ...

Negative match flow

  • This flow covers scenarios where the account details supplied returns a negative match, and/or other issue(s) have prevented a successful attempt to validate the account details.
  • At this stage the user must be able to:
    • Amend the account details and perform another CoP check.
    • Cancel the payment.
    • Proceed with the payment. If the user opts to proceed, they must actively dismiss the warning message. The second warning message must then be presented to the user.

Example user facing message:

No Match

The name you gave us is not the same as the name held on the Account.

Account does not exist flow

  • The account for the details supplied does not exist. Messaging to the user must make it clear the account does not exist, the user cannot continue with the payment and should check the account details with the recipient.
  • At this stage the user must be able to:
    • Cancel the payment.
    • Amend account details and perform another CoP check.

Example user facing message:

Account not found

The account details supplied do not exist. Please check details with recipient

Second Warning Message

In cases where it is not possible to verify the recipient account details, or there is no positive match for the details, the user should first be shown an initial advisory message detailing this. Users may still however opt to proceed with the payment by dismissing this message. On dismissing the initial message, you must provide a secondary warning message indicating that the funds may not be able to be recovered should the user proceed with the payment.

Example user facing message:

Do you wish to proceed?

Initiating this payment may lead to funds being sent to the wrong account and it may not be possible to recover the money.

Solaris is the brand name for the regulated entities Contis Financial Services Ltd and UAB „Finansinės paslaugos „Contis“, which are part of the Solaris Group.