Paths
/{payment-service}/{payment-product}
Payment initiation request
This method is used to initiate a payment.
{
"enum": [
"payments"
]
}{
"enum": [
"target-2-payments"
]
}ID of the request, unique to the call, as determined by the initiating party.
The forwarded IP Address header field consists of the corresponding http request IP Address field between PSU and TPP.
JSON request body for a payment inition request message
Is contained if and only if the "Signature" element is contained in the header of the request.
A signature of the request by the TPP on application level. This might be mandated by ASPSP.
The certificate used for signing the request, in base64 encoding. Must be contained if a signature is contained.
Client ID of the PSU in the ASPSP client interface. Might be mandated in the ASPSP's documentation. Is not contained if an OAuth2 based authentication was performed in a pre-step or an OAuth2 based SCA was performed in an preceeding AIS service in the same session.
Type of the PSU-ID, needed in scenarios where PSUs have several PSU-IDs as access possibility.
Might be mandated in the ASPSP's documentation. Only used in a corporate context.
Might be mandated in the ASPSP's documentation. Only used in a corporate context.
This data element may be contained, if the payment initiation transaction is part of a session, i.e. combined AIS/PIS service. This then contains the consentId of the related AIS consent, which was performed prior to this payment initiation.
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 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.
{
"enum": [
"true",
"false"
]
}URI of the TPP, where the transaction flow shall be redirected to after a Redirect.
Mandated for the Redirect SCA Approach (including OAuth2 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.
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.
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.
{
"enum": [
"true",
"false"
]
}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.
{
"enum": [
"true",
"false"
]
}The forwarded IP Port header field consists of the corresponding HTTP request IP Port field between PSU and TPP, if available.
The forwarded IP Accept header fields consist of the corresponding HTTP request Accept header fields between PSU and TPP, if available.
The forwarded IP Accept header fields consist of the corresponding HTTP request Accept header fields between PSU and TPP, if available.
The forwarded IP Accept header fields consist of the corresponding HTTP request Accept header fields between PSU and TPP, if available.
The forwarded IP Accept header fields consist of the corresponding HTTP request Accept header fields between PSU and TPP, if available.
The forwarded Agent header field of the HTTP request between PSU and TPP, if available. Examples
- Android: "Myappa/1.2 Dalvik/2.1.0 (Linux; U; Android 6.0.1; vivo 1610 Build/MMB29M)"
- iOS: "MyApp/1 iPhone5,2 iOS/10_1 CFNetwork/808.3 Darwin/16.3.0"
HTTP method used at the PSU ? TPP interface, if available. Valid values are:
- GET
- POST
- PUT
- PATCH
- DELETE
{
"enum": [
"GET",
"POST",
"PUT",
"PATCH",
"DELETE"
]
}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 need to be unaltered until removal from device.
The forwarded Geo Location of the corresponding http request between PSU and TPP if available.
{
"pattern": "GEO:-?[0-9]{1,2}\\.[0-9]{6};-?[0-9]{1,3}\\.[0-9]{6}"
}Bad Request
Unauthorized
Forbidden
Not found
Method Not Allowed
Not Acceptable
Request Timeout
Conflict
Unsuported Media Type
Too Many Requests
Internal Server Error
Service Unavailable
Definitions
Body for a target-2-payments initation via JSON.
{
"title": "paymentInitiationTarget",
"type": "object",
"required": [
"debtorAccount",
"instructedAmount",
"creditorAccount",
"creditorName"
],
"properties": {
"endToEndIdentification": {
"$ref": "#/definitions/endToEndIdentification"
},
"debtorName": {
"$ref": "#/definitions/debtorName"
},
"debtorAccount": {
"$ref": "#/definitions/accountReference"
},
"instructedAmount": {
"$ref": "#/definitions/amount"
},
"creditorAccount": {
"$ref": "#/definitions/accountReference"
},
"creditorAgent": {
"$ref": "#/definitions/bicfi"
},
"creditorName": {
"$ref": "#/definitions/creditorName"
},
"creditorAddress": {
"$ref": "#/definitions/address"
},
"chargeBearer": {
"$ref": "#/definitions/chargeBearer"
},
"remittanceInformationUnstructured": {
"$ref": "#/definitions/remittanceInformationUnstructured"
},
"requestedExecutionDate": {
"$ref": "#/definitions/requestedExecutionDate"
}
}
}
Creditor Name
{
"type": "string",
"maxLength": 70,
"example": "Creditor Name"
}
Reference as contained in the structured remittance reference structure (without the surrounding XML structure).
{
"type": "object",
"required": [
"reference"
],
"properties": {
"reference": {
"type": "string",
"maxLength": 35
},
"referenceType": {
"type": "string",
"maxLength": 35
},
"referenceIssuer": {
"type": "string",
"maxLength": 35
}
}
}
Unstructured remittance information.
{
"type": "string",
"maxLength": 140,
"example": "Ref Number Merchant"
}
{
"type": "string",
"maxLength": 35
}
{
"type": "string",
"maxLength": 70,
"example": "Debtor Name"
}
{
"type": "string",
"format": "date",
"example": "2019-10-10"
}
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).
{
"title": "accountReference",
"type": "object",
"properties": {
"iban": {
"description": "IBAN of an account",
"example": "FR7612345987650123456789014",
"type": "string",
"pattern": "[A-Z]{2,2}[0-9]{2,2}[a-zA-Z0-9]{1,30}"
},
"bban": {
"description": "Basic Bank Account Number (BBAN) Identifier\n\nThis data element can be used in the body of the Consent Request\n Message for retrieving Account access Consent from this Account. This\n data elements is used for payment Accounts which have no IBAN.\n ISO20022: Basic Bank Account Number (BBAN). \n \n Identifier used nationally by financial institutions, i.e., in individual countries, \n generally as part of a National Account Numbering Scheme(s), \n which uniquely identifies the account of a customer.",
"example": "BARC12345612345678",
"type": "string",
"pattern": "[a-zA-Z0-9]{1,30}"
},
"pan": {
"description": "Primary Account Number according to ISO/IEC 7812.",
"example": "5409050000000000",
"type": "string",
"maxLength": 35
},
"maskedPan": {
"description": "Masked Primary Account Number",
"example": "123456xxxxxx1234",
"type": "string",
"maxLength": 35
},
"msisdn": {
"description": "Mobile phone number.",
"example": "+49 170 1234567",
"type": "string",
"maxLength": 35
},
"currency": {
"description": "ISO 4217 Alpha 3 currency code",
"example": "EUR",
"type": "string",
"pattern": "[A-Z]{3}"
}
}
}
{
"title": "address",
"example": {
"street": "rue blue",
"buildingNumber": "89",
"city": "Paris",
"postalCode": "75000",
"country": "FR"
},
"type": "object",
"properties": {
"street": {
"type": "string",
"maxLength": 70
},
"buildingNumber": {
"type": "string"
},
"city": {
"type": "string"
},
"postalCode": {
"type": "string"
},
"country": {
"description": "ISO 3166 ALPHA2 country code",
"example": "SE",
"type": "string",
"pattern": "[A-Z]{2}"
}
},
"required": [
"country"
]
}
{
"title": "amount",
"example": {
"currency": "EUR",
"amount": "123"
},
"type": "object",
"properties": {
"currency": {
"description": "ISO 4217 Alpha 3 currency code",
"example": "EUR",
"type": "string",
"pattern": "[A-Z]{3}"
},
"amount": {
"description": "The amount given with fractional digits, where fractions must be compliant to the currency definition.\nUp to 14 significant figures. Negative amounts are signed by minus.\nThe decimal separator is a dot.\n\n**Example:**\nValid representations for EUR with up to two decimals are:\n\n * 1056\n * 5768.2\n * -1.50\n * 5877.78",
"example": "5877.78",
"type": "string",
"pattern": "-?[0-9]{1,14}(\\.[0-9]{1,3})?"
}
},
"required": [
"currency",
"amount"
]
}
BICFI
{
"type": "string",
"pattern": "[A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}",
"example": "AAAADEBBXXX"
}
Charge Bearer. ChargeBearerType1Code from ISO20022
{
"type": "string",
"enum": [
"DEBT",
"CRED",
"SHAR",
"SLEV"
]
}
A _link object with all availabel link types
{
"title": "_linksAll",
"type": "object",
"properties": {
"scaRedirect": {
"$ref": "#/definitions/hrefType"
},
"scaApp2AppIOS": {
"$ref": "#/definitions/hrefType"
},
"scaApp2AppAndroid": {
"$ref": "#/definitions/hrefType"
},
"scaOAuth": {
"$ref": "#/definitions/hrefType"
},
"startAuthorisation": {
"$ref": "#/definitions/hrefType"
},
"startAuthorisationWithPsuIdentification": {
"$ref": "#/definitions/hrefType"
},
"updatePsuIdentification": {
"$ref": "#/definitions/hrefType"
},
"startAuthorisationWithProprietaryData": {
"$ref": "#/definitions/hrefType"
},
"updateProprietaryData": {
"$ref": "#/definitions/hrefType"
},
"startAuthorisationWithPsuAuthentication": {
"$ref": "#/definitions/hrefType"
},
"updatePsuAuthentication": {
"$ref": "#/definitions/hrefType"
},
"startAuthorisationWithEncryptedPsuAuthentication": {
"$ref": "#/definitions/hrefType"
},
"updateEncryptedPsuAuthentication": {
"$ref": "#/definitions/hrefType"
},
"startAuthorisationWithAuthenticationMethodSelection": {
"$ref": "#/definitions/hrefType"
},
"selectAuthenticationMethod": {
"$ref": "#/definitions/hrefType"
},
"startAuthorisationWithTransactionAuthorisation": {
"$ref": "#/definitions/hrefType"
},
"authoriseTransaction": {
"$ref": "#/definitions/hrefType"
},
"self": {
"$ref": "#/definitions/hrefType"
},
"status": {
"$ref": "#/definitions/hrefType"
},
"scaStatus": {
"$ref": "#/definitions/hrefType"
},
"account": {
"$ref": "#/definitions/hrefType"
},
"balances": {
"$ref": "#/definitions/hrefType"
},
"transactions": {
"$ref": "#/definitions/hrefType"
},
"transactionDetails": {
"$ref": "#/definitions/hrefType"
},
"cardAccount": {
"$ref": "#/definitions/hrefType"
},
"cardTransactions": {
"$ref": "#/definitions/hrefType"
},
"first": {
"$ref": "#/definitions/hrefType"
},
"next": {
"$ref": "#/definitions/hrefType"
},
"previous": {
"$ref": "#/definitions/hrefType"
},
"last": {
"$ref": "#/definitions/hrefType"
},
"download": {
"$ref": "#/definitions/hrefType"
}
}
}
Category of the TPP message category
{
"title": "tppMessageCategory",
"example": "ERROR",
"type": "string",
"enum": [
"ERROR",
"WARNING"
]
}
Message codes defined for PIS for HTTP Error code 400 (BAD_REQUEST).
{
"title": "MessageCode400_PIS",
"example": "FORMAT_ERROR",
"type": "string",
"enum": [
"FORMAT_ERROR",
"PARAMETER_NOT_CONSISTENT",
"PARAMETER_NOT_SUPPORTED",
"SERVICE_INVALID",
"RESOURCE_UNKNOWN",
"RESOURCE_EXPIRED",
"RESOURCE_BLOCKED",
"TIMESTAMP_INVALID",
"PERIOD_INVALID",
"SCA_METHOD_UNKNOWN",
"CONSENT_UNKNOWN",
"PAYMENT_FAILED",
"EXECUTION_DATE_INVALID"
]
}
Message codes defined for PIS for HTTP Error code 401 (UNAUTHORIZED).
{
"title": "MessageCode401_PIS",
"example": "CERTIFICATE_INVALID",
"type": "string",
"enum": [
"CERTIFICATE_INVALID",
"CERTIFICATE_EXPIRED",
"CERTIFICATE_BLOCKED",
"CERTIFICATE_REVOKE",
"CERTIFICATE_MISSING",
"SIGNATURE_INVALID",
"SIGNATURE_MISSING",
"CORPORATE_ID_INVALID",
"PSU_CREDENTIALS_INVALID",
"CONSENT_INVALID",
"CONSENT_EXPIRED",
"TOKEN_UNKNOWN",
"TOKEN_INVALID",
"TOKEN_EXPIRED",
"REQUIRED_KID_MISSING"
]
}
Message codes defined defined for PIS for PIS for HTTP Error code 403 (FORBIDDEN).
{
"title": "MessageCode403_PIS",
"example": "CONSENT_UNKNOWN",
"type": "string",
"enum": [
"CONSENT_UNKNOWN",
"SERVICE_BLOCKED",
"RESOURCE_UNKNOWN",
"RESOURCE_EXPIRED",
"PRODUCT_INVALID"
]
}
Message codes defined for PIS for HTTP Error code 404 (NOT FOUND).
{
"title": "MessageCode404_PIS",
"example": "RESOURCE_UNKNOWN",
"type": "string",
"enum": [
"RESOURCE_UNKNOWN",
"PRODUCT_UNKNOWN"
]
}
{
"title": "tppMessage400_PIS",
"type": "object",
"properties": {
"category": {
"$ref": "#/definitions/tppMessageCategory"
},
"code": {
"$ref": "#/definitions/MessageCode400_PIS"
},
"path": {
"type": "string"
},
"text": {
"description": "Additional explaining text to the TPP.",
"type": "string",
"maxLength": 512
}
},
"required": [
"category",
"code"
]
}
{
"title": "tppMessage401_PIS",
"type": "object",
"properties": {
"category": {
"$ref": "#/definitions/tppMessageCategory"
},
"code": {
"$ref": "#/definitions/MessageCode401_PIS"
},
"path": {
"type": "string"
},
"text": {
"description": "Additional explaining text to the TPP.",
"type": "string",
"maxLength": 512
}
},
"required": [
"category",
"code"
]
}
{
"title": "tppMessage403_PIS",
"type": "object",
"properties": {
"category": {
"$ref": "#/definitions/tppMessageCategory"
},
"code": {
"$ref": "#/definitions/MessageCode403_PIS"
},
"path": {
"type": "string"
},
"text": {
"description": "Additional explaining text to the TPP.",
"type": "string",
"maxLength": 512
}
},
"required": [
"category",
"code"
]
}
{
"title": "tppMessage404_PIS",
"type": "object",
"properties": {
"category": {
"$ref": "#/definitions/tppMessageCategory"
},
"code": {
"$ref": "#/definitions/MessageCode404_PIS"
},
"path": {
"type": "string"
},
"text": {
"description": "Additional explaining text to the TPP.",
"type": "string",
"maxLength": 512
}
},
"required": [
"category",
"code"
]
}
{
"title": "tppMessage405_PIS",
"type": "object",
"properties": {
"category": {
"$ref": "#/definitions/tppMessageCategory"
},
"code": {
"description": "Message codes defined for payment cancelations PIS for HTTP Error code 405 (METHOD NOT ALLOWED).",
"example": "SERVICE_INVALID",
"type": "string",
"default": "SERVICE_INVALID"
},
"path": {
"type": "string"
},
"text": {
"description": "Additional explaining text to the TPP.",
"type": "string",
"maxLength": 512
}
},
"required": [
"category",
"code"
]
}
{
"title": "tppMessage409_PIS",
"type": "object",
"properties": {
"category": {
"$ref": "#/definitions/tppMessageCategory"
},
"code": {
"description": "Message codes defined for PIS for HTTP Error code 409 (CONFLICT).",
"example": "STATUS_INVALID",
"type": "string",
"default": "STATUS_INVALID"
},
"path": {
"type": "string"
},
"text": {
"description": "Additional explaining text to the TPP.",
"type": "string",
"maxLength": 512
}
},
"required": [
"category",
"code"
]
}
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 400.
{
"title": "Error400_NG_PIS",
"type": "object",
"properties": {
"tppMessages": {
"type": "array",
"items": {
"$ref": "#/definitions/tppMessage400_PIS"
}
},
"_links": {
"$ref": "#/definitions/_linksAll"
}
}
}
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 401.
{
"title": "Error401_NG_PIS",
"type": "object",
"properties": {
"tppMessages": {
"type": "array",
"items": {
"$ref": "#/definitions/tppMessage401_PIS"
}
},
"_links": {
"$ref": "#/definitions/_linksAll"
}
}
}
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 403.
{
"title": "Error403_NG_PIS",
"type": "object",
"properties": {
"tppMessages": {
"type": "array",
"items": {
"$ref": "#/definitions/tppMessage403_PIS"
}
},
"_links": {
"$ref": "#/definitions/_linksAll"
}
}
}
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 404.
{
"title": "Error404_NG_PIS",
"type": "object",
"properties": {
"tppMessages": {
"type": "array",
"items": {
"$ref": "#/definitions/tppMessage404_PIS"
}
},
"_links": {
"$ref": "#/definitions/_linksAll"
}
}
}
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 405.
{
"title": "Error405_NG_PIS",
"type": "object",
"properties": {
"tppMessages": {
"type": "array",
"items": {
"$ref": "#/definitions/tppMessage405_PIS"
}
},
"_links": {
"$ref": "#/definitions/_linksAll"
}
}
}
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 409.
{
"title": "Error409_NG_PIS",
"type": "object",
"properties": {
"tppMessages": {
"type": "array",
"items": {
"$ref": "#/definitions/tppMessage409_PIS"
}
},
"_links": {
"$ref": "#/definitions/_linksAll"
}
}
}
Link to a resource
{
"type": "object",
"properties": {
"href": {
"$ref": "#/definitions/hrefEntry"
}
}
}
Link to a resource
{
"type": "string",
"example": "/v1/payments/sepa-credit-transfers/1234-wertiq-983"
}
Body of the response for a successful payment initiation request.
{
"title": "paymentInitationRequestResponse-201",
"type": "object",
"properties": {
"transactionStatus": {
"$ref": "#/definitions/transactionStatus"
},
"paymentId": {
"description": "Resource identification of the generated payment initiation resource.",
"example": "1234-wertiq-983",
"type": "string"
},
"transactionFees": {
"$ref": "#/definitions/amount"
},
"transactionFeeIndicator": {
"description": "If equals 'true', the transaction will involve specific transaction cost as shown by the ASPSP in\ntheir public price list or as agreed between ASPSP and PSU.\nIf equals 'false', the transaction will not involve additional specific transaction costs to the PSU.",
"type": "boolean"
},
"scaMethods": {
"description": "This data element might be contained, if SCA is required and if the PSU has a choice between different\nauthentication methods.\n\nDepending on the risk management of the ASPSP this choice might be offered before or after the PSU\nhas been identified with the first relevant factor, or if an access token is transported.\n\nIf this data element is contained, then there is also an hyperlink of type 'startAuthorisationWithAuthenticationMethodSelection'\ncontained in the response body.\n\nThese methods shall be presented towards the PSU for selection by the TPP.",
"type": "array",
"items": {
"$ref": "#/definitions/authenticationObject"
}
},
"chosenScaMethod": {
"$ref": "#/definitions/authenticationObject"
},
"challengeData": {
"$ref": "#/definitions/challengeData"
},
"_links": {
"$ref": "#/definitions/_linksPaymentInitiation"
},
"psuMessage": {
"description": "Text to be displayed to the PSU",
"type": "string",
"maxLength": 512
},
"tppMessages": {
"type": "array",
"items": {
"$ref": "#/definitions/tppMessage2XX"
}
}
},
"required": [
"transactionStatus",
"paymentId",
"_links"
]
}
The transaction status is filled with codes of the ISO 20022 data table:
- 'ACCC': 'AcceptedSettlementCompleted' - Settlement on the creditor's account has been completed.
- 'ACCP': 'AcceptedCustomerProfile' - Preceding check of technical validation was successful. Customer profile check was also successful.
'ACSC': 'AcceptedSettlementCompleted' - Settlement on the debtor?s account has been completed.
Usage: this can be used by the first agent to report to the debtor that the transaction has been completed.
Warning: this status is provided for transaction status reasons, not for financial information. It can only be used after bilateral agreement.
- 'ACSP': 'AcceptedSettlementInProcess' - All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution.
- 'ACTC': 'AcceptedTechnicalValidation' - Authentication and syntactical and semantical validation are successful.
- 'ACWC': 'AcceptedWithChange' - Instruction is accepted but a change will be made, such as date or remittance not sent.
- 'ACWP': 'AcceptedWithoutPosting' - Payment instruction included in the credit transfer is accepted without being posted to the creditor customer?s account.
- 'RCVD': 'Received' - Payment initiation has been received by the receiving agent.
- 'PDNG': 'Pending' - Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed.
- 'RJCT': 'Rejected' - Payment initiation or individual transaction included in the payment initiation has been rejected.
- 'CANC': 'Cancelled' Payment initiation has been cancelled before execution Remark: This code is still requested from ISO20022.
- 'ACFC': 'AcceptedFundsChecked' - Preceeding check of technical validation and customer profile was successful and an automatic funds check was positive . Remark: This code is still requested from ISO20022.
- 'PATC': 'PartiallyAcceptedTechnical' Correct The payment initiation needs multiple authentications, where some but not yet all have been performed. Syntactical and semantical validations are successful. Remark: This code is still requested from ISO20022.
{
"title": "transactionStatus",
"example": "ACCC",
"type": "string",
"enum": [
"ACCC",
"ACCP",
"ACSC",
"ACSP",
"ACTC",
"ACWC",
"ACWP",
"RCVD",
"PDNG",
"RJCT",
"CANC",
"ACFC",
"PATC"
]
}
Authentication Object
{
"title": "authenticationObject",
"type": "object",
"properties": {
"authenticationType": {
"$ref": "#/definitions/authenticationType"
},
"authenticationVersion": {
"description": "Depending on the \"authenticationType\".\nThis version can be used by differentiating authentication tools used within performing OTP generation in the same authentication type.\nThis version can be referred to in the ASPSP?s documentation.",
"type": "string"
},
"authenticationMethodId": {
"description": "An identification provided by the ASPSP for the later identification of the authentication method selection.",
"example": "myAuthenticationID",
"type": "string",
"maxLength": 35
},
"name": {
"description": "This is the name of the authentication method defined by the PSU in the Online Banking frontend of the ASPSP.\nAlternatively this could be a description provided by the ASPSP like \"SMS OTP on phone +49160 xxxxx 28\".\nThis name shall be used by the TPP when presenting a list of authentication methods to the PSU, if available.",
"example": "SMS OTP on phone +49160 xxxxx 28",
"type": "string"
},
"explanation": {
"description": "Detailed information about the SCA method for the PSU.",
"example": "Detailed information about the SCA method for the PSU.",
"type": "string"
}
},
"required": [
"authenticationType",
"authenticationMethodId"
]
}
Type of the authentication method.
More authentication types might be added during implementation projects and documented in the ASPSP documentation.
- 'SMS_OTP': An SCA method, where an OTP linked to the transaction to be authorised is sent to the PSU through a SMS channel.
- 'CHIP_OTP': An SCA method, where an OTP is generated by a chip card, e.g. an TOP derived from an EMV cryptogram. To contact the card, the PSU normally needs a (handheld) device. With this device, the PSU either reads the challenging data through a visual interface like flickering or the PSU types in the challenge through the device key pad. The device then derives an OTP from the challenge data and displays the OTP to the PSU.
- 'PHOTO_OTP': An SCA method, where the challenge is a QR code or similar encoded visual data which can be read in by a consumer device or specific mobile app. The device resp. the specific app than derives an OTP from the visual challenge data and displays the OTP to the PSU.
- 'PUSH_OTP': An OTP is pushed to a dedicated authentication APP and displayed to the PSU.
{
"title": "authenticationType",
"example": "SMS_OTP",
"type": "string",
"enum": [
"SMS_OTP",
"CHIP_OTP",
"PHOTO_OTP",
"PUSH_OTP"
]
}
It is contained in addition to the data element 'chosenScaMethod' if challenge data is needed for SCA. In rare cases this attribute is also used in the context of the 'startAuthorisationWithPsuAuthentication' link.
{
"title": "challengeData",
"type": "object",
"properties": {
"image": {
"description": "PNG data (max. 512 kilobyte) to be displayed to the PSU,\nBase64 encoding, cp. [RFC4648].\nThis attribute is used only, when PHOTO_OTP or CHIP_OTP\nis the selected SCA method.",
"type": "string"
},
"data": {
"description": "String challenge data",
"type": "string"
},
"imageLink": {
"description": "A link where the ASPSP will provides the challenge image for the TPP.",
"type": "string"
},
"otpMaxLength": {
"description": "The maximal length for the OTP to be typed in by the PSU.",
"type": "integer",
"format": "int32"
},
"otpFormat": {
"$ref": "#/definitions/OtpFormat"
},
"additionalInformation": {
"description": "Additional explanation for the PSU to explain\ne.g. fallback mechanism for the chosen SCA method.\nThe TPP is obliged to show this to the PSU.",
"type": "string"
}
}
}
A list of hyperlinks to be recognised by the TPP. The actual hyperlinks used in the response depend on the dynamical decisions of the ASPSP when processing the request.
Remark: All links can be relative or full links, to be decided by the ASPSP.
Type of links admitted in this response, (further links might be added for ASPSP defined extensions):
- 'scaRedirect': In case of an SCA Redirect Approach, the ASPSP is transmitting the link to which to redirect the PSU browser.
- 'scaApp2AppIOS': In case of an App2App Redirect Approach, the ASPSP is transmitting the link to which to redirect the PSU mobile device.
- 'scaApp2AppAndroid': In case of an App2App Redirect Approach, the ASPSP is transmitting the link to which to redirect the PSU mobile device.
- 'scaOAuth': In case of a SCA OAuth2 Approach, the ASPSP is transmitting the URI where the configuration of the Authorisation Server can be retrieved. The configuration follows the OAuth 2.0 Authorisation Server Metadata specification.
- 'startAuthorisation': In case, where an explicit start of the transaction authorisation is needed, but no more data needs to be updated (no authentication method to be selected, no PSU identification nor PSU authentication data to be uploaded).
- 'startAuthorisationWithPsuIdentification': The link to the authorisation end-point, where the authorisation sub-resource has to be generated while uploading the PSU identification data.
- 'startAuthorisationWithPsuAuthentication':
The link to the authorisation end-point, where the authorisation sub-resource has to be generated while
uploading the PSU authentication data.
- 'startAuthorisationWithEncryptedPsuAuthentication': Same as startAuthorisactionWithPsuAuthentication where the authentication data need to be encrypted on application layer in uploading.
- 'startAuthorisationWithAuthenticationMethodSelection': The link to the authorisation end-point, where the authorisation sub-resource has to be generated while selecting the authentication method. This link is contained under exactly the same conditions as the data element "scaMethods"
- 'startAuthorisationWithTransactionAuthorisation': The link to the authorisation end-point, where the authorisation sub-resource has to be generated while authorising the transaction e.g. by uploading an OTP received by SMS.
- 'self': The link to the payment initiation resource created by this request. This link can be used to retrieve the resource data.
- 'status': The link to retrieve the transaction status of the payment initiation.
- 'scaStatus': The link to retrieve the scaStatus of the corresponding authorisation sub-resource. This link is only contained, if an authorisation sub-resource has been already created.
{
"title": "_linksPaymentInitiation",
"example": {
"scaRedirect": "{\"href\":\"https://www.testbank.com/asdfasdfasdf\"}",
"self": "{\"href\":\"/v1/payments/sepa-credit-transfers/1234-wertiq-983\"}"
},
"type": "object",
"properties": {
"scaRedirect": {
"$ref": "#/definitions/hrefType"
},
"scaApp2AppIOS": {
"$ref": "#/definitions/hrefType"
},
"scaApp2AppAndroid": {
"$ref": "#/definitions/hrefType"
},
"scaOAuth": {
"$ref": "#/definitions/hrefType"
},
"startAuthorisation": {
"$ref": "#/definitions/hrefType"
},
"startAuthorisationWithPsuIdentification": {
"$ref": "#/definitions/hrefType"
},
"startAuthorisationWithPsuAuthentication": {
"$ref": "#/definitions/hrefType"
},
"startAuthorisationWithEncryptedPsuAuthentication": {
"$ref": "#/definitions/hrefType"
},
"startAuthorisationWithAuthenticationMethodSelection": {
"$ref": "#/definitions/hrefType"
},
"startAuthorisationWithTransactionAuthorisation": {
"$ref": "#/definitions/hrefType"
},
"self": {
"$ref": "#/definitions/hrefType"
},
"status": {
"$ref": "#/definitions/hrefType"
},
"scaStatus": {
"$ref": "#/definitions/hrefType"
}
}
}
The format type of the OTP to be typed in. The admitted values are "characters" or "integer".
{
"title": "OtpFormat",
"example": "characters",
"type": "string",
"enum": [
"characters",
"integer"
]
}
{
"title": "tppMessage2XX",
"type": "object",
"properties": {
"category": {
"$ref": "#/definitions/tppMessageCategory"
},
"code": {
"description": "Message codes for HTTP Error codes 2XX.",
"example": "WARNING",
"type": "string",
"default": "WARNING"
},
"path": {
"type": "string"
},
"text": {
"description": "Additional explaining text to the TPP.",
"type": "string",
"maxLength": 512
}
},
"required": [
"category",
"code"
]
}