Payment initiation request

This method is used to initiate a payment at the ASPSP.

Variants of payment initiation requests

There are the following payment products:

  • Payment products with payment information in JSON format:
    • aspsp
    • domestic
    • foreign

Furthermore the request body depends on the payment-service:

  • payments: A single payment initiation request.
  • bulk-payments (NOT IMPLEMENTED YET): A collection of several payment initiation requests.
  • periodic-payments (NOT IMPLEMENTED YET):
    Create a standing order initiation resource for recurrent i.e. periodic payments addressable under {paymentId}
    with all data relevant for the corresponding payment product and the execution of the standing order contained in a JSON body.

This is the first step in the API to initiate the related recurring/periodic payment.

Single and mulitilevel SCA Processes

The payment initiation requests are independent from the need of one or multilevel
SCA processing, i.e. independent from the number of authorisations needed for the execution of payments.

But the response messages are specific to either one SCA processing or multilevel SCA processing.

For payment initiation with multilevel SCA, this specification requires an explicit start of the authorisation,
i.e. links directly associated with SCA processing like 'scaRedirect' or 'scaOAuth' cannot be contained in the
response message of a Payment Initation Request for a payment, where multiple authorisations are needed.
Also if any data is needed for the next action, like selecting an SCA method is not supported in the response,
since all starts of the multiple authorisations are fully equal.
In these cases, first an authorisation sub-resource has to be generated following the 'startAuthorisation' link.

Recent Requests
Log in to see full request history
TimeStatusUser Agent
Retrieving recent requests…
LoadingLoading…
Path Params
string
enum
required

Payment service:

Possible values are:

  • payments
  • bulk-payments (not implemented yet)
  • periodic-payments (not implemented yet)
Allowed:
string
enum
required

The following payment products are supported:

  • aspsp
  • domestic
  • foreign
Allowed:
Body Params

JSON request body for a payment inition request message.

There are the following payment-products supported:

  • "aspsp" with JSON-Body
  • "domestic" with JSON-Body
  • "foreign" with JSON-Body

There are the following payment-services supported:

  • "payments"
  • "periodic-payments (NOT IMPLEMENTED YET)"
  • "bulk-paments (NOT IMPLEMENTED YET)"

All optional, conditional and predefined but not yet used fields are defined.

Generic Body for a payment initation via JSON.

This generic JSON body can be used to represent valid payment initiations for the following JSON based payment product, which where defined in the Implementation Guidelines:

  • aspsp
  • domestic
  • foreign

For the convenience of the implementer additional which are already predefinded in the Implementation Guidelines are included (but commented in source code), such that an ASPSP may add them easily.

Take care: Since the format is intended to fit for all payment products there are additional conditions which are NOT covered by this specification. Please check the Implementation Guidelines for detailes.

The following data element are depending on the actual payment product available (in source code):

optional
Data ElementSCT EU CoreSCT INST EU CoreTarget2 Paym. CoreCross Border CT Core
endToEndIdentification optional optional optional n.a.
instructionIdentification n.a. n.a. n.a. n.a.
debtorName n.a. n.a. n.a. n.a.
debtorAccount mandatory mandatory mandatory mandatory
debtorId n.a. n.a. n.a. n.a.
ultimateDebtor n.a. n.a. n.a. n.a.
instructedAmount mandatory mandatory mandatory mandatory
transactionCurrency n.a. n.a. n.a. n.a.
exchangeRateInformation n.a. n.a.n.a. n.a.
creditorAccount mandatory mandatory mandatory mandatory
creditorAgent optional optional optional conditional
creditorAgentName n.a. n.a. n.a. n.a.
creditorName mandatory mandatory mandatory mandatory
creditorId n.a. n.a. n.a. n.a.
creditorAddress optional optional conditional
creditorNameAndAddress n.a. n.a. n.a. n.a.
ultimateCreditor n.a. n.a. n.a. n.a.
purposeCode n.a. n.a. n.a. n.a.
chargeBearer n.a. n.a. optional conditional
remittanceInformationUnstructured optional optional optional optional
remittanceInformationUnstructuredArray n.a. n.a. n.a. n.a.
remittanceInformationStructured n.a. n.a. n.a. n.a.
remittanceInformationStructuredArray n.a. n.a. n.a. n.a.
requestedExecutionDate n.a. n.a. n.a. n.a.
requestedExecutionTime n.a. n.a. n.a. n.a.

IMPORTANT: In this API definition the following holds:

  • All data elements mentioned above are defined, but some of them are commented, i.e. they are only visible in the source code and can be used by uncommenting them.
  • Data elements which are mandatory in the table above for all payment products are set to be mandatory in this specification.
  • Data elements which are indicated in the table above as n.a. for all payment products are commented in the source code.
  • Data elements which are indicated to be option, conditional or mandatory for at least one payment product in the table above are set to be optional in the s specification except the case where all are definde to be mandatory.
  • Data element which are inticated to be n.a. can be used by the ASPS if needed. In this case uncomment tthe the relatetd lines in the source code.
  • If one uses this data types for some payment products he has to ensure that the used data type is valid according to the underlying payment product, e.g. by some appropriate validations.
string
length ≤ 35
debtorAccount
object
required

Reference to an account by either

  • IBAN, of a payment accounts, or
  • BBAN, for payment accounts if there is no IBAN, or
  • the Primary Account Number (PAN) of a card, can be tokenised by the ASPSP due to PCI DSS requirements, or
  • the Primary Account Number (PAN) of a card in a masked form, or
  • an alias to access a payment account via a registered mobile phone number (MSISDN).
