Overview

Spectre Payments API aims to make payments providers as simple as a cURL.

Integrations

The Salt Edge platform is incredibly easy to integrate with. We’ve built the Salt Edge Connect interface so your application could start executing payments.

Formats

We use JSON for all the requests and responses, including the errors.

Glossary

Most of the API revolves around several important concepts:

• Customer - a customer of the client who is consuming Payment Initiation API;
• Provider - a bank or an online payments system;
• Payment - a payment that was made using Salt Edge API

Quick Start

Before we proceed, make sure that you have a Spectre Client account (you can register at https://www.saltedge.com/client_users/sign_up).

Any request to Payment Initiation API is authenticated, so before we are able to fetch any data we need to create API keys. To do that, visit https://www.saltedge.com/keys_and_secrets and create a “Service” API key. You can leave “Public key” field blank.

Providers that support payments require a provider key in order to be used. To create one, visit https://www.saltedge.com/clients/client_provider_keys.

Note that only providers that have Payment Templates available support payments.

Each request to API is authenticated with an App-id, and a Secret. Let’s store them as environment variables so that all the later requests are authenticated.

$ export APP_ID=YOUR_APP_ID

$ export SECRET=YOUR_APP_SECRET

Create customer

Before we can create any payments, we need to create a Customer. A Customer in Payment Initiation API is the end-user of your application.

We need to save the Customer id (in this case “111”), because we will use it later to create payments.

See customers reference for Customer related API endpoints.

Choose provider

First we need to choose provider that supports payments and has client provider keys. We need to execute a request.

The response will be a list of providers that support payments.

Each payments provider can support multiple ways of initiating a payment. Each of this method is called a payment_template. We can see from the response that provider fake_client_xf supports payment templates SEPA, FPS and SWIFT.

Choose payment template

Since in previous steps we only added client keys for provider fake_client_xf, we can only execute payments using payment templates supported by this providers - SEPA, FPS, and SWIFT.

For the purposes of this guide, let’s stick with SEPA. We need to save the payment template identifier (in this case SEPA), because we will use it later.

$ export PAYMENT_TEMPLATE=SEPA

To get the payment_template’s fields we need to execute the following request.

The response will be a payment template object with payment fields.

From the response, we can see that payment template SEPA requires the following fields (none of them have optional flag set to true):

• end_to_end_id
• customer_last_logged_at
• customer_ip_address
• customer_device_os
• creditor_name
• creditor_street_name
• creditor_building_number
• creditor_country_code
• currency_code
• amount
• description
• creditor_iban

The data type for each of these fields is represented by the nature field.

Initiate payment

To initiate a payment in Salt Edge Connect, we need to execute a request to create payment using connect endpoint.

The response will contain the connect_url. This is the url we will visit to authorize the user and initiate the payment.

Visit connect url

Visit the connect_url from the previous API response. We will be presented with a form for user credentials input. Put “fake” in search and choose Fake Bank:

Input username and secret as per the on-screen instructions and press “PAY”.

After that, we will see the consent window.

After confirming, it will try to initiate the payment.

In case the provider has interactive fields, a form will be presented for filling these fields.

After that we will have to wait for the payment process to finish.

Salt Edge Connect

The most simple and easiest way to execute payments in Salt Edge API is to use Salt Edge Connect. Salt Edge Connect is a web page that handles all the user interaction during a payment initiation process:

• user credentials input
• interactive confirmation
• progress reporting
• error reporting

After your application has received an url for executing a payment using Salt Edge Connect, you can redirect your user to it. There, they will see a screen that lets them pick a provider to execute a payment.

Your user will also be asked to input their credentials and, if needed, any of the interactive credentials. After the process is done, the user will be redirected back to your application url, or to an url specified as return_to argument to create payment api endpoint.

You can easily test Connect from your Dashboard page by pressing Create Payment button or by using the create payment API endpoint.

Embedding connect in your application

At the moment, the only way to embed Salt Edge Connect in your application is to open it in a popup. When opening it in a popup using window.open, it will post notifications during the payment process. To enable, these notifications, when you request an url for executing payments, you can pass an optional argument javascript_callback_type with value post_message.

This tells Salt Edge connect to use postMessage to send messages to parent window. You can then subscribe to those message by calling window.addEventListener("message", callback) in the parent window.

Callbacks

The most important parts of Payment Initiation API (e.g. Payment initiation) are asynchronous.

Every Web application has to provide a set of valid URLs which we will use to notify about the payment progress. Other applications can poll Payment Initiation API in order to retrieve the current payment status.

There are several common points about the request we send to the callback URLs provided by the client:

• The Content-Type header is application/json;
• There is a Signature header that identifies the request was signed by Payment Initiation API;
• The request method is always POST;
• The JSON object sent will always have a data field;
• The meta field will display the version of the callbacks API.

You can set the callback URLs for your application by accessing your Payment Initiation tab on the callbacks page.

Due to security reasons, the callbacks can be sent to ports 80/HTTP (in test and pending modes) and 443/HTTPS (in test, pending and live modes) only!
Also, the callbacks not follow redirects!

Signature

In order for the client to identify that the request is coming from Payment Initiation API, there is a Signature header in the request.

Signature - base64 encoded SHA256 signature of the string represented in the form callback_url|post_body - 2 parameters concatenated with a vertical bar |, signed with a Payment Initiation API’s private key. You can find the version of the signature key used to sign the callback in the Signature-key-version header. The current version is 4.0 which corresponds to the following public key:

  -----BEGIN PUBLIC KEY-----
  MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzi1XL1b0XwUYVHj7/AR6
  Hr0YN34wH/bDOIub0nwt0s/s3tD+DPxNB85xpMEZrLikPW5PAKkQ/oC3OyPYxKOb
  8TNhzGmQhEfyCkbdRwxNZqRMRwuOc+N4sdBtQKPN8+XF3RIcRZAk25JGROtb1M2o
  d/Nb9QqdQwMjdk6W+Vdq5Sj25Tj2efJc8zmBJkNXR4WtW45p4XSdjSEjuVCSZjOy
  +N8/Od8MGixC99jYbiKm3RrVDJCgDi4YYnNRI0QgxZRpJKbQX/WeZiYOrbctG3m8
  l1/Hpkv3w1QHz/YFIshCOKwUL+xg1hLMaW4IH7XFHenE+JlUKdCqhcWyi7oIDkyr
  7wIDAQAB
  -----END PUBLIC KEY-----

An example of the string that is to be used to generate the signature looks as follows:

https://www.client.com/api/payments/callbacks/success|{"data":{"payment_id":"1234","customer_id":"4321","custom_fields":{},"status": "processing"},"meta":{"version":"1","time":"2017-01-03T13:00:28Z"}}

The pseudocode that we use to generate the signature looks like this:

base64(sha256_signature(private_key, "callback_url|post_body"))

Success

We send a callback to your application’s success URL whenever an operation has caused a change in the data we store for a particular payment.

For instance, after you’ve redirected your user to the Connect page and they have selected their provider, gave their consent and pressed Pay, we’ll send you a success callback. This callback will contain the customer identifier, the ID of the newly created payment and its status. Afterwards, your application will be able to use the show payment route and query the information about this payment.

Whenever we have more information about the payment, we will send another success callback.

A success callback marks a change in the data and you can generally expect from one to three success callbacks with the same payload within several minutes. We recommend that your application fetch the full payment data at each callback, as some information might change during the fetching process.

For instance, when your user has initiated a payment using Salt Edge Connect, we will send the following success callback:

{
  "data": {
    "payment_id": "123",
    "customer_id": "34445",
    "custom_fields": { "key": "value" },
    "status": "processing"
  },
  "meta": {
    "version": "1",
    "time": "2020-01-17T12:44:21.536Z"
  }
}

You can now use the show payment route and obtain the provider and some other attributes of the new payment.

Failure

Sometimes a payment will fail to go through. It might happen because the interactive data was not sent by the user, provider access was not granted or we could not perform one of the steps of the payment process. In this case, you will receive a fail callback, containing a JSON similar to the following:

{
  "data": {
    "payment_id": "123",
    "customer_id": "34445",
    "custom_fields": { "key": "value" },
    "status": "rejected",
    "error_class": "ProviderAccessNotGranted",
    "error_message": "Provider access was not granted"
  },
  "meta": {
    "version": "1",
    "time": "2020-01-17T12:44:21.538Z"
  }
}

After you get this callback, you need to request the payment to check for its updates. Please note that even if there’s an error, we still store the payment.

Notify

After a new payment was created in the payment initialization process, Salt Edge can inform you about the progress the payment is going through using a Notify callback.

Your app can expect the notify callback several times, but you can use this information to inform your user about what’s happening with their payment.

The possible stages sent in a notify callback are described here.

Note that for some of the payments, you might not receive all the stages.

Here’s an example callback sent to the /notify route of your app:

{
  "data": {
    "payment_id": "123",
    "customer_id": "34445",
    "custom_fields": { "key": "value" },
    "stage": "submission",
    "stage_id": "123",
    "status": "processing"
  },
  "meta": {
    "version": "1",
    "time": "2020-01-16T12:44:21Z"
  }
}

Interactive

Some of the providers require an additional step in the payment initialization process, asking users to input an SMS, Token, solve a CAPTCHA, etc.

Whenever we encounter that the payment initialization process requires an interactive step, we will send the interactive callback to the interactive route set in your app’s profile. Your app should prompt the user for the interactive credentials and send them to the interactive route.

We also send a snippet of HTML so that it would be easier for your app to display the CAPTCHA or image to the user. If the provider requires filling a CAPTCHA, the img tag in the HTML will contain the image URL.

During this process, the payment’s stage will be set to interactive.

The interactive callback should contain the values of the interactive_credentials field from the corresponding provider.

Here’s an example callback sent to your app’s /interactive route:

{
  "data": {
    "payment_id": "123",
    "customer_id": "34445",
    "status": "processing",
    "html": "<div id='interactive'><img src='https://docs.saltedge.com/images/saltedge_captcha.png' width='10' height='10' alt='some description' title='some description'></div>",
    "stage": "interactive",
    "stage_id": "124",
    "session_expires_at": "2020-01-16T13:44:21Z",
    "interactive_fields_names": ["image"],
    "custom_fields": { "key": "value" }
  },
  "meta": {
    "version": "4",
    "time": "2020-01-16T12:44:21Z"
  }
}

Interactive redirect

There are some OAuth providers require 2 redirects for payment authorization. In these cases, for the 2nd redirect Salt Edge will send an interactive callback with redirect_url field:

{
  "data": {
    "payment_id": "123",
    "customer_id": "34445",
    "status": "processing",
    "html": "",
    "redirect_url": "https://bank.com/authorize"
    "stage": "interactive",
    "stage_id": "125",
    "session_expires_at": "2020-01-16T13:44:21Z",
    "interactive_fields_names": [],
    "custom_fields": { "key": "value" }
  },
  "meta": {
    "version": "4",
    "time": "2020-01-16T12:44:21Z"
  }
}

In these cases, your application should redirect the user to redirect_url field value of the interactive callback payload. Once the end-user will be authorized on the provider’s side, they will be redirected to the return_to url indicated in the initiate payment request, with a bunch of parameters appended to it by the provider that are needed for authorizing the payment. Those parameters need to be sent to the payments confirm route as query_string field.

Errors

The API can return multiple errors for any operation, each having its meaning and usage.

Error attributes

error_class

string

the class of the error, one of the listed below

error_message

string

a message describing the error

request

object

the body of the request that caused the error

error_class

string

the class of the error, one of the listed below

error_message

string

a message describing the error

request

object

the body of the request that caused the error

List

ApiKeyNotFound

the API key with the provided App-id and Secret does not exist or is inactive

AppIdNotProvided

The App-id was not provided in request headers

ClientDisabled

The client has been disabled. You can find out more about the disabled status on Disabled guides page

ClientNotFound

The API key used in the request does not belong to a client

ClientPending

The client is pending approval. You can find out more about the pending status on Pending guides page

ClientRestricted

The client is in the Restricted state. You can find out more about the restricted status on Restricted guides page

ConnectionFailed

Some network errors appear while fetching data

ConnectionLost

Internet connection was lost in the process

CountryNotFound

Sending a country_code that is not present in our system

CustomerNotFound

A customer with such customer_id could not be found

CustomerLocked

Customer is locked

CustomFieldsSizeTooBig

The custom_fields object has more than 1 KB

CustomFieldsFormatInvalid

The custom_fields field is not of type object

DateFormatInvalid

We have received an invalid Date format

DateOutOfRange

Sending a date value that does not fit in admissible range

DuplicatedCustomer

The customer you are trying to create already exists

EmailInvalid

The email is invalid

ExpiresAtInvalid

The Expires-at header is invalid, or is set to more than 1 hour from now in UTC

IdentifierInvalid

Invalid identifier sent for identifying the customer

InteractiveTimeout

It took too long to respond to the interactive question

InternalServerError

An internal error has occured

InvalidCredentials

The customer tried to initiate a payment with invalid credentials

InvalidEncoding

Invalid JSON encoded values

InvalidInteractiveCredentials

Interactive credentials that were sent are wrong

InvalidPaymentAttributes

Invalid payment attributes

JsonParseError

We have received some other request format instead of JSON, or the body could not be parsed

MissingExpiresAt

The Expires-at field is missing in the headers

MissingSignature

The Signature field is missing in the headers

PaymentFailed

Failed to create the payment

PaymentNotFound

Payment was not found

PaymentNotFinished

Payment not finished

PaymentTemplateNotFound

Payment template was not found

PaymentTemplateNotSupported

The chosen provider does not support the desired payment template

PaymentAlreadyStarted

Payment already started

PaymentAlreadyFinished

Payment already finished

PaymentAlreadyAuthorized

Payment already authorized

PaymentInitiationTimeout

Payment initiation timeout

ProviderAccessNotGranted

The customer denied access to his data from the provider’s page

ProviderDisabled

The accessed provider is disabled

ProviderError

There’s an error on the provider’s side which obstructs us from obtaining initiating the payment

ProviderInactive

The accessed provider is inactive at the moment

ProviderNotFound

Sending a provider_code that is not present in our system

ProviderKeyFound

The chosen provider does not have provider keys

ProviderNotInteractive

The payment’s provider has no interactive step

ProviderUnavailable

The provider is temporary unavailable

PublicKeyNotProvided

The client did not provide the public key in his account information

RateLimitExceeded

Too many logins are being processed at the same time from one application

RequestExpired

The request has expired, took longer than mentioned in the Expires-at header

ReturnURLInvalid

The return_to URL is invalid

ReturnURLTooLong

The return_to URL exceeds 2040 characters

RouteNotFound

The action you are trying to access deos not exist

SecretNotProvided

The Secret was not provided in request headers

SignatureNotMatch

The Signature header does not match with the correct one

TooManyRequests

Too many requests have occured for initiating payments from one IP address in a small period of time

ValueOutOfRange

Sending a value (e.g. id) which exceeds integer limit

WrongProviderMode

We do not support the received provider_mode

WrongRequestFormat

The JSON request is incorrectly formed

ApiKeyNotFound

the API key with the provided App-id and Secret does not exist or is inactive

AppIdNotProvided

The App-id was not provided in request headers

ClientDisabled

The client has been disabled. You can find out more about the disabled status on Disabled guides page

ClientNotFound

The API key used in the request does not belong to a client

ClientPending

The client is pending approval. You can find out more about the pending status on Pending guides page

ClientRestricted

The client is in the Restricted state. You can find out more about the restricted status on Restricted guides page

ConnectionFailed

Some network errors appear while fetching data

ConnectionLost

Internet connection was lost in the process

CountryNotFound

Sending a country_code that is not present in our system

CustomerNotFound

A customer with such customer_id could not be found

CustomerLocked

Customer is locked

CustomFieldsSizeTooBig

The custom_fields object has more than 1 KB

CustomFieldsFormatInvalid

The custom_fields field is not of type object

DateFormatInvalid

We have received an invalid Date format

DateOutOfRange

Sending a date value that does not fit in admissible range

DuplicatedCustomer

The customer you are trying to create already exists

EmailInvalid

The email is invalid

ExpiresAtInvalid

The Expires-at header is invalid, or is set to more than 1 hour from now in UTC

IdentifierInvalid

Invalid identifier sent for identifying the customer

InteractiveTimeout

It took too long to respond to the interactive question

InternalServerError

An internal error has occured

InvalidCredentials

The customer tried to initiate a payment with invalid credentials

InvalidEncoding

Invalid JSON encoded values

InvalidInteractiveCredentials

Interactive credentials that were sent are wrong

InvalidPaymentAttributes

Invalid payment attributes

JsonParseError

We have received some other request format instead of JSON, or the body could not be parsed

MissingExpiresAt

The Expires-at field is missing in the headers

MissingSignature

The Signature field is missing in the headers

PaymentFailed

Failed to create the payment

PaymentNotFound

Payment was not found

PaymentNotFinished

Payment not finished

PaymentTemplateNotFound

Payment template was not found

PaymentTemplateNotSupported

The chosen provider does not support the desired payment template

PaymentAlreadyStarted

Payment already started

PaymentAlreadyFinished

Payment already finished

PaymentAlreadyAuthorized

Payment already authorized

PaymentInitiationTimeout

Payment initiation timeout

ProviderAccessNotGranted

The customer denied access to his data from the provider’s page

ProviderDisabled

The accessed provider is disabled

ProviderError

There’s an error on the provider’s side which obstructs us from obtaining initiating the payment

ProviderInactive

The accessed provider is inactive at the moment

ProviderNotFound

Sending a provider_code that is not present in our system

ProviderKeyFound

The chosen provider does not have provider keys

ProviderNotInteractive

The payment’s provider has no interactive step

ProviderUnavailable

The provider is temporary unavailable

PublicKeyNotProvided

The client did not provide the public key in his account information

RateLimitExceeded

Too many logins are being processed at the same time from one application

RequestExpired

The request has expired, took longer than mentioned in the Expires-at header

ReturnURLInvalid

The return_to URL is invalid

ReturnURLTooLong

The return_to URL exceeds 2040 characters

RouteNotFound

The action you are trying to access deos not exist

SecretNotProvided

The Secret was not provided in request headers

SignatureNotMatch

The Signature header does not match with the correct one

TooManyRequests

Too many requests have occured for initiating payments from one IP address in a small period of time

ValueOutOfRange

Sending a value (e.g. id) which exceeds integer limit

WrongProviderMode

We do not support the received provider_mode

WrongRequestFormat

The JSON request is incorrectly formed

Pay with Connect

The easiest way to initiate payments using Salt Edge API is to use Salt Edge Connect, which handles all the authentication interaction with the user. After you will execute the request you will receive a connect_url field, which you need to redirect the user to in order to process with the payment flow.

Please see the sequence diagram for details on how to handle payments via Connect.

Parameters

customer_id

string, required

the ID of the customer received from customer create

provider_code

string, optional

the code of the desired provider. To access the list of providers that support payments, see providers list. If passed, make sure the chosen provider supports the desired payment template

payment_attributes

object, required

all attributes (required and optional) that are needed for a successful payment initiation received in show templates

template_identifier

string, required

payment template identifier received in show templates

payee_description

string, required

short description of the payment’s target (ex: company name, payee full name)

return_to

string, optional

the URL the user will be redirected to, defaults to client’s home URL

show_consent_confirmation

boolean, optional

if sent as false, upon submitting the form, the user will not be asked to give his consent to Salt Edge Inc. Default value: true.

disable_provider_search

boolean, optional

if sent as true, together with provider_code, does not allow the user to change the preselected provider

javascript_callback_type

string, optional

allows you to specify what kind of callback type you are expecting. Possible values: post_message. Defaults to null, which means that you will not receive any callbacks.

customer_id

string, required

the ID of the customer received from customer create

provider_code

string, optional

the code of the desired provider. To access the list of providers that support payments, see providers list. If passed, make sure the chosen provider supports the desired payment template

payment_attributes

object, required

all attributes (required and optional) that are needed for a successful payment initiation received in show templates

template_identifier

string, required

payment template identifier received in show templates

payee_description

string, required

short description of the payment’s target (ex: company name, payee full name)

return_to

string, optional

the URL the user will be redirected to, defaults to client’s home URL

show_consent_confirmation

boolean, optional

if sent as false, upon submitting the form, the user will not be asked to give his consent to Salt Edge Inc. Default value: true.

disable_provider_search

boolean, optional

if sent as true, together with provider_code, does not allow the user to change the preselected provider

javascript_callback_type

string, optional

allows you to specify what kind of callback type you are expecting. Possible values: post_message. Defaults to null, which means that you will not receive any callbacks.

Possible Errors

• ClientDisabled
• ClientNotFound
• ClientRestricted
• CustomerLocked
• CustomerNotFound
• InvalidPaymentAttributes
• JsonParseError
• PaymentTemplateNotFound
• PaymentTemplateNotSupported
• ProviderDisabled
• ProviderInactive
• ProviderNotFound
• WrongRequestFormat

Pay with Direct API

If you wish to handle the credentials, consent and authorization for payments yourself, you can create payments directly via the API. Your app will have to pass the user’s values of provider’s fields within the payload in the credentials object. Please note that you still have to use redirects (see OAuth in all cases when provider mode is oauth.

The credentials object should be modeled after the provider’s fields. For instance, if the provider’s required fields contain a field with the value of name equal to username, the credential object should contain a username attribute with the value being the actual username.

For example, here’s a provider:

{
  "data": {
    "code": "bigbank_us",
    "required_fields": [
      {
        "english_name": "Pass Code",
        "localized_name": "Pass Code",
        "name": "code",
        "nature": "text",
        "position": 1
      }
    ]
  }
}

The user should be prompted to input their Pass Code. If they input their Pass Code (in this case, the user has input “hunter2”), your app should send the following data in the credentials object:

{
  "code": "hunter2"
}

Here’s another example that includes a select:

{
  "data": {
    "code": "anotherbank_us",
    "required_fields": [
      {
        "english_name": "Password",
        "localized_name": "Password",
        "name": "password",
        "nature": "password",
        "position": 1
      },
      {
        "nature":         "select",
        "name":           "image",
        "english_name":   "Image",
        "localized_name": "Imagine",
        "position":       2,
        "optional":       false,
        "field_options": [
          {
            "name":           "1",
            "english_name":   "Home",
            "localized_name": "Casa",
            "option_value":   "home",
            "selected":       false
          },
          {
            "name":           "2",
            "english_name":   "Car",
            "localized_name": "Automobil",
            "option_value":   "car",
            "selected":       false
          }
        ]
      }
    ]
  }
}

In this case, your app should prompt the user to input their Password and offer them a select with the options of “Casa” and “Automobil” (the localized_name or english_name values, depending on your service). The credentials should contain the name of the select field (in this case image) as the key and the user’s selected option_value as its value. Let’s say the user has input hunter2 as their password and has chosen “Automobil” from the select.

The credentials object should look like this:

{
  "password": "hunter2",
  "image": "car"
}

Payments workflow does not currently support encrypted credentials.

Parameters

customer_id

string, required

the ID of the customer received from customer create

provider_code

string, required

the code of the desired provider. To access the list of providers that support payments, see providers list

credentials

object, required

the credentials required to initiate the payment

payment_attributes

object, required

all attributes (required and optional) that are needed for a successful payment initiation received in show templates

template_identifier

string, required

payment template identifier received in show templates

custom_fields

object, optional

a JSON object, which will be sent back on any of your callbacks

customer_id

string, required

the ID of the customer received from customer create

provider_code

string, required

the code of the desired provider. To access the list of providers that support payments, see providers list

credentials

object, required

the credentials required to initiate the payment

payment_attributes

object, required

all attributes (required and optional) that are needed for a successful payment initiation received in show templates

template_identifier

string, required

payment template identifier received in show templates

custom_fields

object, optional

a JSON object, which will be sent back on any of your callbacks

Possible Errors

• ClientDisabled
• ClientNotFound
• ClientRestricted
• CustomFieldsFormatInvalid
• CustomerLocked
• CustomerNotFound
• InvalidCredentials
• InvalidPaymentAttributes
• JsonParseError
• PaymentNotFound
• PaymentTemplateNotFound
• PaymentTemplateNotSupported
• ProviderDisabled
• ProviderInactive
• ProviderNotFound
• WrongRequestFormat

OAuth

Since initiating payments with OAuth providers implies a redirect, the flow for these providers is similar to pay with Connect. The response will contain a redirect_url and your app has to redirect the user to that URL.

The redirect_url points to a page where the user can provide PISP access to make payments, making it available for your app. After the user has approved PISP in the OAuth provider’s interface, they will be redirected to the return_to page. return_to is optional for clients only if they use a shared (owned by Salt Edge) [provider key](/general/#clientproviderkeys (it is set as the client’s home_url by default). If clients use their own provider keys, return_to is required and should be a valid url that was registered within the chosen provider.

Please see the sequence diagram for details on how to handle OAuth payments directly.

Parameters

customer_id

string, required

the ID of the customer received from customer create

provider_code

string, required

the code of the desired oauth provider. To access the list of providers that support payments, see providers list.

payment_attributes

object, required

all attributes (required and optional) that are needed for a successful payment initiation received in show templates

template_identifier

string, required

payment template identifier received in show templates

payee_description

string, required

short description of the payment’s target (ex: company name, payee full name)

return_to

string, required

the url the user will be redirected to after they authenticate on the provider’s side. If you used your own provider keys for the chosen provider, the url to which the end-user will be redirected will contain a bunch of parameters appended by the provider that you need to send to the authorize route in order to authorize the payment

customer_id

string, required

the ID of the customer received from customer create

provider_code

string, required

the code of the desired oauth provider. To access the list of providers that support payments, see providers list.

payment_attributes

object, required

all attributes (required and optional) that are needed for a successful payment initiation received in show templates

template_identifier

string, required

payment template identifier received in show templates

payee_description

string, required

short description of the payment’s target (ex: company name, payee full name)

return_to

string, required

the url the user will be redirected to after they authenticate on the provider’s side. If you used your own provider keys for the chosen provider, the url to which the end-user will be redirected will contain a bunch of parameters appended by the provider that you need to send to the authorize route in order to authorize the payment

Possible Errors

• ClientDisabled
• ClientNotFound
• ClientRestricted
• CustomerLocked
• CustomerNotFound
• InvalidPaymentAttributes
• JsonParseError
• PaymentTemplateNotFound
• PaymentTemplateNotSupported
• ProviderDisabled
• ProviderInactive
• ProviderNotFound
• WrongProviderMode
• WrongRequestFormat

Authorize

Used to authorize a payment for an OAuth provider when using client owned provider keys. In this flow, once the end-user will be authorized on the provider’s side, they will be redirected to the return_to url indicated in the previous request, with a bunch of parameters appended to it by the provider that are needed for authorizing the payment.

Examples:

<return_to url>?code=bc4521d3&state=Pd8b4d0eb
<return_to url>#code=bc4521d3&state=Pd8b4d0eb

For both cases, the query_string that is needed to authorize the payment is code=bc4521d3&state=Pd8b4d0eb.

Parameters

payment_id

string, required

the id of the payment that is being authorized

query_string

string, required

all the parameters appended to your return_to url upon being redirected from the provider back to your application

payment_id

string, required

the id of the payment that is being authorized

query_string

string, required

all the parameters appended to your return_to url upon being redirected from the provider back to your application

Possible Errors

• ClientDisabled
• ClientNotFound
• JsonParseError
• PaymentAlreadyAuthorized
• WrongRequestFormat

Confirm

If the currently processing payment requires any interactive credentials, your app should ask the user for the interactive credentials and send them to the /confirm route. After that, the process will continue as usual.

In case of dynamic_select field nature, send the option_value of the user selected options in an array:

{
  "data": {
    "interactive_fields": {
      "accounts": ["account1", "account2"]
    }
  }
}

Please note that in some cases, on interactive stage provider may not require any interactive fields (see interactive_fields_names), thus you should send an empty object in the interactive_fields field:

{
  "data": {
    "interactive_fields": {}
  }
}

In case of an interactive redirect, once the use is redirected to your return_to url, the query string appendend to your return_to should be sent to confirm route:

Examples:

<return_to url>?code=bc4521d3&state=Pd8b4d0eb
<return_to url>#code=bc4521d3&state=Pd8b4d0eb

For both cases, the query_string that is needed to authorize the payment is code=bc4521d3&state=Pd8b4d0eb.

Parameters

interactive_fields

object, required

the credentials object based on the provider’s interactive fields

interactive_fields

object, required

the credentials object based on the provider’s interactive fields

Possible Errors

• ClientDisabled
• ClientNotFound
• JsonParseError
• PaymentAlreadyFinished
• PaymentNotFound
• WrongRequestFormat

Cancel

Allows you to cancel the payment initiation. Note: payment can be canceled only being in initialize stage.

Possible Errors

• ClientDisabled
• ClientNotFound
• JsonParseError
• PaymentAlreadyFinished
• PaymentAlreadyStarted
• PaymentNotFound
• WrongRequestFormat

Providers

A provider is an Financial Institution which can execute payments. We recommend you update all of the provider’s fields at least daily.

PSD2/Open Banking Integrated Banks map will let help you to get better understanding which banks already integrated and find if your bank is supported by Salt Edge.

Attributes

id

string

provider’s id

code

string

provider’s code

name

string

provider’s name

mode

string

possible values are: oauth, api

status

string

possible values are: active, inactive, disabled

interactive

boolean

whether the provider requires interactive input

identification_mode

string

whether the request to the provider is made with your authorization headers or with Salt Edge’s. Possible values are: client, saltedge

instruction

string

instructions on how to connect the bank, in English

home_url

string

the url of the main page of the provider

forum_url

string

the url for the Salt Edge Support page, dedicated to the provider

logo_url

string

the url for the provider logo, may have a placeholder for providers with missing logos

country_code

string

code of the provider’s country

payment_templates

array of strings

identifiers of the payment templates that are supported by this provider

created_at

datetime

updated_at

datetime

id

string

provider’s id

code

string

provider’s code

name

string

provider’s name

mode

string

possible values are: oauth, api

status

string

possible values are: active, inactive, disabled

interactive

boolean

whether the provider requires interactive input

identification_mode

string

whether the request to the provider is made with your authorization headers or with Salt Edge’s. Possible values are: client, saltedge

instruction

string

instructions on how to connect the bank, in English

home_url

string

the url of the main page of the provider

forum_url

string

the url for the Salt Edge Support page, dedicated to the provider

logo_url

string

the url for the provider logo, may have a placeholder for providers with missing logos

country_code

string

code of the provider’s country

payment_templates

array of strings

identifiers of the payment templates that are supported by this provider

created_at

datetime

updated_at

datetime

Show

Provider show allows you to inspect the single provider in order to give your users a proper interface to input their credentials. The response will have an array of required_fields and interactive_fields.

Parameters

provider_code

string

provider’s code

provider_code

string

provider’s code

Possible Errors

• ClientDisabled
• ClientNotFound
• ProviderNotFound

List

Returns all the providers we operate with. If a provider becomes disabled, it is not included in the list. You can read more about the next_id field, in the pagination section of the reference.

Providers that require a client provider key will be included only if you have created provider keys for them.

Parameters

from_id

string, optional

the id of the record starting the next page, defaults to null

from_date

date, optional

filtering providers created or updated starting from this date, defaults to null

country_code

string, optional

filtering providers by country, defaults to null

mode

string, optional

filtering providers by mode, possible values are: oauth, api

include_fake_providers

boolean, optional

whether you wish to fetch the fake providers, defaults to false

template_identifier

string, optional

return only providers that support the given payment template

provider_key_owner

string, optional

filtering providers by key owner, possible values are: client, saltedge. When value is set as client, only providers with client-set keys will be returned. Please see Client Provider Keys

from_id

string, optional

the id of the record starting the next page, defaults to null

from_date

date, optional

filtering providers created or updated starting from this date, defaults to null

country_code

string, optional

filtering providers by country, defaults to null

mode

string, optional

filtering providers by mode, possible values are: oauth, api

include_fake_providers

boolean, optional

whether you wish to fetch the fake providers, defaults to false

template_identifier

string, optional

return only providers that support the given payment template

provider_key_owner

string, optional

filtering providers by key owner, possible values are: client, saltedge. When value is set as client, only providers with client-set keys will be returned. Please see Client Provider Keys

Possible Errors

• ClientDisabled
• ClientNotFound
• DateOutOfRange
• ValueOutOfRange

Fake

In order to help with testing, we provide a fake country (having the country code XF) and a set of fake providers. If your application is in the Test or Pending status, the Connect page will let you select the fake country and its providers.

The API supplies a number of fake providers:

• fake_client_xf - requires a username and password (embedded);
• fake_oauth_client_xf - asks for authorization (OAuth redirect);
• fake_interactive_client_xf - asks for a fake SMS code in addition to username and password (embedded);

Both providers require for Client Provider Keys to be set. Check the provider’s instructions in the Connect page for the appropriate credentials.

Sandboxes

We also add all sandboxes and model banks as providers to XF country. Currenly Salt Edge has the following sandboxes:

• priora_demobank_xf
• priora_demobank_sca_oauth_client_xf
• bbva_oauth_client_es_xf
• bcr_client_oauth_ro_xf
• citibank_oauth_client_sg_xf
• csas_oauth_client_cz_xf
• deutsche_bank_oauth_client_de_xf
• fineco_oauth_client_it_xf
• forgerock_client_gb_xf
• hsbc_oauth_client_gb_xf
• ing_oauth_client_ro_xf
• lloyds_oauth_client_gb_xf
• natwest_oauth_client_gb_xf
• ocbc_oauth_client_sg_xf
• ozone_client_gb_xf
• raiffeisen_oauth_client_cz_xf
• raiffeisen_oauth_client_ro_xf
• revolut_business_client_oauth_gb_xf
• revolut_client_oauth_gb_xf
• starlingbank_oauth_client_gb_xf
• tsb_oauth_client_gb_xf

Customers

A customer represents a person who will be using your application. You need to store the id returned from the response in your application, which is necessary when creating payments. We give you the following customer API actions so that the customer will be successfully identified within Salt Edge.

Create

Creates a customer, returning the customer object.

Parameters

identifier

string, required

a unique identifier of the new customer

identifier

string, required

a unique identifier of the new customer

Possible Errors

• ClientDisabled
• ClientNotFound
• DuplicatedCustomer
• JsonParseError
• WrongRequestFormat