instructedAmount
object
required
creditorAccount
object
required

Reference to an account by either

  • IBAN, of a payment accounts, or
  • BBAN, for payment accounts if there is no IBAN, or
  • the Primary Account Number (PAN) of a card, can be tokenised by the ASPSP due to PCI DSS requirements, or
  • the Primary Account Number (PAN) of a card in a masked form, or
  • an alias to access a payment account via a registered mobile phone number (MSISDN).
string

BICFI

string
length ≤ 70

Creditor agent name.

string
required
length ≤ 70

Creditor name.

creditorAddress
object
string
length ≤ 140

Unstructured remittance information.

Headers
uuid
required

ID of the request, unique to the call, as determined by the initiating party.

string

Is contained if and only if the "Signature" element is contained in the header of the request.

string

A signature of the request by the TPP on application level. This might be mandated by ASPSP.

string

The certificate used for signing the request, in base64 encoding.
Must be contained if a signature is contained.

string

Client ID of the PSU in the ASPSP client interface.

Might be mandated in the ASPSP's documentation.

It might be contained even if an OAuth2 based authentication was performed in a pre-step or an OAuth2 based SCA was performed in an preceding
AIS service in the same session.
In this case the ASPSP might check whether PSU-ID and token match,
according to ASPSP documentation.

string

Type of the PSU-ID, needed in scenarios where PSUs have several PSU-IDs as access possibility.

In this case, the mean and use are then defined in the ASPSP’s documentation.

string

Might be mandated in the ASPSP's documentation. Only used in a corporate context.

string

Might be mandated in the ASPSP's documentation. Only used in a corporate context.

string
string
required

The forwarded IP Address header field consists of the corresponding http request IP Address field between PSU and TPP.
If not available, the TPP shall use the IP Address used by the TPP when submitting this request.

boolean

If it equals "true", the TPP prefers a redirect over an embedded SCA approach.
If it equals "false", the TPP prefers not to be redirected for SCA. The ASPSP will then choose between the Embedded or the Decoupled
SCA approach, depending on the parameter TPP-Decoupled-Preferred and the choice of the SCA procedure by the TPP/PSU.
If the parameter is not used, the ASPSP will choose the SCA approach to be applied depending on the SCA method chosen by the
TPP/PSU.

boolean

If it equals "true", the TPP prefers a decoupled SCA approach.
If it equals "false", the TPP prefers not to use the decoupled approach for SCA. The ASPSP will then choose between the embedded or the redirect SCA approach, depending on the choice of the SCA procedure by the TPP/PSU.
If the parameter is not used, the ASPSP will choose the SCA approach to be applied depending on the parameter TPP-Redirect-Preferred and the SCA method chosen by the TPP/PSU.
The parameter might be ignored by the ASPSP.
If both parameters TPP-Redirect-Preferred and TPP-Decoupled-Preferred are present and true, the request is still not rejected, but it is up to the ASPSP, which approach will actually be used.

Remark for Future:
TPP-Redirect-Preferred and TPP-Decoupled-Preferred will be revised in future versions, maybe merged. Currently kept separate for downward compatibility.

uri

URI of the TPP, where the transaction flow shall be redirected to after a Redirect.

Mandated for the Redirect SCA Approach, specifically
when TPP-Redirect-Preferred equals "true".
It is recommended to always use this header field.

Remark for Future:
This field might be changed to mandatory in the next version of the specification.

uri

If this URI is contained, the TPP is asking to redirect the transaction flow to this address instead of the TPP-Redirect-URI in case
of a negative result of the redirect SCA method. This might be ignored by the ASPSP.

boolean

If it equals "true", the TPP prefers to start the authorisation process separately,
e.g. because of the usage of a signing basket.
This preference might be ignored by the ASPSP, if a signing basket is not supported as functionality.

If it equals "false" or if the parameter is not used, there is no preference of the TPP.
This especially indicates that the TPP assumes a direct authorisation of the transaction in the next step,
without using a signing basket.

boolean

If it equals "true" then the TPP prefers a rejection of the payment initiation in case the ASPSP is
providing an integrated confirmation of funds request an the result of this is that not sufficient
funds are available.

If it equals "false" then the TPP prefers that the ASPSP is dealing with the payment initiation like
in the ASPSPs online channel, potentially waiting for a certain time period for funds to arrive to initiate the payment.

This parameter might be ignored by the ASPSP.

string

The forwarded IP Accept header fields consist of the corresponding HTTP request Accept header fields between PSU and TPP, if available.

string

The forwarded Agent header field of the HTTP request between PSU and TPP, if available.

string
enum

HTTP method used at the PSU ? TPP interface, if available.
Valid values are:

  • GET
  • POST
  • PUT
  • PATCH
  • DELETE
Allowed:
uuid

UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available.
UUID identifies either a device or a device dependant application installation.
In case of an installation identification this ID needs to be unaltered until removal from device.

string

The forwarded Geo Location of the corresponding http request between PSU and TPP if available.

string
enum
Defaults to application/json

Generated from available response content types

Allowed:
Responses

Language
Credentials
Bearer
LoadingLoading…
Response
Click Try It! to start a request and see the response here! Or choose an example:
application/json
application/problem+json
*/*