diff --git a/obp-api/src/main/scala/code/api/ResourceDocs1_4_0/SwaggerDefinitionsJSON.scala b/obp-api/src/main/scala/code/api/ResourceDocs1_4_0/SwaggerDefinitionsJSON.scala index 84ce088aef..431abdcb8c 100644 --- a/obp-api/src/main/scala/code/api/ResourceDocs1_4_0/SwaggerDefinitionsJSON.scala +++ b/obp-api/src/main/scala/code/api/ResourceDocs1_4_0/SwaggerDefinitionsJSON.scala @@ -38,6 +38,7 @@ import java.net.URLEncoder import code.api.v5_1_0.{AtmsJsonV510, _} import code.endpointMapping.EndpointMappingCommons +import net.liftweb.json.Extraction import scala.collection.immutable.List @@ -79,7 +80,7 @@ object SwaggerDefinitionsJSON { entity_post_code = "1060", entity_country = "CY", entity_web_site = "www.example.com", - services = """[{"CY":["PS_010","PS_020","PS_03C","PS_04C"]}]""" + services = json.parse("""[{"CY":["PS_010","PS_020","PS_03C","PS_04C"]}]""") ) val license = License( @@ -2259,7 +2260,7 @@ object SwaggerDefinitionsJSON { duration = 39, source_ip = "2001:0db8:3c4d:0015:0000:0000:1a2f:1a2b", target_ip = "2001:0db8:3c4d:0015:0000:0000:1a2f:1a2b", - response_body = """{"code":401,"message":"OBP-20001: User not logged in. Authentication is required!"}""".stripMargin + response_body = json.parse("""{"code":401,"message":"OBP-20001: User not logged in. Authentication is required!"}""") ) val resourceUserJSON = ResourceUserJSON( diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/AccountInformationServiceAISApi.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/AccountInformationServiceAISApi.scala index d88a7a9092..8004e8193d 100644 --- a/obp-api/src/main/scala/code/api/berlin/group/v1_3/AccountInformationServiceAISApi.scala +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/AccountInformationServiceAISApi.scala @@ -5,7 +5,9 @@ import java.text.SimpleDateFormat import code.api.APIFailureNewStyle import code.api.Constant.{SYSTEM_READ_ACCOUNTS_BERLIN_GROUP_VIEW_ID, SYSTEM_READ_BALANCES_BERLIN_GROUP_VIEW_ID, SYSTEM_READ_TRANSACTIONS_BERLIN_GROUP_VIEW_ID} import code.api.berlin.group.v1_3.JSONFactory_BERLIN_GROUP_1_3.{PostConsentResponseJson, _} +import code.api.berlin.group.v1_3.model.{HrefType, LinksAll, ScaStatusResponse} import code.api.berlin.group.v1_3.{JSONFactory_BERLIN_GROUP_1_3, JvalueCaseClass, OBP_BERLIN_GROUP_1_3} +import code.api.berlin.group.v1_3.model._ import code.api.util.APIUtil.{passesPsd2Aisp, _} import code.api.util.ApiTag._ import code.api.util.ErrorMessages._ @@ -26,6 +28,7 @@ import com.openbankproject.commons.util.ApiVersion import net.liftweb.common.{Empty, Full} import net.liftweb.http.js.JE.JsRaw import net.liftweb.http.rest.RestHelper +import net.liftweb import net.liftweb.json import net.liftweb.json._ @@ -55,8 +58,13 @@ object APIMethods_AccountInformationServiceAISApi extends RestHelper { getTransactionList :: readAccountDetails :: readCardAccount :: - startConsentAuthorisation :: - updateConsentsPsuData :: + startConsentAuthorisationTransactionAuthorisation :: + startConsentAuthorisationUpdatePsuAuthentication :: + startConsentAuthorisationSelectPsuAuthenticationMethod :: + updateConsentsPsuDataTransactionAuthorisation :: + updateConsentsPsuDataUpdatePsuAuthentication :: + updateConsentsPsuDataUpdateAuthorisationConfirmation :: + updateConsentsPsuDataUpdateSelectPsuAuthenticationMethod :: Nil lazy val newStyleEndpoints: List[(String, String)] = resourceDocs.map { rd => (rd.partialFunctionName, rd.implementedInApiVersion.toString()) @@ -123,8 +131,7 @@ As a last option, an ASPSP might in addition accept a command with access rights consentId = "1234-wertiq-983", consentStatus = "received", _links = ConsentLinksV13("/v1.3/consents/1234-wertiq-983/authorisations") - ) - , + ), List(UserNotLoggedIn, UnknownError), ApiTag("Account Information Service (AIS)") :: apiTagBerlinGroupM :: Nil ) @@ -1020,45 +1027,49 @@ respectively the OAuth2 access token. } } - resourceDocs += ResourceDoc( - startConsentAuthorisation, - apiVersion, - nameOf(startConsentAuthorisation), - "POST", - "/consents/CONSENTID/authorisations", - "Start the authorisation process for a consent", + def generalStartConsentAuthorisationSummary(isMockedData:Boolean) = s"""${mockedDataText(false)} Create an authorisation sub-resource and start the authorisation process of a consent. The message might in addition transmit authentication and authorisation related data. his method is iterated n times for a n times SCA authorisation in a corporate context, each creating an own authorisation sub-endpoint for the corresponding PSU authorising the consent. The ASPSP might make the usage of this access method unnecessary, since the related authorisation - resource will be automatically created by the ASPSP after the submission of the consent data with the - first POST consents call. The start authorisation process is a process which is needed for creating - a new authorisation or cancellation sub-resource. - - This applies in the following scenarios: * The ASPSP has indicated with an 'startAuthorisation' hyperlink - in the preceding Payment Initiation Response that an explicit start of the authorisation process is needed by the TPP. - The 'startAuthorisation' hyperlink can transport more information about data which needs to be uploaded by using - the extended forms. - * 'startAuthorisationWithPsuIdentfication', - * 'startAuthorisationWithPsuAuthentication' - * 'startAuthorisationWithEncryptedPsuAuthentication' - * 'startAuthorisationWithAuthentciationMethodSelection' - * The related payment initiation cannot yet be executed since a multilevel SCA is mandated. - * The ASPSP has indicated with an 'startAuthorisation' hyperlink in the preceding Payment Cancellation - Response that an explicit start of the authorisation process is needed by the TPP. - - The 'startAuthorisation' hyperlink can transport more information about data which needs to be uploaded by - using the extended forms as indicated above. - * The related payment cancellation request cannot be applied yet since a multilevel SCA is mandate for executing the cancellation. - * The signing basket needs to be authorised yet. +resource will be automatically created by the ASPSP after the submission of the consent data with the +first POST consents call. The start authorisation process is a process which is needed for creating +a new authorisation or cancellation sub-resource. -""", - emptyObjectJson, +This applies in the following scenarios: * The ASPSP has indicated with an 'startAuthorisation' hyperlink +in the preceding Payment Initiation Response that an explicit start of the authorisation process is needed by the TPP. +The 'startAuthorisation' hyperlink can transport more information about data which needs to be uploaded by using +the extended forms. +* 'startAuthorisationWithPsuIdentfication', +* 'startAuthorisationWithPsuAuthentication' +* 'startAuthorisationWithEncryptedPsuAuthentication' +* 'startAuthorisationWithAuthentciationMethodSelection' +* The related payment initiation cannot yet be executed since a multilevel SCA is mandated. +* The ASPSP has indicated with an 'startAuthorisation' hyperlink in the preceding Payment Cancellation +Response that an explicit start of the authorisation process is needed by the TPP. + +The 'startAuthorisation' hyperlink can transport more information about data which needs to be uploaded by +using the extended forms as indicated above. +* The related payment cancellation request cannot be applied yet since a multilevel SCA is mandate for executing the cancellation. +* The signing basket needs to be authorised yet. + +""" + + resourceDocs += ResourceDoc( + startConsentAuthorisationTransactionAuthorisation, + apiVersion, + nameOf(startConsentAuthorisationTransactionAuthorisation), + "POST", + "/consents/CONSENTID/authorisations", + "Start the authorisation process for a consent(transactionAuthorisation)", + generalStartConsentAuthorisationSummary(false), + json.parse("""{"scaAuthenticationData":""}"""), json.parse("""{ "scaStatus": "received", "psuMessage": "Please use your BankApp for transaction Authorisation.", + "authorisationId": "123auth456.", "_links": { "scaStatus": {"href":"/v1.3/consents/qwer3456tzui7890/authorisations/123auth456"} @@ -1068,8 +1079,8 @@ The ASPSP might make the usage of this access method unnecessary, since the rela ApiTag("Account Information Service (AIS)") :: apiTagBerlinGroupM :: Nil ) - lazy val startConsentAuthorisation : OBPEndpoint = { - case "consents" :: consentId :: "authorisations" :: Nil JsonPost _ => { + lazy val startConsentAuthorisationTransactionAuthorisation : OBPEndpoint = { + case "consents" :: consentId :: "authorisations" :: Nil JsonPost json -> _ if checkTransactionAuthorisation(json)=> { cc => for { (Full(u), callContext) <- authenticatedAccess(cc) @@ -1096,14 +1107,96 @@ The ASPSP might make the usage of this access method unnecessary, since the rela } } } - + resourceDocs += ResourceDoc( - updateConsentsPsuData, + startConsentAuthorisationUpdatePsuAuthentication, apiVersion, - nameOf(updateConsentsPsuData), - "PUT", - "/consents/CONSENTID/authorisations/AUTHORISATIONID", - "Update PSU Data for consents", + nameOf(startConsentAuthorisationUpdatePsuAuthentication), + "POST", + "/consents/CONSENTID/authorisations", + "Start the authorisation process for a consent(updatePsuAuthentication)", + generalStartConsentAuthorisationSummary(true), + json.parse("""{ + "psuData": { + "password": "start12" + } + }"""), + json.parse("""{ + "scaStatus": "received", + "psuMessage": "Please use your BankApp for transaction Authorisation.", + "authorisationId": "123auth456.", + "_links": + { + "scaStatus": {"href":"/v1.3/consents/qwer3456tzui7890/authorisations/123auth456"} + } + }"""), + List(UserNotLoggedIn, UnknownError), + ApiTag("Account Information Service (AIS)") :: apiTagBerlinGroupM :: Nil + ) + + lazy val startConsentAuthorisationUpdatePsuAuthentication : OBPEndpoint = { + case "consents" :: consentId :: "authorisations" :: Nil JsonPost json -> _ if checkUpdatePsuAuthentication(json)=> { + cc => + for { + (Full(u), callContext) <- authenticatedAccess(cc) + } yield { + (liftweb.json.parse( + """{ + "scaStatus": "received", + "psuMessage": "Please use your BankApp for transaction Authorisation.", + "authorisationId": "123auth456.", + "_links": + { + "scaStatus": {"href":"/v1.3/consents/qwer3456tzui7890/authorisations/123auth456"} + } + }"""),HttpCode.`201`(callContext)) + } + } + } + + resourceDocs += ResourceDoc( + startConsentAuthorisationSelectPsuAuthenticationMethod, + apiVersion, + nameOf(startConsentAuthorisationSelectPsuAuthenticationMethod), + "POST", + "/consents/CONSENTID/authorisations", + "Start the authorisation process for a consent(selectPsuAuthenticationMethod)", + generalStartConsentAuthorisationSummary(true), + json.parse("""{"authenticationMethodId":""}"""), + json.parse("""{ + "scaStatus": "received", + "psuMessage": "Please use your BankApp for transaction Authorisation.", + "authorisationId": "123auth456.", + "_links": + { + "scaStatus": {"href":"/v1.3/consents/qwer3456tzui7890/authorisations/123auth456"} + } + }"""), + List(UserNotLoggedIn, UnknownError), + ApiTag("Account Information Service (AIS)") :: apiTagBerlinGroupM :: Nil + ) + + lazy val startConsentAuthorisationSelectPsuAuthenticationMethod : OBPEndpoint = { + case "consents" :: consentId :: "authorisations" :: Nil JsonPost json -> _ if checkSelectPsuAuthenticationMethod(json)=> { + cc => + for { + (Full(u), callContext) <- authenticatedAccess(cc) + } yield { + (liftweb.json.parse( + """{ + "scaStatus": "received", + "psuMessage": "Please use your BankApp for transaction Authorisation.", + "authorisationId": "123auth456.", + "_links": + { + "scaStatus": {"href":"/v1.3/consents/qwer3456tzui7890/authorisations/123auth456"} + } + }"""),HttpCode.`201`(callContext)) + } + } + } + + def generalUpdateConsentsPsuDataSummary(isMockedData: Boolean) = s"""${mockedDataText(false)} This method update PSU data on the consents resource if needed. It may authorise a consent within the Embedded SCA Approach where needed. Independently from the SCA Approach it supports @@ -1130,15 +1223,27 @@ Maybe in a later version the access path will change. * Transaction Authorisation WARNING: This method need a reduced header, therefore many optional elements are not present. Maybe in a later version the access path will change. - """, + """ + + resourceDocs += ResourceDoc( + updateConsentsPsuDataTransactionAuthorisation, + apiVersion, + nameOf(updateConsentsPsuDataTransactionAuthorisation), + "PUT", + "/consents/CONSENTID/authorisations/AUTHORISATIONID", + "Update PSU Data for consents (transactionAuthorisation)", + generalUpdateConsentsPsuDataSummary(false), json.parse("""{"scaAuthenticationData":"123"}"""), - emptyObjectJson, + ScaStatusResponse( + scaStatus = "received", + _links = Some(LinksAll(scaStatus = Some(HrefType(Some(s"/v1.3/consents/1234-wertiq-983/authorisations"))))) + ), List(UserNotLoggedIn, UnknownError), ApiTag("Account Information Service (AIS)") :: apiTagBerlinGroupM :: Nil ) - lazy val updateConsentsPsuData : OBPEndpoint = { - case "consents" :: consentId :: "authorisations" :: authorisationId :: Nil JsonPut jsonPut -> _ => { + lazy val updateConsentsPsuDataTransactionAuthorisation : OBPEndpoint = { + case "consents" :: consentId :: "authorisations" :: authorisationId :: Nil JsonPut jsonPut -> _ if checkTransactionAuthorisation(jsonPut) => { cc => for { (Full(u), callContext) <- authenticatedAccess(cc) @@ -1146,9 +1251,9 @@ Maybe in a later version the access path will change. _ <- Future(Consents.consentProvider.vend.getConsentByConsentId(consentId)) map { unboxFullOrFail(_, callContext, ConsentNotFound) } - failMsg = s"$InvalidJsonFormat The Json body should be the $UpdatePaymentPsuDataJson " + failMsg = s"$InvalidJsonFormat The Json body should be the $TransactionAuthorisation " updateJson <- NewStyle.function.tryons(failMsg, 400, callContext) { - jsonPut.extract[UpdatePaymentPsuDataJson] + jsonPut.extract[TransactionAuthorisation] } (challenges, callContext) <- NewStyle.function.getChallengesByConsentId(consentId, callContext) _ <- NewStyle.function.tryons(s"$AuthorisationNotFound Current AUTHORISATION_ID($authorisationId)", 400, callContext) { @@ -1184,7 +1289,132 @@ Maybe in a later version the access path will change. unboxFullOrFail(_, callContext, ConsentUserCannotBeAdded) } } yield { - (createPostConsentResponseJson(consent.toList.head), HttpCode.`200`(callContext)) + (createPutConsentResponseJson(consent.toList.head), HttpCode.`200`(callContext)) + } + } + } + + resourceDocs += ResourceDoc( + updateConsentsPsuDataUpdatePsuAuthentication, + apiVersion, + nameOf(updateConsentsPsuDataUpdatePsuAuthentication), + "PUT", + "/consents/CONSENTID/authorisations/AUTHORISATIONID", + "Update PSU Data for consents (updatePsuAuthentication)", + generalUpdateConsentsPsuDataSummary(true), + json.parse("""{"psuData": {"password": "start12"}}""".stripMargin), + json.parse("""{ + | "scaStatus": "psuAuthenticated", + | "_links": { + | "authoriseTransaction": {"href": "/psd2/v1/payments/1234-wertiq-983/authorisations/123auth456"} + | } + | }""".stripMargin), + List(UserNotLoggedIn, UnknownError), + ApiTag("Account Information Service (AIS)") :: apiTagBerlinGroupM :: Nil + ) + + lazy val updateConsentsPsuDataUpdatePsuAuthentication : OBPEndpoint = { + case "consents" :: consentId :: "authorisations" :: authorisationId :: Nil JsonPut jsonPut -> _ if checkUpdatePsuAuthentication(jsonPut) => { + cc => + for { + (Full(u), callContext) <- authenticatedAccess(cc) + + } yield { + (liftweb.json.parse( + """{ + | "scaStatus": "psuAuthenticated", + | "_links": { + | "authoriseTransaction": {"href": "/psd2/v1/payments/1234-wertiq-983/authorisations/123auth456"} + | } + |}""".stripMargin), HttpCode.`200`(callContext)) + } + } + } + + resourceDocs += ResourceDoc( + updateConsentsPsuDataUpdateSelectPsuAuthenticationMethod, + apiVersion, + nameOf(updateConsentsPsuDataUpdateSelectPsuAuthenticationMethod), + "PUT", + "/consents/CONSENTID/authorisations/AUTHORISATIONID", + "Update PSU Data for consents (selectPsuAuthenticationMethod)", + generalUpdateConsentsPsuDataSummary(true), + json.parse("""{ + | "authenticationMethodId": "myAuthenticationID" + |}""".stripMargin), + json.parse("""{ + | "scaStatus": "scaMethodSelected", + | "chosenScaMethod": { + | "authenticationType": "SMS_OTP", + | "authenticationMethodId": "myAuthenticationID"}, + | "challengeData": { + | "otpMaxLength": 6, + | "otpFormat": "integer"}, + | "_links": { + | "authoriseTransaction": {"href": "/psd2/v1/payments/1234-wertiq-983/authorisations/123auth456"} + | } + | }""".stripMargin), + List(UserNotLoggedIn, UnknownError), + ApiTag("Account Information Service (AIS)") :: apiTagBerlinGroupM :: Nil + ) + + lazy val updateConsentsPsuDataUpdateSelectPsuAuthenticationMethod : OBPEndpoint = { + case "consents" :: consentId :: "authorisations" :: authorisationId :: Nil JsonPut jsonPut -> _ if checkSelectPsuAuthenticationMethod(jsonPut) => { + cc => + for { + (Full(u), callContext) <- authenticatedAccess(cc) + + } yield { + (liftweb.json.parse( + """{ + | "scaStatus": "scaMethodSelected", + | "chosenScaMethod": { + | "authenticationType": "SMS_OTP", + | "authenticationMethodId": "myAuthenticationID"}, + | "challengeData": { + | "otpMaxLength": 6, + | "otpFormat": "integer"}, + | "_links": { + | "authoriseTransaction": {"href": "/psd2/v1/payments/1234-wertiq-983/authorisations/123auth456"} + | } + |}""".stripMargin), HttpCode.`200`(callContext)) + } + } + } + + resourceDocs += ResourceDoc( + updateConsentsPsuDataUpdateAuthorisationConfirmation, + apiVersion, + nameOf(updateConsentsPsuDataUpdateAuthorisationConfirmation), + "PUT", + "/consents/CONSENTID/authorisations/AUTHORISATIONID", + "Update PSU Data for consents (authorisationConfirmation)", + generalUpdateConsentsPsuDataSummary(true), + json.parse("""{"confirmationCode":"confirmationCode"}"""), + json.parse("""{ + | "scaStatus": "finalised", + | "_links":{ + | "status": {"href":"/v1/payments/sepa-credit-transfers/qwer3456tzui7890/status"} + | } + | }""".stripMargin), + List(UserNotLoggedIn, UnknownError), + ApiTag("Account Information Service (AIS)") :: apiTagBerlinGroupM :: Nil + ) + + lazy val updateConsentsPsuDataUpdateAuthorisationConfirmation : OBPEndpoint = { + case "consents" :: consentId :: "authorisations" :: authorisationId :: Nil JsonPut jsonPut -> _ if checkAuthorisationConfirmation(jsonPut) => { + cc => + for { + (Full(u), callContext) <- authenticatedAccess(cc) + } yield { + (json.parse( + """{ + | "scaStatus": "finalised", + | "_links":{ + | "status": {"href":"/v1/payments/sepa-credit-transfers/qwer3456tzui7890/status"} + | } + |}""".stripMargin), + HttpCode.`200`(callContext)) } } } diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/CommonServicesApi.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/CommonServicesApi.scala index fcdd153683..0a32939b63 100644 --- a/obp-api/src/main/scala/code/api/berlin/group/v1_3/CommonServicesApi.scala +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/CommonServicesApi.scala @@ -30,12 +30,27 @@ object APIMethods_CommonServicesApi extends RestHelper { APIMethods_PaymentInitiationServicePISApi.getPaymentCancellationScaStatus :: APIMethods_PaymentInitiationServicePISApi.getPaymentInitiationAuthorisation :: APIMethods_PaymentInitiationServicePISApi.getPaymentInitiationScaStatus :: - APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisation :: - APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisation :: - APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuData :: - APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuData :: - APIMethods_AccountInformationServiceAISApi.startConsentAuthorisation :: - APIMethods_AccountInformationServiceAISApi.updateConsentsPsuData :: + APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationUpdatePsuAuthentication :: + APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationTransactionAuthorisation :: + APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationSelectPsuAuthenticationMethod :: + APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisationTransactionAuthorisation :: + APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisationUpdatePsuAuthentication :: + APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisationSelectPsuAuthenticationMethod :: + APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataUpdatePsuAuthentication :: + APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataTransactionAuthorisation :: + APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod :: + APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataAuthorisationConfirmation :: + APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataTransactionAuthorisation :: + APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataUpdatePsuAuthentication :: + APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataSelectPsuAuthenticationMethod :: + APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataAuthorisationConfirmation :: + APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationTransactionAuthorisation :: + APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationUpdatePsuAuthentication :: + APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationSelectPsuAuthenticationMethod :: + APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataTransactionAuthorisation :: + APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataUpdatePsuAuthentication :: + APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataUpdateAuthorisationConfirmation :: + APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataUpdateSelectPsuAuthenticationMethod :: APIMethods_AccountInformationServiceAISApi.getConsentScaStatus :: Nil @@ -49,13 +64,28 @@ object APIMethods_CommonServicesApi extends RestHelper { resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.getPaymentCancellationScaStatus).head resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.getPaymentInitiationAuthorisation).head resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.getPaymentInitiationScaStatus).head - resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisation).head - resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisation).head - resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuData).head - resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuData).head + resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationUpdatePsuAuthentication).head + resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationSelectPsuAuthenticationMethod).head + resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationTransactionAuthorisation).head + resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisationTransactionAuthorisation).head + resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisationUpdatePsuAuthentication).head + resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisationSelectPsuAuthenticationMethod).head + resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataUpdatePsuAuthentication).head + resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataTransactionAuthorisation).head + resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataAuthorisationConfirmation).head + resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod).head + resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataTransactionAuthorisation).head + resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataAuthorisationConfirmation).head + resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataSelectPsuAuthenticationMethod).head + resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataAuthorisationConfirmation).head - resourceDocs += APIMethods_AccountInformationServiceAISApi.resourceDocs.filter(_.partialFunction == APIMethods_AccountInformationServiceAISApi.startConsentAuthorisation ).head - resourceDocs += APIMethods_AccountInformationServiceAISApi.resourceDocs.filter(_.partialFunction == APIMethods_AccountInformationServiceAISApi.updateConsentsPsuData ).head + resourceDocs += APIMethods_AccountInformationServiceAISApi.resourceDocs.filter(_.partialFunction == APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationTransactionAuthorisation).head + resourceDocs += APIMethods_AccountInformationServiceAISApi.resourceDocs.filter(_.partialFunction == APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationUpdatePsuAuthentication).head + resourceDocs += APIMethods_AccountInformationServiceAISApi.resourceDocs.filter(_.partialFunction == APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationSelectPsuAuthenticationMethod).head + resourceDocs += APIMethods_AccountInformationServiceAISApi.resourceDocs.filter(_.partialFunction == APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataTransactionAuthorisation).head + resourceDocs += APIMethods_AccountInformationServiceAISApi.resourceDocs.filter(_.partialFunction == APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataUpdatePsuAuthentication).head + resourceDocs += APIMethods_AccountInformationServiceAISApi.resourceDocs.filter(_.partialFunction == APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataUpdateAuthorisationConfirmation).head + resourceDocs += APIMethods_AccountInformationServiceAISApi.resourceDocs.filter(_.partialFunction == APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataUpdateSelectPsuAuthenticationMethod).head resourceDocs += APIMethods_AccountInformationServiceAISApi.resourceDocs.filter(_.partialFunction == APIMethods_AccountInformationServiceAISApi.getConsentScaStatus).head } diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/JSONFactory_BERLIN_GROUP_1_3.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/JSONFactory_BERLIN_GROUP_1_3.scala index c71f08da15..70baf53481 100644 --- a/obp-api/src/main/scala/code/api/berlin/group/v1_3/JSONFactory_BERLIN_GROUP_1_3.scala +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/JSONFactory_BERLIN_GROUP_1_3.scala @@ -3,6 +3,7 @@ package code.api.berlin.group.v1_3 import java.text.SimpleDateFormat import java.util.Date +import code.api.berlin.group.v1_3.model._ import code.api.util.APIUtil._ import code.api.util.{APIUtil, ConsentJWT, CustomJsonFormats, JwtUtil} import code.bankconnectors.Connector @@ -10,10 +11,10 @@ import code.consent.ConsentTrait import code.model.ModeratedTransaction import com.openbankproject.commons.model.enums.AccountRoutingScheme import com.openbankproject.commons.model.{BankAccount, TransactionRequest, User, _} +import net.liftweb.common.Box.tryo import net.liftweb.common.{Box, Full} import net.liftweb.json import net.liftweb.json.{JValue, parse} - import scala.collection.immutable.List case class JvalueCaseClass(jvalueToCaseclass: JValue) @@ -218,6 +219,11 @@ object JSONFactory_BERLIN_GROUP_1_3 extends CustomJsonFormats { _links: ConsentLinksV13 ) + case class PutConsentResponseJson( + scaStatus: String, + _links: ConsentLinksV13 + ) + case class GetConsentResponseJson( access: ConsentAccessJson, @@ -231,6 +237,7 @@ object JSONFactory_BERLIN_GROUP_1_3 extends CustomJsonFormats { case class StartConsentAuthorisationJson( scaStatus: String, + authorisationId: String, pushMessage: String, _links: ScaStatusJsonV13 ) @@ -502,6 +509,12 @@ object JSONFactory_BERLIN_GROUP_1_3 extends CustomJsonFormats { _links= ConsentLinksV13(s"/v1.3/consents/${consent.consentId}/authorisations") ) } + def createPutConsentResponseJson(consent: ConsentTrait) : ScaStatusResponse = { + ScaStatusResponse( + scaStatus = consent.status.toLowerCase(), + _links = Some(LinksAll(scaStatus = Some(HrefType(Some(s"/v1.3/consents/${consent.consentId}/authorisations"))))) + ) + } def createGetConsentResponseJson(createdConsent: ConsentTrait) : GetConsentResponseJson = { val jsonWebTokenAsJValue: Box[ConsentJWT] = JwtUtil.getSignedPayloadAsJson(createdConsent.jsonWebToken) @@ -522,6 +535,7 @@ object JSONFactory_BERLIN_GROUP_1_3 extends CustomJsonFormats { def createStartConsentAuthorisationJson(consent: ConsentTrait, challenge: ChallengeTrait) : StartConsentAuthorisationJson = { StartConsentAuthorisationJson( scaStatus = challenge.scaStatus.map(_.toString).getOrElse("None"), + authorisationId = challenge.authenticationMethodId.getOrElse("None"), pushMessage = "started", //TODO Not implement how to fill this. _links = ScaStatusJsonV13(s"/v1.3/consents/${consent.consentId}/authorisations/${challenge.challengeId}")//TODO, Not sure, what is this for?? ) @@ -603,22 +617,56 @@ object JSONFactory_BERLIN_GROUP_1_3 extends CustomJsonFormats { ) } - def createStartPaymentCancellationAuthorisationsJson(challenges: List[ChallengeTrait], - paymentService: String, - paymentProduct: String, - paymentId: String): List[StartPaymentAuthorisationJson] = { - challenges.map(createStartPaymentCancellationAuthorisationJson(_, paymentService, paymentProduct, paymentId)) + def createUpdatePaymentPsuDataTransactionAuthorisationJson(challenge: ChallengeTrait) = { + ScaStatusResponse( + scaStatus = challenge.scaStatus.map(_.toString).getOrElse(""), + psuMessage = Some("Please check your SMS at a mobile device."), + _links = Some(LinksAll(scaStatus = Some(HrefType(Some(s"/v1.3/payments/sepa-credit-transfers/${challenge.challengeId}")))) + ) + ) } def createStartPaymentCancellationAuthorisationJson(challenge: ChallengeTrait, paymentService: String, paymentProduct: String, paymentId: String ) = { - StartPaymentAuthorisationJson( + ScaStatusResponse( scaStatus = challenge.scaStatus.map(_.toString).getOrElse(""), - authorisationId = challenge.challengeId, - psuMessage = "Please check your SMS at a mobile device.", - _links = ScaStatusJsonV13(s"/v1.3/${paymentService}/${paymentProduct}/${paymentId}/cancellation-authorisations/${challenge.challengeId}") + psuMessage = Some("Please check your SMS at a mobile device."), + _links = Some(LinksAll(scaStatus = Some(HrefType(Some(s"/v1.3/${paymentService}/${paymentProduct}/${paymentId}/cancellation-authorisations/${challenge.challengeId}")))) ) + ) } + + def createStartPaymentInitiationCancellationAuthorisation( + challenge: ChallengeTrait, + paymentService: String, + paymentProduct: String, + paymentId: String + ) = { + UpdatePsuAuthenticationResponse( + scaStatus = challenge.scaStatus.map(_.toString).getOrElse(""), + authorisationId = Some(challenge.challengeId), + psuMessage = Some("Please check your SMS at a mobile device."), + _links = Some(LinksUpdatePsuAuthentication( + scaStatus = Some(HrefType(Some(s"/v1.3/${paymentService}/${paymentProduct}/${paymentId}/cancellation-authorisations/${challenge.challengeId}")))) + ) + ) + } + + def checkTransactionAuthorisation(JsonPost: JValue) = tryo { + JsonPost.extract[TransactionAuthorisation] + }.isDefined + + def checkUpdatePsuAuthentication(JsonPost: JValue) = tryo { + JsonPost.extract[UpdatePsuAuthentication] + }.isDefined + + def checkSelectPsuAuthenticationMethod(JsonPost: JValue) = tryo { + JsonPost.extract[SelectPsuAuthenticationMethod] + }.isDefined + + def checkAuthorisationConfirmation(JsonPost: JValue) = tryo { + JsonPost.extract[AuthorisationConfirmation] + }.isDefined } diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/PaymentInitiationServicePISApi.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/PaymentInitiationServicePISApi.scala index 777a0ee68e..6028d42379 100644 --- a/obp-api/src/main/scala/code/api/berlin/group/v1_3/PaymentInitiationServicePISApi.scala +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/PaymentInitiationServicePISApi.scala @@ -1,13 +1,16 @@ package code.api.builder.PaymentInitiationServicePISApi import code.api.ResourceDocs1_4_0.SwaggerDefinitionsJSON.sepaCreditTransfersBerlinGroupV13 -import code.api.berlin.group.v1_3.JSONFactory_BERLIN_GROUP_1_3.{CancelPaymentResponseJson, CancelPaymentResponseLinks, LinkHrefJson, UpdatePaymentPsuDataJson, createCancellationTransactionRequestJson} +import code.api.berlin.group.v1_3.JSONFactory_BERLIN_GROUP_1_3.{CancelPaymentResponseJson, + CancelPaymentResponseLinks, LinkHrefJson, UpdatePaymentPsuDataJson, checkUpdatePsuAuthentication,checkAuthorisationConfirmation, + checkTransactionAuthorisation, checkSelectPsuAuthenticationMethod, createCancellationTransactionRequestJson} import code.api.berlin.group.v1_3.{JSONFactory_BERLIN_GROUP_1_3, JvalueCaseClass, OBP_BERLIN_GROUP_1_3} import code.api.util.APIUtil._ import code.api.util.ApiTag._ import code.api.util.ErrorMessages._ import code.api.util.NewStyle.HttpCode -import code.api.util.{ApiRole, ApiTag, NewStyle} +import code.api.util.{ApiRole, ApiTag, CallContext, NewStyle} +import code.api.berlin.group.v1_3.model._ import code.bankconnectors.Connector import code.fx.fx import code.api.Constant._ @@ -22,6 +25,8 @@ import com.openbankproject.commons.model.enums.ChallengeType.BERLINGROUP_PAYMENT import com.openbankproject.commons.model.enums.TransactionRequestStatus._ import com.openbankproject.commons.model.enums.{ChallengeType, StrongCustomerAuthenticationStatus, TransactionRequestStatus} import com.openbankproject.commons.util.ApiVersion +import net.liftweb +import net.liftweb.common.Box.tryo import net.liftweb.common.Full import net.liftweb.http.js.JE.JsRaw import net.liftweb.http.rest.RestHelper @@ -51,11 +56,23 @@ object APIMethods_PaymentInitiationServicePISApi extends RestHelper { getPaymentInitiationCancellationAuthorisationInformation :: getPaymentInitiationScaStatus :: getPaymentInitiationStatus :: - initiatePayment :: - startPaymentAuthorisation :: - startPaymentInitiationCancellationAuthorisation :: - updatePaymentCancellationPsuData :: - updatePaymentPsuData :: + initiatePayments :: + initiateBulkPayments :: + initiatePeriodicPayments :: + startPaymentAuthorisationUpdatePsuAuthentication :: + startPaymentAuthorisationTransactionAuthorisation :: + startPaymentAuthorisationSelectPsuAuthenticationMethod :: + startPaymentInitiationCancellationAuthorisationTransactionAuthorisation :: + startPaymentInitiationCancellationAuthorisationUpdatePsuAuthentication :: + startPaymentInitiationCancellationAuthorisationSelectPsuAuthenticationMethod :: + updatePaymentCancellationPsuDataUpdatePsuAuthentication :: + updatePaymentCancellationPsuDataTransactionAuthorisation :: + updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod :: + updatePaymentCancellationPsuDataAuthorisationConfirmation :: + updatePaymentPsuDataTransactionAuthorisation :: + updatePaymentPsuDataAuthorisationConfirmation :: + updatePaymentPsuDataSelectPsuAuthenticationMethod :: + updatePaymentPsuDataAuthorisationConfirmation :: Nil @@ -453,173 +470,288 @@ Check the transaction status of a payment initiation.""", """.stripMargin - resourceDocs += ResourceDoc( - initiatePayment, - apiVersion, - nameOf(initiatePayment), - "POST", - "/PAYMENT_SERVICE/PAYMENT_PRODUCT", - "Payment initiation request", - s"""${mockedDataText(false)} -This method is used to initiate a payment at the ASPSP. - -## Variants of Payment Initiation Requests - -This method to initiate a payment initiation at the ASPSP can be sent with either a JSON body or an pain.001 body depending on the payment product in the path. - -There are the following **payment products**: - - - Payment products with payment information in *JSON* format: - - ***sepa-credit-transfers*** - - ***instant-sepa-credit-transfers*** - - ***target-2-payments*** - - ***cross-border-credit-transfers*** - - Payment products with payment information in *pain.001* XML format: - - ***pain.001-sepa-credit-transfers*** - - ***pain.001-instant-sepa-credit-transfers*** - - ***pain.001-target-2-payments*** - - ***pain.001-cross-border-credit-transfers*** - - - Furthermore the request body depends on the **payment-service** - - ***payments***: A single payment initiation request. - - ***bulk-payments***: A collection of several payment iniatiation requests. - In case of a *pain.001* message there are more than one payments contained in the *pain.001 message. - In case of a *JSON* there are several JSON payment blocks contained in a joining list. - - ***periodic-payments***: - 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. + private val generalPaymentSummary = + s"""${mockedDataText(false)} + This method is used to initiate a payment at the ASPSP. -## Single and mulitilevel SCA Processes - -The Payment Initiation Requests are independent from the need of one ore 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. - - -$additionalInstructions - -""", - sepaCreditTransfersBerlinGroupV13, - json.parse(s"""{ - "transactionStatus": "RCVD", - "paymentId": "1234-wertiq-983", - "_links": - { - "scaRedirect": {"href": "$getServerUrl/otp?flow=payment&paymentService=payments&paymentProduct=sepa_credit_transfers&paymentId=b0472c21-6cea-4ee0-b036-3e253adb3b0b"}, - "self": {"href": "/v1.3/payments/sepa-credit-transfers/1234-wertiq-983"}, - "status": {"href": "/v1.3/payments/1234-wertiq-983/status"}, - "scaStatus": {"href": "/v1.3/payments/1234-wertiq-983/authorisations/123auth456"} - } - }"""), - List(UserNotLoggedIn, UnknownError), - ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil - ) - - lazy val initiatePayment : OBPEndpoint = { - case paymentService :: paymentProduct :: Nil JsonPost json -> _ => { - cc => - for { - (Full(u), callContext) <- authenticatedAccess(cc) - _ <- passesPsd2Pisp(callContext) - _ <- NewStyle.function.tryons(checkPaymentServerError(paymentService),400, callContext) { - PaymentServiceTypes.withName(paymentService.replaceAll("-","_")) - } - transactionRequestTypes <- NewStyle.function.tryons(checkPaymentProductError(paymentProduct),400, callContext) { - TransactionRequestTypes.withName(paymentProduct.replaceAll("-","_").toUpperCase) - } - - transDetailsJson <- NewStyle.function.tryons(s"$InvalidJsonFormat The Json body should be the $SepaCreditTransfersBerlinGroupV13 ", 400, callContext) { - json.extract[SepaCreditTransfersBerlinGroupV13] - } - - transDetailsSerialized <- NewStyle.function.tryons (s"$UnknownError Can not serialize in request Json ", 400, callContext){write(transDetailsJson)(Serialization.formats(NoTypeHints))} - - isValidAmountNumber <- NewStyle.function.tryons(s"$InvalidNumber Current input is ${transDetailsJson.instructedAmount.amount} ", 400, callContext) { - BigDecimal(transDetailsJson.instructedAmount.amount) - } - - _ <- Helper.booleanToFuture(s"${NotPositiveAmount} Current input is: '${isValidAmountNumber}'", cc=callContext) { - isValidAmountNumber > BigDecimal("0") - } - - // Prevent default value for transaction request type (at least). - _ <- Helper.booleanToFuture(s"${InvalidISOCurrencyCode} Current input is: '${transDetailsJson.instructedAmount.currency}'", cc=callContext) { - isValidCurrencyISOCode(transDetailsJson.instructedAmount.currency) - } - - _ <- NewStyle.function.isEnabledTransactionRequests(callContext) - fromAccountIban = transDetailsJson.debtorAccount.iban - toAccountIban = transDetailsJson.creditorAccount.iban - - (fromAccount, callContext) <- NewStyle.function.getBankAccountByIban(fromAccountIban, callContext) - (ibanChecker, callContext) <- NewStyle.function.validateAndCheckIbanNumber(toAccountIban, callContext) - _ <- Helper.booleanToFuture(invalidIban, cc=callContext) { ibanChecker.isValid == true } - (toAccount, callContext) <- NewStyle.function.getToBankAccountByIban(toAccountIban, callContext) - - viewId = ViewId(SYSTEM_READ_TRANSACTIONS_BERLIN_GROUP_VIEW_ID) - bankIdAccountId = BankIdAccountId(fromAccount.bankId, fromAccount.accountId) - view <- NewStyle.function.checkAccountAccessAndGetView(viewId, bankIdAccountId, Full(u), callContext) - - _ <- if (view.canAddTransactionRequestToAnyAccount) - Future.successful(Full(Unit)) - else - NewStyle.function.hasEntitlement(fromAccount.bankId.value, u.userId, ApiRole.canCreateAnyTransactionRequest, callContext, InsufficientAuthorisationToCreateTransactionRequest) - - // Prevent default value for transaction request type (at least). - _ <- Helper.booleanToFuture(s"From Account Currency is ${fromAccount.currency}, but Requested Transaction Currency is: ${transDetailsJson.instructedAmount.currency}", cc=callContext) { - transDetailsJson.instructedAmount.currency == fromAccount.currency - } - - amountOfMoneyJSON = transDetailsJson.instructedAmount + ## Variants of Payment Initiation Requests + + This method to initiate a payment initiation at the ASPSP can be sent with either a JSON body or an pain.001 body depending on the payment product in the path. + + There are the following **payment products**: + + - Payment products with payment information in *JSON* format: + - ***sepa-credit-transfers*** + - ***instant-sepa-credit-transfers*** + - ***target-2-payments*** + - ***cross-border-credit-transfers*** + - Payment products with payment information in *pain.001* XML format: + - ***pain.001-sepa-credit-transfers*** + - ***pain.001-instant-sepa-credit-transfers*** + - ***pain.001-target-2-payments*** + - ***pain.001-cross-border-credit-transfers*** + + - Furthermore the request body depends on the **payment-service** + - ***payments***: A single payment initiation request. + - ***bulk-payments***: A collection of several payment iniatiation requests. + In case of a *pain.001* message there are more than one payments contained in the *pain.001 message. + In case of a *JSON* there are several JSON payment blocks contained in a joining list. + - ***periodic-payments***: + 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 ore 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. + + + $additionalInstructions + + """ + def initiatePaymentImplementation(paymentService: String, paymentProduct: String, json: liftweb.json.JValue, cc: CallContext) = { + for { + (Full(u), callContext) <- authenticatedAccess(cc) + _ <- passesPsd2Pisp(callContext) + _ <- NewStyle.function.tryons(checkPaymentServerError(paymentService), 400, callContext) { + PaymentServiceTypes.withName(paymentService.replaceAll("-", "_")) + } + transactionRequestTypes <- NewStyle.function.tryons(checkPaymentProductError(paymentProduct), 400, callContext) { + TransactionRequestTypes.withName(paymentProduct.replaceAll("-", "_").toUpperCase) + } + + transDetailsJson <- NewStyle.function.tryons(s"$InvalidJsonFormat The Json body should be the $SepaCreditTransfersBerlinGroupV13 ", 400, callContext) { + json.extract[SepaCreditTransfersBerlinGroupV13] + } + + transDetailsSerialized <- NewStyle.function.tryons(s"$UnknownError Can not serialize in request Json ", 400, callContext) { + write(transDetailsJson)(Serialization.formats(NoTypeHints)) + } + + isValidAmountNumber <- NewStyle.function.tryons(s"$InvalidNumber Current input is ${transDetailsJson.instructedAmount.amount} ", 400, callContext) { + BigDecimal(transDetailsJson.instructedAmount.amount) + } + + _ <- Helper.booleanToFuture(s"${NotPositiveAmount} Current input is: '${isValidAmountNumber}'", cc = callContext) { + isValidAmountNumber > BigDecimal("0") + } + + // Prevent default value for transaction request type (at least). + _ <- Helper.booleanToFuture(s"${InvalidISOCurrencyCode} Current input is: '${transDetailsJson.instructedAmount.currency}'", cc = callContext) { + isValidCurrencyISOCode(transDetailsJson.instructedAmount.currency) + } + + _ <- NewStyle.function.isEnabledTransactionRequests(callContext) + fromAccountIban = transDetailsJson.debtorAccount.iban + toAccountIban = transDetailsJson.creditorAccount.iban + + (fromAccount, callContext) <- NewStyle.function.getBankAccountByIban(fromAccountIban, callContext) + (ibanChecker, callContext) <- NewStyle.function.validateAndCheckIbanNumber(toAccountIban, callContext) + _ <- Helper.booleanToFuture(invalidIban, cc = callContext) { + ibanChecker.isValid == true + } + (toAccount, callContext) <- NewStyle.function.getToBankAccountByIban(toAccountIban, callContext) + + viewId = ViewId(SYSTEM_READ_TRANSACTIONS_BERLIN_GROUP_VIEW_ID) + bankIdAccountId = BankIdAccountId(fromAccount.bankId, fromAccount.accountId) + view <- NewStyle.function.checkAccountAccessAndGetView(viewId, bankIdAccountId, Full(u), callContext) + + _ <- if (view.canAddTransactionRequestToAnyAccount) + Future.successful(Full(Unit)) + else + NewStyle.function.hasEntitlement(fromAccount.bankId.value, u.userId, ApiRole.canCreateAnyTransactionRequest, callContext, InsufficientAuthorisationToCreateTransactionRequest) + + // Prevent default value for transaction request type (at least). + _ <- Helper.booleanToFuture(s"From Account Currency is ${fromAccount.currency}, but Requested Transaction Currency is: ${transDetailsJson.instructedAmount.currency}", cc = callContext) { + transDetailsJson.instructedAmount.currency == fromAccount.currency + } + + amountOfMoneyJSON = transDetailsJson.instructedAmount + + (createdTransactionRequest, callContext) <- transactionRequestTypes match { + case TransactionRequestTypes.SEPA_CREDIT_TRANSFERS => { + for { + (createdTransactionRequest, callContext) <- NewStyle.function.createTransactionRequestv400( + u, + ViewId("Owner"), //This is the default + fromAccount, + toAccount, + TransactionRequestType(transactionRequestTypes.toString), + TransactionRequestCommonBodyJSONCommons( + amountOfMoneyJSON, + "" + ), + transDetailsSerialized, + "", + Some(BERLINGROUP_PAYMENT_CHALLENGE), + None, + None, + Some(transDetailsJson), + callContext + ) //in SANDBOX_TAN, ChargePolicy set default "SHARED" + } yield (createdTransactionRequest, callContext) + } + } + } yield { + (JSONFactory_BERLIN_GROUP_1_3.createTransactionRequestJson(createdTransactionRequest), HttpCode.`201`(callContext)) + } + } - (createdTransactionRequest,callContext) <- transactionRequestTypes match { - case TransactionRequestTypes.SEPA_CREDIT_TRANSFERS => { - for { - (createdTransactionRequest, callContext) <- NewStyle.function.createTransactionRequestv400( - u, - ViewId("Owner"),//This is the default - fromAccount, - toAccount, - TransactionRequestType(transactionRequestTypes.toString), - TransactionRequestCommonBodyJSONCommons( - amountOfMoneyJSON, - "" - ), - transDetailsSerialized, - "", - Some(BERLINGROUP_PAYMENT_CHALLENGE), - None, - None, - Some(transDetailsJson), - callContext - ) //in SANDBOX_TAN, ChargePolicy set default "SHARED" - } yield (createdTransactionRequest, callContext) - } - } - } yield { - (JSONFactory_BERLIN_GROUP_1_3.createTransactionRequestJson(createdTransactionRequest), HttpCode.`201`(callContext)) - } - } + + resourceDocs += ResourceDoc( + initiatePayments, + apiVersion, + nameOf(initiatePayments), + "POST", + "/payments/PAYMENT_PRODUCT", + "Payment initiation request(payments)", + generalPaymentSummary, + sepaCreditTransfersBerlinGroupV13, + json.parse(s"""{ + "transactionStatus": "RCVD", + "paymentId": "1234-wertiq-983", + "_links": + { + "scaRedirect": {"href": "$getServerUrl/otp?flow=payment&paymentService=payments&paymentProduct=sepa_credit_transfers&paymentId=b0472c21-6cea-4ee0-b036-3e253adb3b0b"}, + "self": {"href": "/v1.3/payments/sepa-credit-transfers/1234-wertiq-983"}, + "status": {"href": "/v1.3/payments/1234-wertiq-983/status"}, + "scaStatus": {"href": "/v1.3/payments/1234-wertiq-983/authorisations/123auth456"} + } + }"""), + List(UserNotLoggedIn, UnknownError), + ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil + ) + + lazy val initiatePayments : OBPEndpoint = { + case "payments" :: paymentProduct :: Nil JsonPost json -> _ => { + cc => + initiatePaymentImplementation("payments", paymentProduct, json, cc) } - - resourceDocs += ResourceDoc( - startPaymentAuthorisation, - apiVersion, - nameOf(startPaymentAuthorisation), - "POST", - "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations", - "Start the authorisation process for a payment initiation", - s"""${mockedDataText(false)} + } + + + resourceDocs += ResourceDoc( + initiatePeriodicPayments, + apiVersion, + nameOf(initiatePeriodicPayments), + "POST", + "/periodic-payments/PAYMENT_PRODUCT", + "Payment initiation request(periodic-payments)", + generalPaymentSummary, + json.parse(s"""{ + "instructedAmount": { + "currency": "EUR", + "amount": "123" + }, + "debtorAccount": { + "iban": "DE40100100103307118608" + }, + "creditorName": "Merchant123", + "creditorAccount": { + "iban": "DE23100120020123456789" + }, + "remittanceInformationUnstructured": "Ref Number Abonnement", + "startDate": "2018-03-01", + "executionRule": "preceding", + "frequency": "Monthly", + "dayOfExecution": "01" + }"""), + json.parse(s"""{ + "transactionStatus": "RCVD", + "paymentId": "1234-wertiq-983", + "_links": + { + "scaRedirect": {"href": "$getServerUrl/otp?flow=payment&paymentService=payments&paymentProduct=sepa_credit_transfers&paymentId=b0472c21-6cea-4ee0-b036-3e253adb3b0b"}, + "self": {"href": "/v1.3/periodic-payments/instant-sepa-credit-transfer/1234-wertiq-983"}, + "status": {"href": "/v1.3/periodic-payments/1234-wertiq-983/status"}, + "scaStatus": {"href": "/v1.3/periodic-payments/1234-wertiq-983/authorisations/123auth456"} + } + }"""), + List(UserNotLoggedIn, UnknownError), + ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil + ) + + lazy val initiatePeriodicPayments : OBPEndpoint = { + case "periodic-payments" :: paymentProduct :: Nil JsonPost json -> _ => { + cc => + initiatePaymentImplementation("periodic-payments", paymentProduct, json, cc) + } + } + + resourceDocs += ResourceDoc( + initiateBulkPayments, + apiVersion, + nameOf(initiateBulkPayments), + "POST", + "/bulk-payments/PAYMENT_PRODUCT", + "Payment initiation request(bulk-payments)", + generalPaymentSummary, + json.parse(s"""{ + "batchBookingPreferred": "true", + "debtorAccount": { + "iban": "DE40100100103307118608" + }, + "paymentInformationId": "my-bulk-identification-1234", + "requestedExecutionDate": "2018-08-01", + "payments": [ + { + "instructedAmount": { + "currency": "EUR", + "amount": "123.50" + }, + "creditorName": "Merchant123", + "creditorAccount": { + "iban": "DE02100100109307118603" + }, + "remittanceInformationUnstructured": "Ref Number Merchant 1" + }, + { + "instructedAmount": { + "currency": "EUR", + "amount": "34.10" + }, + "creditorName": "Merchant456", + "creditorAccount": { + "iban": "FR7612345987650123456789014" + }, + "remittanceInformationUnstructured": "Ref Number Merchant 2" + } + ] + }"""), + json.parse(s"""{ + "transactionStatus": "RCVD", + "paymentId": "1234-wertiq-983", + "_links": + { + "scaRedirect": {"href": "$getServerUrl/otp?flow=payment&paymentService=payments&paymentProduct=sepa_credit_transfers&paymentId=b0472c21-6cea-4ee0-b036-3e253adb3b0b"}, + "self": {"href": "/v1.3/bulk-payments/sepa-credit-transfers/1234-wertiq-983"}, + "status": {"href": "/v1.3/bulk-payments/1234-wertiq-983/status"}, + "scaStatus": {"href": "/v1.3/bulk-payments/1234-wertiq-983/authorisations/123auth456"} + } + }"""), + List(UserNotLoggedIn, UnknownError), + ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil + ) + + lazy val initiateBulkPayments : OBPEndpoint = { + case "bulk-payments" :: paymentProduct :: Nil JsonPost json -> _ => { + cc => + initiatePaymentImplementation("bulk-payments", paymentProduct, json, cc) + } + } + + def generalStartPaymentAuthorisationSummary(isMockedDate: Boolean) = s"""${mockedDataText(isMockedDate)} Create an authorisation sub-resource and start the authorisation process. The message might in addition transmit authentication and authorisation related data. @@ -652,8 +784,23 @@ This applies in the following scenarios: * The related payment cancellation request cannot be applied yet since a multilevel SCA is mandate for executing the cancellation. * The signing basket needs to be authorised yet. -""", - emptyObjectJson, +""" + + resourceDocs += ResourceDoc( + startPaymentAuthorisationUpdatePsuAuthentication, + apiVersion, + nameOf(startPaymentAuthorisationUpdatePsuAuthentication), + "POST", + "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations", + "Start the authorisation process for a payment initiation (updatePsuAuthentication)", + generalStartPaymentAuthorisationSummary(true), + json.parse( + """{ + | "scaStatus": "finalised", + | "_links":{ + | "status": {"href":"/v1/payments/sepa-credit-transfers/qwer3456tzui7890/status"} + | } + | }""".stripMargin), json.parse("""{ "challengeData": { "scaStatus": "received", @@ -668,48 +815,131 @@ This applies in the following scenarios: ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil ) - lazy val startPaymentAuthorisation : OBPEndpoint = { - case paymentService :: paymentProduct :: paymentId :: "authorisations" :: Nil JsonPost json -> _ => { + + lazy val startPaymentAuthorisationUpdatePsuAuthentication : OBPEndpoint = { + case paymentService :: paymentProduct :: paymentId :: "authorisations" :: Nil JsonPost json -> _ if checkUpdatePsuAuthentication(json) => { + cc => + for { + (_, callContext) <- authenticatedAccess(cc) + } yield { + (liftweb.json.parse("""{ + "challengeData": { + "scaStatus": "received", + "authorisationId": "88695566-6642-46d5-9985-0d824624f507", + "psuMessage": "Please check your SMS at a mobile device.", + "_links": { + "scaStatus": "/v1.3/payments/sepa-credit-transfers/88695566-6642-46d5-9985-0d824624f507" + } + } + }"""), HttpCode.`201`(callContext)) + } + } + } + + resourceDocs += ResourceDoc( + startPaymentAuthorisationSelectPsuAuthenticationMethod, + apiVersion, + nameOf(startPaymentAuthorisationSelectPsuAuthenticationMethod), + "POST", + "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations", + "Start the authorisation process for a payment initiation (selectPsuAuthenticationMethod)", + generalStartPaymentAuthorisationSummary(true), + json.parse("""{"authenticationMethodId":""}"""), + json.parse("""{ + "challengeData": { + "scaStatus": "received", + "authorisationId": "88695566-6642-46d5-9985-0d824624f507", + "psuMessage": "Please check your SMS at a mobile device.", + "_links": { + "scaStatus": "/v1.3/payments/sepa-credit-transfers/88695566-6642-46d5-9985-0d824624f507" + } + } + }"""), + List(UserNotLoggedIn, UnknownError), + ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil + ) + + lazy val startPaymentAuthorisationSelectPsuAuthenticationMethod : OBPEndpoint = { + case paymentService :: paymentProduct :: paymentId :: "authorisations" :: Nil JsonPost json -> _ if checkSelectPsuAuthenticationMethod(json) => { cc => for { (Full(u), callContext) <- authenticatedAccess(cc) - _ <- passesPsd2Pisp(callContext) - _ <- NewStyle.function.tryons(checkPaymentServerError(paymentService),400, callContext) { - PaymentServiceTypes.withName(paymentService.replaceAll("-","_")) - } - _ <- NewStyle.function.tryons(checkPaymentProductError(paymentProduct),400, callContext) { - TransactionRequestTypes.withName(paymentProduct.replaceAll("-","_").toUpperCase) - } - (_, callContext) <- NewStyle.function.getTransactionRequestImpl(TransactionRequestId(paymentId), callContext) - - (challenges, callContext) <- NewStyle.function.createChallengesC2( - List(u.userId), - ChallengeType.BERLINGROUP_PAYMENT_CHALLENGE, - Some(paymentId), - getScaMethodAtInstance(SEPA_CREDIT_TRANSFERS.toString).toOption, - Some(StrongCustomerAuthenticationStatus.received), - None, - None, - callContext - ) - //NOTE: in OBP it support multiple challenges, but in Berlin Group it has only one challenge. The following guard is to make sure it return the 1st challenge properly. - challenge <- NewStyle.function.tryons(InvalidConnectorResponseForCreateChallenge,400, callContext) { - challenges.head - } } yield { - (JSONFactory_BERLIN_GROUP_1_3.createStartPaymentAuthorisationJson(challenge), callContext) + (liftweb.json.parse( + """{ + "challengeData": { + "scaStatus": "received", + "authorisationId": "88695566-6642-46d5-9985-0d824624f507", + "psuMessage": "Please check your SMS at a mobile device.", + "_links": { + "scaStatus": "/v1.3/payments/sepa-credit-transfers/88695566-6642-46d5-9985-0d824624f507" + } + } + }"""), HttpCode.`201`(callContext)) } } - } + } - resourceDocs += ResourceDoc( - startPaymentInitiationCancellationAuthorisation, - apiVersion, - nameOf(startPaymentInitiationCancellationAuthorisation), - "POST", - "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations", - "Start the authorisation process for the cancellation of the addressed payment", - s"""${mockedDataText(false)} + resourceDocs += ResourceDoc( + startPaymentAuthorisationTransactionAuthorisation, + apiVersion, + nameOf(startPaymentAuthorisationTransactionAuthorisation), + "POST", + "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations", + "Start the authorisation process for a payment initiation (transactionAuthorisation)", + generalStartPaymentAuthorisationSummary(false), + json.parse("""{"scaAuthenticationData":"123"}"""), + json.parse("""{ + "challengeData": { + "scaStatus": "received", + "authorisationId": "88695566-6642-46d5-9985-0d824624f507", + "psuMessage": "Please check your SMS at a mobile device.", + "_links": { + "scaStatus": "/v1.3/payments/sepa-credit-transfers/88695566-6642-46d5-9985-0d824624f507" + } + } + }"""), + List(UserNotLoggedIn, UnknownError), + ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil + ) + + + lazy val startPaymentAuthorisationTransactionAuthorisation : OBPEndpoint = { + case paymentService :: paymentProduct :: paymentId :: "authorisations" :: Nil JsonPost json -> _ if checkTransactionAuthorisation(json) => { + cc => + for { + (Full(u), callContext) <- authenticatedAccess(cc) + _ <- passesPsd2Pisp(callContext) + _ <- NewStyle.function.tryons(checkPaymentServerError(paymentService), 400, callContext) { + PaymentServiceTypes.withName(paymentService.replaceAll("-", "_")) + } + _ <- NewStyle.function.tryons(checkPaymentProductError(paymentProduct), 400, callContext) { + TransactionRequestTypes.withName(paymentProduct.replaceAll("-", "_").toUpperCase) + } + (_, callContext) <- NewStyle.function.getTransactionRequestImpl(TransactionRequestId(paymentId), callContext) + + (challenges, callContext) <- NewStyle.function.createChallengesC2( + List(u.userId), + ChallengeType.BERLINGROUP_PAYMENT_CHALLENGE, + Some(paymentId), + getScaMethodAtInstance(SEPA_CREDIT_TRANSFERS.toString).toOption, + Some(StrongCustomerAuthenticationStatus.received), + None, + None, + callContext + ) + //NOTE: in OBP it support multiple challenges, but in Berlin Group it has only one challenge. The following guard is to make sure it return the 1st challenge properly. + challenge <- NewStyle.function.tryons(InvalidConnectorResponseForCreateChallenge, 400, callContext) { + challenges.head + } + } yield { + (JSONFactory_BERLIN_GROUP_1_3.createStartPaymentAuthorisationJson(challenge), HttpCode.`201`(callContext)) + } + } + } + + def generalStartPaymentInitiationCancellationAuthorisationSummary (isMockedDate:Boolean) = + s"""${mockedDataText(isMockedDate)} Creates an authorisation sub-resource and start the authorisation process of the cancellation of the addressed payment. The message might in addition transmit authentication and authorisation related data. @@ -727,37 +957,48 @@ or cancellation sub-resource. This applies in the following scenarios: - * The ASPSP has indicated with an 'startAuthorisation' hyperlink in the preceeding Payment - Initiation Response that an explicit start of the authorisation process is needed by the TPP. - The 'startAuthorisation' hyperlink can transport more information about data which needs to be - uploaded by using the extended forms. - * 'startAuthorisationWithPsuIdentfication', - * 'startAuthorisationWithPsuAuthentication' #TODO - * 'startAuthorisationWithAuthentciationMethodSelection' - * The related payment initiation cannot yet be executed since a multilevel SCA is mandated. - * The ASPSP has indicated with an 'startAuthorisation' hyperlink in the preceeding - Payment Cancellation Response that an explicit start of the authorisation process is needed by the TPP. - The 'startAuthorisation' hyperlink can transport more information about data which needs to be uploaded - by using the extended forms as indicated above. - * The related payment cancellation request cannot be applied yet since a multilevel SCA is mandate for - executing the cancellation. - * The signing basket needs to be authorised yet. -""", - emptyObjectJson, +* The ASPSP has indicated with an 'startAuthorisation' hyperlink in the preceeding Payment + Initiation Response that an explicit start of the authorisation process is needed by the TPP. + The 'startAuthorisation' hyperlink can transport more information about data which needs to be + uploaded by using the extended forms. + * 'startAuthorisationWithPsuIdentfication', + * 'startAuthorisationWithPsuAuthentication' #TODO + * 'startAuthorisationWithAuthentciationMethodSelection' +* The related payment initiation cannot yet be executed since a multilevel SCA is mandated. +* The ASPSP has indicated with an 'startAuthorisation' hyperlink in the preceeding + Payment Cancellation Response that an explicit start of the authorisation process is needed by the TPP. + The 'startAuthorisation' hyperlink can transport more information about data which needs to be uploaded + by using the extended forms as indicated above. +* The related payment cancellation request cannot be applied yet since a multilevel SCA is mandate for + executing the cancellation. +* The signing basket needs to be authorised yet. +""" + + resourceDocs += ResourceDoc( + startPaymentInitiationCancellationAuthorisationTransactionAuthorisation, + apiVersion, + nameOf(startPaymentInitiationCancellationAuthorisationTransactionAuthorisation), + "POST", + "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations", + "Start the authorisation process for the cancellation of the addressed payment (transactionAuthorisation)", + generalStartPaymentInitiationCancellationAuthorisationSummary(false), + json.parse("""{"scaAuthenticationData":""}"""), json.parse("""{ - "scaStatus":"received", - "authorisationId":"8a49b79b-b400-4e6b-b88d-637c3a71479d", - "psuMessage":"Please check your SMS at a mobile device.", - "_links":{ - "scaStatus":"/v1.3/payments/sepa-credit-transfers/PAYMENT_ID/8a49b79b-b400-4e6b-b88d-637c3a71479d" - } - }"""), + "scaStatus": "received", + "authorisationId": "123auth456", + "psuMessage": "Please use your BankApp for transaction Authorisation.", + "_links": { + "scaStatus": { + "href": "/v1.3/payments/qwer3456tzui7890/authorisations/123auth456" + } + } + }"""), List(UserNotLoggedIn, UnknownError), ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil ) - lazy val startPaymentInitiationCancellationAuthorisation : OBPEndpoint = { - case paymentService :: paymentProduct :: paymentId:: "cancellation-authorisations" :: Nil JsonPost _ => { + lazy val startPaymentInitiationCancellationAuthorisationTransactionAuthorisation : OBPEndpoint = { + case paymentService :: paymentProduct :: paymentId:: "cancellation-authorisations" :: Nil JsonPost json -> _ if checkTransactionAuthorisation(json)=> { cc => for { (Full(u), callContext) <- authenticatedAccess(cc) @@ -787,24 +1028,110 @@ This applies in the following scenarios: challenges.head } } yield { - (JSONFactory_BERLIN_GROUP_1_3.createStartPaymentCancellationAuthorisationJson( + (JSONFactory_BERLIN_GROUP_1_3.createStartPaymentInitiationCancellationAuthorisation( challenge, paymentService, paymentProduct, paymentId - ), callContext) + ), HttpCode.`201`(callContext)) } } } - + resourceDocs += ResourceDoc( - updatePaymentCancellationPsuData, + startPaymentInitiationCancellationAuthorisationUpdatePsuAuthentication, apiVersion, - nameOf(updatePaymentCancellationPsuData), - "PUT", - "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations/CANCELLATIONID", - "Update PSU Data for payment initiation cancellation", - s"""${mockedDataText(false)} + nameOf(startPaymentInitiationCancellationAuthorisationUpdatePsuAuthentication), + "POST", + "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations", + "Start the authorisation process for the cancellation of the addressed payment (updatePsuAuthentication)", + generalStartPaymentInitiationCancellationAuthorisationSummary(true), + json.parse("""{ + "psuData": { + "password": "start12" + } + }"""), + json.parse("""{ + "scaStatus": "received", + "authorisationId": "123auth456", + "psuMessage": "Please use your BankApp for transaction Authorisation.", + "_links": { + "scaStatus": { + "href": "/v1.3/payments/qwer3456tzui7890/authorisations/123auth456" + } + } + }"""), + List(UserNotLoggedIn, UnknownError), + ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil + ) + + lazy val startPaymentInitiationCancellationAuthorisationUpdatePsuAuthentication : OBPEndpoint = { + case paymentService :: paymentProduct :: paymentId:: "cancellation-authorisations" :: Nil JsonPost json -> _ if checkUpdatePsuAuthentication(json)=> { + cc => + for { + (Full(u), callContext) <- authenticatedAccess(cc) + } yield { + (liftweb.json.parse( + """{ + "scaStatus": "received", + "authorisationId": "123auth456", + "psuMessage": "Please use your BankApp for transaction Authorisation.", + "_links": { + "scaStatus": { + "href": "/v1.3/payments/qwer3456tzui7890/authorisations/123auth456" + } + } + }"""), HttpCode.`201`(callContext)) + } + } + } + + resourceDocs += ResourceDoc( + startPaymentInitiationCancellationAuthorisationSelectPsuAuthenticationMethod, + apiVersion, + nameOf(startPaymentInitiationCancellationAuthorisationSelectPsuAuthenticationMethod), + "POST", + "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations", + "Start the authorisation process for the cancellation of the addressed payment (selectPsuAuthenticationMethod)", + generalStartPaymentInitiationCancellationAuthorisationSummary(true), + json.parse("""{"authenticationMethodId":""}"""), + json.parse("""{ + "scaStatus": "received", + "authorisationId": "123auth456", + "psuMessage": "Please use your BankApp for transaction Authorisation.", + "_links": { + "scaStatus": { + "href": "/v1.3/payments/qwer3456tzui7890/authorisations/123auth456" + } + } + }"""), + List(UserNotLoggedIn, UnknownError), + ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil + ) + + lazy val startPaymentInitiationCancellationAuthorisationSelectPsuAuthenticationMethod : OBPEndpoint = { + case paymentService :: paymentProduct :: paymentId:: "cancellation-authorisations" :: Nil JsonPost json -> _ if checkSelectPsuAuthenticationMethod(json)=> { + cc => + for { + (Full(u), callContext) <- authenticatedAccess(cc) + } yield { + (liftweb.json.parse( + """{ + "scaStatus": "received", + "authorisationId": "123auth456", + "psuMessage": "Please use your BankApp for transaction Authorisation.", + "_links": { + "scaStatus": { + "href": "/v1.3/payments/qwer3456tzui7890/authorisations/123auth456" + } + } + }"""), HttpCode.`201`(callContext)) + } + } + } + + def generalUpdatePaymentCancellationPsuDataSummary (isMockedData: Boolean)= + s"""${mockedDataText(isMockedData)} This method updates PSU data on the cancellation authorisation resource if needed. It may authorise a cancellation of the payment within the Embedded SCA Approach where needed. @@ -817,17 +1144,17 @@ There are several possible Update PSU Data requests in the context of a cancella which depends on the SCA approach: * Redirect SCA Approach: - A specific Update PSU Data Request is applicable for - * the selection of authentication methods, before choosing the actual SCA approach. +A specific Update PSU Data Request is applicable for + * the selection of authentication methods, before choosing the actual SCA approach. * Decoupled SCA Approach: - A specific Update PSU Data Request is only applicable for - * adding the PSU Identification, if not provided yet in the Payment Initiation Request or the Account Information Consent Request, or if no OAuth2 access token is used, or - * the selection of authentication methods. +A specific Update PSU Data Request is only applicable for +* adding the PSU Identification, if not provided yet in the Payment Initiation Request or the Account Information Consent Request, or if no OAuth2 access token is used, or +* the selection of authentication methods. * Embedded SCA Approach: - The Update PSU Data Request might be used - * to add credentials as a first factor authentication data of the PSU and - * to select the authentication method and - * transaction authorisation. +The Update PSU Data Request might be used +* to add credentials as a first factor authentication data of the PSU and +* to select the authentication method and +* transaction authorisation. The SCA Approach might depend on the chosen SCA method. For that reason, the following possible Update PSU Data request can apply to all SCA approaches: @@ -835,21 +1162,29 @@ For that reason, the following possible Update PSU Data request can apply to all * Select an SCA method in case of several SCA methods are available for the customer. There are the following request types on this access path: - * Update PSU Identification - * Update PSU Authentication - * Select PSU Autorization Method - WARNING: This method need a reduced header, - therefore many optional elements are not present. - Maybe in a later version the access path will change. - * Transaction Authorisation - WARNING: This method need a reduced header, - therefore many optional elements are not present. - Maybe in a later version the access path will change. -""", +* Update PSU Identification +* Update PSU Authentication +* Select PSU Autorization Method + WARNING: This method need a reduced header, + therefore many optional elements are not present. + Maybe in a later version the access path will change. +* Transaction Authorisation + WARNING: This method need a reduced header, + therefore many optional elements are not present. + Maybe in a later version the access path will change. +""" + + resourceDocs += ResourceDoc( + updatePaymentCancellationPsuDataTransactionAuthorisation, + apiVersion, + nameOf(updatePaymentCancellationPsuDataTransactionAuthorisation), + "PUT", + "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations/AUTHORISATION_ID", + "Update PSU Data for payment initiation cancellation (transactionAuthorisation)", + generalUpdatePaymentCancellationPsuDataSummary(false), json.parse("""{"scaAuthenticationData":"123"}"""), json.parse("""{ "scaStatus":"finalised", - "authorisationId":"4f4a8b7f-9968-4183-92ab-ca512b396bfc", "psuMessage":"Please check your SMS at a mobile device.", "_links":{ "scaStatus":"/v1.3/payments/sepa-credit-transfers/PAYMENT_ID/4f4a8b7f-9968-4183-92ab-ca512b396bfc" @@ -858,16 +1193,16 @@ There are the following request types on this access path: List(UserNotLoggedIn, UnknownError), ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil ) - - lazy val updatePaymentCancellationPsuData : OBPEndpoint = { - case paymentService :: paymentProduct :: paymentId:: "cancellation-authorisations" :: cancellationId :: Nil JsonPut json -> _ => { + + lazy val updatePaymentCancellationPsuDataTransactionAuthorisation : OBPEndpoint = { + case paymentService :: paymentProduct :: paymentId:: "cancellation-authorisations" :: authorisationId :: Nil JsonPut json -> _ if checkTransactionAuthorisation(json) => { cc => for { (_, callContext) <- authenticatedAccess(cc) _ <- passesPsd2Pisp(callContext) failMsg = s"$InvalidJsonFormat The Json body should be the $UpdatePaymentPsuDataJson " - updatePaymentPsuDataJson <- NewStyle.function.tryons(failMsg, 400, callContext) { - json.extract[UpdatePaymentPsuDataJson] + transactionAuthorisation <- NewStyle.function.tryons(failMsg, 400, callContext) { + json.extract[TransactionAuthorisation] } _ <- NewStyle.function.tryons(checkPaymentServerError(paymentService),400, callContext) { @@ -889,8 +1224,8 @@ There are the following request types on this access path: ChallengeType.BERLINGROUP_PAYMENT_CHALLENGE, Some(paymentId), None, - cancellationId, - updatePaymentPsuDataJson.scaAuthenticationData, + authorisationId, + transactionAuthorisation.scaAuthenticationData, callContext ) @@ -916,16 +1251,131 @@ There are the following request types on this access path: ), callContext) } } - } - + } + resourceDocs += ResourceDoc( - updatePaymentPsuData, + updatePaymentCancellationPsuDataUpdatePsuAuthentication, apiVersion, - nameOf(updatePaymentPsuData), + nameOf(updatePaymentCancellationPsuDataUpdatePsuAuthentication), "PUT", - "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations/AUTHORISATION_ID", - "Update PSU data for payment initiation", - s"""${mockedDataText(false)} + "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations/AUTHORISATION_ID", + "Update PSU Data for payment initiation cancellation (updatePsuAuthentication)", + generalUpdatePaymentCancellationPsuDataSummary(true), + json.parse("""{ "psuData":{"password":"start12" }}"""), + json.parse("""{ + "scaStatus": "psuAuthenticated", + "_links": { + "authoriseTransaction": {"href": "/psd2/v1.3/payments/1234-wertiq-983/authorisations/123auth456"} + } + }"""), + List(UserNotLoggedIn, UnknownError), + ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil + ) + + lazy val updatePaymentCancellationPsuDataUpdatePsuAuthentication : OBPEndpoint = { + case paymentService :: paymentProduct :: paymentId:: "cancellation-authorisations" :: authorisationId :: Nil JsonPut json -> _ if checkUpdatePsuAuthentication(json)=> { + cc => + for { + (_, callContext) <- authenticatedAccess(cc) + } yield { + (net.liftweb.json.parse( + """{ + "scaStatus": "psuAuthenticated", + "_links": { + "authoriseTransaction": {"href": "/psd2/v1.3/payments/1234-wertiq-983/authorisations/123auth456"} + } + }"""), callContext) + } + } + } + + resourceDocs += ResourceDoc( + updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod, + apiVersion, + nameOf(updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod), + "PUT", + "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations/AUTHORISATION_ID", + "Update PSU Data for payment initiation cancellation (selectPsuAuthenticationMethod)", + generalUpdatePaymentCancellationPsuDataSummary(true), + json.parse("""{"authenticationMethodId":""}"""), + json.parse("""{ + "scaStatus": "scaMethodSelected", + "chosenScaMethod": { + "authenticationType": "SMS_OTP", + "authenticationMethodId": "myAuthenticationID"}, + "challengeData": { + "otpMaxLength": 6, + "otpFormat": "integer"}, + "_links": { + "authoriseTransaction": {"href": "/psd2/v1.3/payments/1234-wertiq-983/authorisations/123auth456"} + } + }"""), + List(UserNotLoggedIn, UnknownError), + ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil + ) + + lazy val updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod : OBPEndpoint = { + case paymentService :: paymentProduct :: paymentId:: "cancellation-authorisations" :: authorisationId :: Nil JsonPut json -> _ if checkSelectPsuAuthenticationMethod(json)=> { + cc => + for { + (_, callContext) <- authenticatedAccess(cc) + } yield { + (net.liftweb.json.parse( + """{ + "scaStatus": "scaMethodSelected", + "chosenScaMethod": { + "authenticationType": "SMS_OTP", + "authenticationMethodId": "myAuthenticationID"}, + "challengeData": { + "otpMaxLength": 6, + "otpFormat": "integer"}, + "_links": { + "authoriseTransaction": {"href": "/psd2/v1.3/payments/1234-wertiq-983/authorisations/123auth456"} + } + }"""), callContext) + } + } + } + + resourceDocs += ResourceDoc( + updatePaymentCancellationPsuDataAuthorisationConfirmation, + apiVersion, + nameOf(updatePaymentCancellationPsuDataAuthorisationConfirmation), + "PUT", + "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations/AUTHORISATION_ID", + "Update PSU Data for payment initiation cancellation (authorisationConfirmation)", + generalUpdatePaymentCancellationPsuDataSummary(true), + json.parse("""{"confirmationCode":"confirmationCode"}"""), + json.parse("""{ + "scaStatus": "finalised", + "_links":{ + "status": {"href":"/v1.3/payments/sepa-credit-transfers/qwer3456tzui7890/status"} + } + }"""), + List(UserNotLoggedIn, UnknownError), + ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil + ) + + lazy val updatePaymentCancellationPsuDataAuthorisationConfirmation : OBPEndpoint = { + case paymentService :: paymentProduct :: paymentId:: "cancellation-authorisations" :: authorisationId :: Nil JsonPut json -> _ if checkAuthorisationConfirmation(json)=> { + cc => + for { + (_, callContext) <- authenticatedAccess(cc) + } yield { + (net.liftweb.json.parse( + """{ + "scaStatus": "finalised", + "_links":{ + "status": {"href":"/v1.3/payments/sepa-credit-transfers/qwer3456tzui7890/status"} + } + }"""), callContext) + } + } + } + + + def generalUpdatePaymentPsuDataSumarry(isMockedData: Boolean) = + s"""${mockedDataText(isMockedData)} This methods updates PSU data on the authorisation resource if needed. It may authorise a payment within the Embedded SCA Approach where needed. @@ -936,17 +1386,17 @@ There are several possible Update PSU Data requests in the context of payment in which depends on the SCA approach: * Redirect SCA Approach: - A specific Update PSU Data Request is applicable for - * the selection of authentication methods, before choosing the actual SCA approach. +A specific Update PSU Data Request is applicable for + * the selection of authentication methods, before choosing the actual SCA approach. * Decoupled SCA Approach: - A specific Update PSU Data Request is only applicable for - * adding the PSU Identification, if not provided yet in the Payment Initiation Request or the Account Information Consent Request, or if no OAuth2 access token is used, or - * the selection of authentication methods. +A specific Update PSU Data Request is only applicable for +* adding the PSU Identification, if not provided yet in the Payment Initiation Request or the Account Information Consent Request, or if no OAuth2 access token is used, or +* the selection of authentication methods. * Embedded SCA Approach: - The Update PSU Data Request might be used - * to add credentials as a first factor authentication data of the PSU and - * to select the authentication method and - * transaction authorisation. +The Update PSU Data Request might be used +* to add credentials as a first factor authentication data of the PSU and +* to select the authentication method and +* transaction authorisation. The SCA Approach might depend on the chosen SCA method. For that reason, the following possible Update PSU Data request can apply to all SCA approaches: @@ -954,45 +1404,53 @@ For that reason, the following possible Update PSU Data request can apply to all * Select an SCA method in case of several SCA methods are available for the customer. There are the following request types on this access path: - * Update PSU Identification - * Update PSU Authentication - * Select PSU Autorization Method - WARNING: This method need a reduced header, - therefore many optional elements are not present. - Maybe in a later version the access path will change. - * Transaction Authorisation - WARNING: This method need a reduced header, - therefore many optional elements are not present. - Maybe in a later version the access path will change. +* Update PSU Identification +* Update PSU Authentication +* Select PSU Autorization Method + WARNING: This method need a reduced header, + therefore many optional elements are not present. + Maybe in a later version the access path will change. +* Transaction Authorisation + WARNING: This method need a reduced header, + therefore many optional elements are not present. + Maybe in a later version the access path will change. + + NOTE: For this endpoint, for sandbox mode, the `scaAuthenticationData` is fixed value: 123. To make the process work. + Normally the app use will get SMS/EMAIL to get the value for this process. - NOTE: For this endpoint, for sandbox mode, the `scaAuthenticationData` is fixed value: 123. To make the process work. - Normally the app use will get SMS/EMAIL to get the value for this process. - -""", +""" + + resourceDocs += ResourceDoc( + updatePaymentPsuDataTransactionAuthorisation, + apiVersion, + nameOf(updatePaymentPsuDataTransactionAuthorisation), + "PUT", + "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations/AUTHORISATION_ID", + "Update PSU data for payment initiation (transactionAuthorisation)", + generalUpdatePaymentPsuDataSumarry(false), json.parse("""{"scaAuthenticationData":"123"}"""), json.parse("""{ "scaStatus": "finalised", - "authorisationId": "88695566-6642-46d5-9985-0d824624f507", "psuMessage": "Please check your SMS at a mobile device.", "_links": { - "scaStatus": "/v1.3/payments/sepa-credit-transfers/88695566-6642-46d5-9985-0d824624f507" + "scaStatus": {"href":"/v1.3/payments/sepa-credit-transfers/88695566-6642-46d5-9985-0d824624f507"} } }"""), List(UserNotLoggedIn, UnknownError), ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil ) - lazy val updatePaymentPsuData : OBPEndpoint = { - case paymentService :: paymentProduct :: paymentId:: "authorisations" :: authorisationid :: Nil JsonPut json -> _ => { + lazy val updatePaymentPsuDataTransactionAuthorisation : OBPEndpoint = { + case paymentService :: paymentProduct :: paymentId:: "authorisations" :: authorisationid :: Nil JsonPut json -> _ if checkTransactionAuthorisation(json) => { cc => for { (Full(u), callContext) <- authenticatedAccess(cc) _ <- passesPsd2Pisp(callContext) - failMsg = s"$InvalidJsonFormat The Json body should be the $UpdatePaymentPsuDataJson " - updatePaymentPsuDataJson <- NewStyle.function.tryons(failMsg, 400, callContext) { - json.extract[UpdatePaymentPsuDataJson] + failMsg = s"$InvalidJsonFormat The Json body should be the $TransactionAuthorisation " + transactionAuthorisationJson <- NewStyle.function.tryons(failMsg, 400, callContext) { + json.extract[TransactionAuthorisation] } - + _ <- NewStyle.function.tryons(checkPaymentServerError(paymentService),400, callContext) { PaymentServiceTypes.withName(paymentService.replaceAll("-","_")) } @@ -1010,7 +1468,7 @@ There are the following request types on this access path: Some(paymentId), None, authorisationid, - updatePaymentPsuDataJson.scaAuthenticationData, + transactionAuthorisationJson.scaAuthenticationData, callContext ) @@ -1031,7 +1489,132 @@ There are the following request types on this access path: Future(Full(true)) } } yield { - (JSONFactory_BERLIN_GROUP_1_3.createStartPaymentAuthorisationJson(challenge), callContext) + (JSONFactory_BERLIN_GROUP_1_3.createUpdatePaymentPsuDataTransactionAuthorisationJson(challenge), callContext) + } + } + } + + resourceDocs += ResourceDoc( + updatePaymentPsuDataUpdatePsuAuthentication, + apiVersion, + nameOf(updatePaymentPsuDataUpdatePsuAuthentication), + "PUT", + "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations/AUTHORISATION_ID", + "Update PSU data for payment initiation (updatePsuAuthentication)", + generalUpdatePaymentPsuDataSumarry(true), + json.parse("""{"psuData": {"password": "start12"}}""".stripMargin), + json.parse("""{ + "scaStatus": "finalised", + "_links": { + "scaStatus": {"href":"/v1.3/payments/sepa-credit-transfers/88695566-6642-46d5-9985-0d824624f507"} + } + }"""), + List(UserNotLoggedIn, UnknownError), + ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil + ) + + lazy val updatePaymentPsuDataUpdatePsuAuthentication : OBPEndpoint = { + case paymentService :: paymentProduct :: paymentId:: "authorisations" :: authorisationid :: Nil JsonPut json -> _ if checkUpdatePsuAuthentication(json) => { + cc => + for { + (Full(u), callContext) <- authenticatedAccess(cc) + + } yield { + (liftweb.json.parse( + """{ + "scaStatus": "finalised", + "_links": { + "scaStatus": {"href":"/v1.3/payments/sepa-credit-transfers/88695566-6642-46d5-9985-0d824624f507"} + } + }"""), callContext) + } + } + } + + resourceDocs += ResourceDoc( + updatePaymentPsuDataSelectPsuAuthenticationMethod, + apiVersion, + nameOf(updatePaymentPsuDataSelectPsuAuthenticationMethod), + "PUT", + "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations/AUTHORISATION_ID", + "Update PSU data for payment initiation (selectPsuAuthenticationMethod)", + generalUpdatePaymentPsuDataSumarry(true), + json.parse("""{"authenticationMethodId":""}"""), + json.parse( + """{ + "scaStatus": "scaMethodSelected", + "chosenScaMethod": { + "authenticationType": "SMS_OTP", + "authenticationMethodId": "myAuthenticationID"}, + "challengeData": { + "otpMaxLength": 6, + "otpFormat": "integer"}, + "_links": { + "authoriseTransaction": {"href": "/psd2/v1.3/payments/1234-wertiq-983/authorisations/123auth456"} + } + }"""), + List(UserNotLoggedIn, UnknownError), + ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil + ) + + lazy val updatePaymentPsuDataSelectPsuAuthenticationMethod : OBPEndpoint = { + case paymentService :: paymentProduct :: paymentId:: "authorisations" :: authorisationid :: Nil JsonPut json -> _ if checkSelectPsuAuthenticationMethod(json) => { + cc => + for { + (Full(u), callContext) <- authenticatedAccess(cc) + + } yield { + (liftweb.json.parse( + """{ + "scaStatus": "scaMethodSelected", + "chosenScaMethod": { + "authenticationType": "SMS_OTP", + "authenticationMethodId": "myAuthenticationID"}, + "challengeData": { + "otpMaxLength": 6, + "otpFormat": "integer"}, + "_links": { + "authoriseTransaction": {"href": "/psd2/v1.3/payments/1234-wertiq-983/authorisations/123auth456"} + } + }"""), callContext) + } + } + } + + resourceDocs += ResourceDoc( + updatePaymentPsuDataAuthorisationConfirmation, + apiVersion, + nameOf(updatePaymentPsuDataAuthorisationConfirmation), + "PUT", + "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations/AUTHORISATION_ID", + "Update PSU data for payment initiation (authorisationConfirmation)", + generalUpdatePaymentPsuDataSumarry(true), + json.parse("""{"confirmationCode":"confirmationCode"}"""), + json.parse( + """{ + "scaStatus": "finalised", + "_links":{ + "status": {"href":"/v1.3/payments/sepa-credit-transfers/qwer3456tzui7890/status"} + } + }"""), + List(UserNotLoggedIn, UnknownError), + ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil + ) + + lazy val updatePaymentPsuDataAuthorisationConfirmation : OBPEndpoint = { + case paymentService :: paymentProduct :: paymentId:: "authorisations" :: authorisationid :: Nil JsonPut json -> _ if checkAuthorisationConfirmation(json) => { + cc => + for { + (Full(u), callContext) <- authenticatedAccess(cc) + + } yield { + (liftweb.json.parse( + """{ + "scaStatus": "finalised", + "_links":{ + "status": {"href":"/v1.3/payments/sepa-credit-transfers/qwer3456tzui7890/status"} + } + }"""), callContext) } } } diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountAccess.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountAccess.scala new file mode 100644 index 0000000000..bde7cd561f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountAccess.scala @@ -0,0 +1,54 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class AccountAccess ( + /* Is asking for detailed account information. If the array is empty in a request, the TPP is asking for an accessible account list. This may be restricted in a PSU/ASPSP authorization dialogue. If the array is empty, also the arrays for balances, additionalInformation sub attributes or transactions shall be empty, if used. */ + accounts: Option[Seq[AccountReference]] = None, + /* Is asking for balances of the addressed accounts. If the array is empty in the request, the TPP is asking for the balances of all accessible account lists. This may be restricted in a PSU/ASPSP authorization dialogue. If the array is empty, also the arrays for accounts, additionalInformation sub attributes or transactions shall be empty, if used. */ + balances: Option[Seq[AccountReference]] = None, + /* Is asking for transactions of the addressed accounts. If the array is empty in the request, the TPP is asking for the transactions of all accessible account lists. This may be restricted in a PSU/ASPSP authorization dialogue. If the array is empty, also the arrays for accounts, additionalInformation sub attributes or balances shall be empty, if used. */ + transactions: Option[Seq[AccountReference]] = None, + additionalInformation: Option[AdditionalInformationAccess] = None, + /* Optional if supported by API provider. The values \"allAccounts\" and \"allAccountsWithOwnerName\" are admitted. The support of the \"allAccountsWithOwnerName\" value by the ASPSP is optional. */ + availableAccounts: Option[AccountAccessEnums.AvailableAccounts] = None, + /* Optional if supported by API provider. The values \"allAccounts\" and \"allAccountsWithOwnerName\" are admitted. The support of the \"allAccountsWithOwnerName\" value by the ASPSP is optional. */ + availableAccountsWithBalance: Option[AccountAccessEnums.AvailableAccountsWithBalance] = None, + /* Optional if supported by API provider. The values \"allAccounts\" and \"allAccountsWithOwnerName\" are admitted. The support of the \"allAccountsWithOwnerName\" value by the ASPSP is optional. */ + allPsd2: Option[AccountAccessEnums.AllPsd2] = None, + /* If the TPP requests access to accounts via availableAccounts (List of available accounts), global or bank driven consents, the TPP may include this element to restrict access to the referred account types. Absence of the element is interpreted as \"no restriction\" (therefore access to accounts of all types is requested). The element may only occur, if each of the elements - accounts - balances - transactions is either not present or contains an empty array. */ + restrictedTo: Option[Seq[String]] = None +) extends ApiModel + +object AccountAccessEnums { + + type AvailableAccounts = AvailableAccounts.Value + type AvailableAccountsWithBalance = AvailableAccountsWithBalance.Value + type AllPsd2 = AllPsd2.Value + object AvailableAccounts extends Enumeration { + val AllAccounts = Value("allAccounts") + val AllAccountsWithOwnerName = Value("allAccountsWithOwnerName") + } + + object AvailableAccountsWithBalance extends Enumeration { + val AllAccounts = Value("allAccounts") + val AllAccountsWithOwnerName = Value("allAccountsWithOwnerName") + } + + object AllPsd2 extends Enumeration { + val AllAccounts = Value("allAccounts") + val AllAccountsWithOwnerName = Value("allAccountsWithOwnerName") + } + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountDetails.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountDetails.scala new file mode 100644 index 0000000000..0bddb81125 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountDetails.scala @@ -0,0 +1,63 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class AccountDetails ( + /* This shall be filled, if addressable resource are created by the ASPSP on the /accounts or /card-accounts endpoint. */ + resourceId: Option[String] = None, + /* IBAN of an account. */ + iban: Option[String] = None, + /* Basic Bank Account Number (BBAN) Identifier. This data element can be used in the body of the consent request. Message for retrieving account access consent from this account. This data elements is used for payment accounts which have no IBAN. ISO20022: Basic Bank Account Number (BBAN). Identifier used nationally by financial institutions, i.e., in individual countries, generally as part of a National Account Numbering Scheme(s), which uniquely identifies the account of a customer. */ + bban: Option[String] = None, + /* Mobile phone number. */ + msisdn: Option[String] = None, + /* ISO 4217 Alpha 3 currency code. */ + currency: String, + /* Name of the legal account owner. If there is more than one owner, then e.g. two names might be noted here. For a corporate account, the corporate name is used for this attribute. Even if supported by the ASPSP, the provision of this field might depend on the fact whether an explicit consent to this specific additional account information has been given by the PSU. */ + ownerName: Option[String] = None, + /* List of owner names. */ + ownerNames: Option[Seq[AccountOwner]] = None, + /* Name of the PSU. In case of a corporate account, this might be the person acting on behalf of the corporate. */ + psuName: Option[String] = None, + /* Name of the account, as assigned by the ASPSP, in agreement with the account owner in order to provide an additional means of identification of the account. */ + name: Option[String] = None, + /* Name of the account as defined by the PSU within online channels. */ + displayName: Option[String] = None, + /* Product name of the bank for this account, proprietary definition. */ + product: Option[String] = None, + /* ExternalCashAccountType1Code from ISO 20022. */ + cashAccountType: Option[String] = None, + status: Option[AccountStatus] = None, + /* BICFI */ + bic: Option[String] = None, + /* Case of a set of pending card transactions, the APSP will provide the relevant cash account the card is set up on. */ + linkedAccounts: Option[String] = None, + /* Specifies the usage of the account: * PRIV: private personal account * ORGA: professional account */ + usage: Option[AccountDetailsEnums.Usage] = None, + /* Specifications that might be provided by the ASPSP: - characteristics of the account - characteristics of the relevant card */ + details: Option[String] = None, + /* A list of balances regarding this account, e.g. the current balance, the last booked balance. The list might be restricted to the current balance. */ + balances: Option[Seq[Balance]] = None, + _links: Option[LinksAccountDetails] = None +) extends ApiModel + +object AccountDetailsEnums { + + type Usage = Usage.Value + object Usage extends Enumeration { + val PRIV = Value("PRIV") + val ORGA = Value("ORGA") + } + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountList.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountList.scala new file mode 100644 index 0000000000..d78328fd0f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountList.scala @@ -0,0 +1,19 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class AccountList ( + accounts: Seq[AccountDetails] +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountOwner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountOwner.scala new file mode 100644 index 0000000000..14282d54b4 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountOwner.scala @@ -0,0 +1,22 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class AccountOwner ( + /* Account owner name */ + name: String, + /* The following proprietary codes are used: * \"owner\", * \"legalRepresentative\", * \"authorisedUser\" */ + role: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountReference.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountReference.scala new file mode 100644 index 0000000000..6a6cf44202 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountReference.scala @@ -0,0 +1,33 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class AccountReference ( + /* IBAN of an account. */ + iban: Option[String] = None, + /* Basic Bank Account Number (BBAN) Identifier. This data element can be used in the body of the consent request. Message for retrieving account access consent from this account. This data elements is used for payment accounts which have no IBAN. ISO20022: Basic Bank Account Number (BBAN). Identifier used nationally by financial institutions, i.e., in individual countries, generally as part of a National Account Numbering Scheme(s), which uniquely identifies the account of a customer. */ + bban: Option[String] = None, + /* Primary Account Number according to ISO/IEC 7812. */ + pan: Option[String] = None, + /* Masked Primary Account Number. */ + maskedPan: Option[String] = None, + /* Mobile phone number. */ + msisdn: Option[String] = None, + other: Option[OtherType] = None, + /* ISO 4217 Alpha 3 currency code. */ + currency: Option[String] = None, + /* ExternalCashAccountType1Code from ISO 20022. */ + cashAccountType: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountReport.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountReport.scala new file mode 100644 index 0000000000..2271b65d82 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountReport.scala @@ -0,0 +1,25 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class AccountReport ( + /* Array of transaction details. */ + booked: Option[Seq[Transactions]] = None, + /* Array of transaction details. */ + pending: Option[Seq[Transactions]] = None, + /* Array of transaction details. */ + information: Option[Seq[Transactions]] = None, + links: LinksAccountReport +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountStatus.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountStatus.scala new file mode 100644 index 0000000000..776aea5904 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountStatus.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class AccountStatus ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AdditionalInformationAccess.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AdditionalInformationAccess.scala new file mode 100644 index 0000000000..25cdbc74cc --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AdditionalInformationAccess.scala @@ -0,0 +1,22 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class AdditionalInformationAccess ( + /* Is asking for account owner name of the accounts referenced within. If the array is empty in the request, the TPP is asking for the account owner name of all accessible accounts. This may be restricted in a PSU/ASPSP authorization dialogue. If the array is empty, also the arrays for accounts, balances or transactions shall be empty, if used. The ASPSP will indicate in the consent resource after a successful authorisation, whether the ownerName consent can be accepted by providing the accounts on which the ownerName will be delivered. This array can be empty. */ + ownerName: Option[Seq[AccountReference]] = None, + /* Optional if supported by API provider. Is asking for the trusted beneficiaries related to the accounts referenced within and related to the PSU. If the array is empty in the request, the TPP is asking for the lists of trusted beneficiaries of all accessible accounts. This may be restricted in a PSU/ASPSP authorization dialogue by the PSU if also the account lists addressed by the tags “accounts”, “balances” or “transactions” are empty. The ASPSP will indicate in the consent resource after a successful authorisation, whether the trustedBeneficiaries consent can be accepted by providing the accounts on which the list of trusted beneficiaries will be delivered. This array can be empty. */ + trustedBeneficiaries: Option[Seq[AccountReference]] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AdditionalInformationStructured.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AdditionalInformationStructured.scala new file mode 100644 index 0000000000..ef98b41425 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AdditionalInformationStructured.scala @@ -0,0 +1,19 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class AdditionalInformationStructured ( + standingOrderDetails: StandingOrderDetails +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Address.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Address.scala new file mode 100644 index 0000000000..ebd0eba13a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Address.scala @@ -0,0 +1,24 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Address ( + streetName: Option[String] = None, + buildingNumber: Option[String] = None, + townName: Option[String] = None, + postCode: Option[String] = None, + /* ISO 3166 ALPHA2 country code. */ + country: String +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Amount.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Amount.scala new file mode 100644 index 0000000000..2d3a37d01e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Amount.scala @@ -0,0 +1,22 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Amount ( + /* ISO 4217 Alpha 3 currency code. */ + currency: String, + /* The amount given with fractional digits, where fractions must be compliant to the currency definition. Up to 14 significant figures. Negative amounts are signed by minus. The decimal separator is a dot. **Example:** Valid representations for EUR with up to two decimals are: * 1056 * 5768.2 * -1.50 * 5877.78 */ + amount: String +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthenticationObject.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthenticationObject.scala new file mode 100644 index 0000000000..7095c111ac --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthenticationObject.scala @@ -0,0 +1,30 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class AuthenticationObject ( + authenticationType: AuthenticationType, + /* Depending on the \"authenticationType\". This version can be used by differentiating authentication tools used within performing OTP generation in the same authentication type. This version can be referred to in the ASPSP?s documentation. */ + authenticationVersion: Option[String] = None, + /* An identification provided by the ASPSP for the later identification of the authentication method selection. */ + authenticationMethodId: String, + /* This is the name of the authentication method defined by the PSU in the Online Banking frontend of the ASPSP. Alternatively this could be a description provided by the ASPSP like \"SMS OTP on phone +49160 xxxxx 28\". This name shall be used by the TPP when presenting a list of authentication methods to the PSU, if available. */ + name: Option[String] = None, + /* Detailed information about the SCA method for the PSU. */ + explanation: Option[String] = None +) extends ApiModel + +object AuthenticationObjectEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthenticationType.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthenticationType.scala new file mode 100644 index 0000000000..bbf9f85088 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthenticationType.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class AuthenticationType ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthorisationConfirmation.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthorisationConfirmation.scala new file mode 100644 index 0000000000..2adaca6b3f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthorisationConfirmation.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class AuthorisationConfirmation ( + /* Confirmation Code as retrieved by the TPP from the redirect based SCA process. */ + confirmationCode: String +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthorisationConfirmationResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthorisationConfirmationResponse.scala new file mode 100644 index 0000000000..c6fe65cfa9 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthorisationConfirmationResponse.scala @@ -0,0 +1,25 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class AuthorisationConfirmationResponse ( + scaStatus: ScaStatusAuthorisationConfirmation, + links: LinksAuthorisationConfirmation, + /* Text to be displayed to the PSU. */ + psuMessage: Option[String] = None +) extends ApiModel + +object AuthorisationConfirmationResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Authorisations.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Authorisations.scala new file mode 100644 index 0000000000..835ba69558 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Authorisations.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Authorisations ( + /* An array of all authorisationIds. */ + authorisationIds: Seq[String] +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Balance.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Balance.scala new file mode 100644 index 0000000000..996dfb800a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Balance.scala @@ -0,0 +1,33 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate +import java.time.OffsetDateTime + + +case class Balance ( + balanceAmount: Amount, + balanceType: BalanceType, + /* A flag indicating if the credit limit of the corresponding account is included in the calculation of the balance, where applicable. */ + creditLimitIncluded: Option[Boolean] = None, + /* This data element might be used to indicate e.g. with the expected or booked balance that no action is known on the account, which is not yet booked. */ + lastChangeDateTime: Option[OffsetDateTime] = None, + /* Indicates the date of the balance. */ + referenceDate: Option[LocalDate] = None, + /* \"entryReference\" of the last committed transaction to support the TPP in identifying whether all PSU transactions are already known. */ + lastCommittedTransaction: Option[String] = None +) extends ApiModel + +object BalanceEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BalanceType.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BalanceType.scala new file mode 100644 index 0000000000..d5477a6f76 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BalanceType.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class BalanceType ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationCrossBorderJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationCrossBorderJson.scala new file mode 100644 index 0000000000..5a86840b84 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationCrossBorderJson.scala @@ -0,0 +1,25 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class BulkPaymentInitiationCrossBorderJson ( + /* If this element equals 'true', the PSU prefers only one booking entry. If this element equals 'false', the PSU prefers individual booking of all contained individual transactions. The ASPSP will follow this preference according to contracts agreed on with the PSU. */ + batchBookingPreferred: Option[Boolean] = None, + requestedExecutionDate: Option[LocalDate] = None, + debtorAccount: AccountReference, + /* A List of JSON bodies for cross-border payments. */ + payments: Seq[PaymentInitiationCrossBorderBulkElementJson] +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationCrossBorderWithStatusResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationCrossBorderWithStatusResponse.scala new file mode 100644 index 0000000000..6a80b55fa0 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationCrossBorderWithStatusResponse.scala @@ -0,0 +1,29 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class BulkPaymentInitiationCrossBorderWithStatusResponse ( + /* If this element equals 'true', the PSU prefers only one booking entry. If this element equals 'false', the PSU prefers individual booking of all contained individual transactions. The ASPSP will follow this preference according to contracts agreed on with the PSU. */ + batchBookingPreferred: Option[Boolean] = None, + requestedExecutionDate: Option[LocalDate] = None, + debtorAccount: AccountReference, + /* A list of JSON bodies for cross-border payments. */ + payments: Seq[PaymentInitiationCrossBorderJson], + transactionStatus: Option[TransactionStatus] = None +) extends ApiModel + +object BulkPaymentInitiationCrossBorderWithStatusResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationJson.scala new file mode 100644 index 0000000000..d29aeca4ba --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationJson.scala @@ -0,0 +1,27 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate +import java.time.OffsetDateTime + + +case class BulkPaymentInitiationJson ( + /* If this element equals 'true', the PSU prefers only one booking entry. If this element equals 'false', the PSU prefers individual booking of all contained individual transactions. The ASPSP will follow this preference according to contracts agreed on with the PSU. */ + batchBookingPreferred: Option[Boolean] = None, + debtorAccount: AccountReference, + requestedExecutionDate: Option[LocalDate] = None, + requestedExecutionTime: Option[OffsetDateTime] = None, + /* A list of generic JSON bodies payment initiations for bulk payments via JSON. Note: Some fields from single payments do not occur in a bulk payment element */ + payments: Seq[PaymentInitiationBulkElementJson] +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationSctInstJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationSctInstJson.scala new file mode 100644 index 0000000000..3a2dfb4b3b --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationSctInstJson.scala @@ -0,0 +1,25 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class BulkPaymentInitiationSctInstJson ( + /* If this element equals 'true', the PSU prefers only one booking entry. If this element equals 'false', the PSU prefers individual booking of all contained individual transactions. The ASPSP will follow this preference according to contracts agreed on with the PSU. */ + batchBookingPreferred: Option[Boolean] = None, + requestedExecutionDate: Option[LocalDate] = None, + debtorAccount: AccountReference, + /* A list of JSON bodies for SCT INST payments. */ + payments: Seq[PaymentInitiationSctInstBulkElementJson] +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationSctInstWithStatusResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationSctInstWithStatusResponse.scala new file mode 100644 index 0000000000..e69fee8f4c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationSctInstWithStatusResponse.scala @@ -0,0 +1,29 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class BulkPaymentInitiationSctInstWithStatusResponse ( + /* If this element equals 'true', the PSU prefers only one booking entry. If this element equals 'false', the PSU prefers individual booking of all contained individual transactions. The ASPSP will follow this preference according to contracts agreed on with the PSU. */ + batchBookingPreferred: Option[Boolean] = None, + requestedExecutionDate: Option[LocalDate] = None, + debtorAccount: AccountReference, + /* A list of JSON bodies for SCT INST payments. */ + payments: Seq[PaymentInitiationSctInstJson], + transactionStatus: Option[TransactionStatus] = None +) extends ApiModel + +object BulkPaymentInitiationSctInstWithStatusResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationSctJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationSctJson.scala new file mode 100644 index 0000000000..280a9c6902 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationSctJson.scala @@ -0,0 +1,25 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class BulkPaymentInitiationSctJson ( + /* If this element equals 'true', the PSU prefers only one booking entry. If this element equals 'false', the PSU prefers individual booking of all contained individual transactions. The ASPSP will follow this preference according to contracts agreed on with the PSU. */ + batchBookingPreferred: Option[Boolean] = None, + requestedExecutionDate: Option[LocalDate] = None, + debtorAccount: AccountReference, + /* A list of JSON bodies for SCT payments. */ + payments: Seq[PaymentInitiationSctBulkElementJson] +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationSctWithStatusResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationSctWithStatusResponse.scala new file mode 100644 index 0000000000..0e16936674 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationSctWithStatusResponse.scala @@ -0,0 +1,29 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class BulkPaymentInitiationSctWithStatusResponse ( + /* If this element equals 'true', the PSU prefers only one booking entry. If this element equals 'false', the PSU prefers individual booking of all contained individual transactions. The ASPSP will follow this preference according to contracts agreed on with the PSU. */ + batchBookingPreferred: Option[Boolean] = None, + requestedExecutionDate: Option[LocalDate] = None, + debtorAccount: AccountReference, + /* A list of JSON bodies for SCT payments. */ + payments: Seq[PaymentInitiationSctJson], + transactionStatus: Option[TransactionStatus] = None +) extends ApiModel + +object BulkPaymentInitiationSctWithStatusResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationTarget2Json.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationTarget2Json.scala new file mode 100644 index 0000000000..2e28262e05 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationTarget2Json.scala @@ -0,0 +1,25 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class BulkPaymentInitiationTarget2Json ( + /* If this element equals 'true', the PSU prefers only one booking entry. If this element equals 'false', the PSU prefers individual booking of all contained individual transactions. The ASPSP will follow this preference according to contracts agreed on with the PSU. */ + batchBookingPreferred: Option[Boolean] = None, + requestedExecutionDate: Option[LocalDate] = None, + debtorAccount: AccountReference, + /* A list of JSON bodies for TARGET-2 payments. */ + payments: Seq[PaymentInitiationTarget2BulkElementJson] +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationTarget2WithStatusResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationTarget2WithStatusResponse.scala new file mode 100644 index 0000000000..fe70364f63 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationTarget2WithStatusResponse.scala @@ -0,0 +1,29 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class BulkPaymentInitiationTarget2WithStatusResponse ( + /* If this element equals 'true', the PSU prefers only one booking entry. If this element equals 'false', the PSU prefers individual booking of all contained individual transactions. The ASPSP will follow this preference according to contracts agreed on with the PSU. */ + batchBookingPreferred: Option[Boolean] = None, + requestedExecutionDate: Option[LocalDate] = None, + debtorAccount: AccountReference, + /* A list of JSON bodies for TARGET-2 payments. */ + payments: Seq[PaymentInitiationTarget2Json], + transactionStatus: Option[TransactionStatus] = None +) extends ApiModel + +object BulkPaymentInitiationTarget2WithStatusResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationWithStatusResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationWithStatusResponse.scala new file mode 100644 index 0000000000..d939b0e298 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationWithStatusResponse.scala @@ -0,0 +1,34 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate +import java.time.OffsetDateTime + + +case class BulkPaymentInitiationWithStatusResponse ( + /* If this element equals 'true', the PSU prefers only one booking entry. If this element equals 'false', the PSU prefers individual booking of all contained individual transactions. The ASPSP will follow this preference according to contracts agreed on with the PSU. */ + batchBookingPreferred: Option[Boolean] = None, + requestedExecutionDate: Option[LocalDate] = None, + acceptorTransactionDateTime: Option[OffsetDateTime] = None, + debtorAccount: AccountReference, + paymentInformationId: Option[String] = None, + /* A list of generic JSON bodies payment initiations for bulk payments via JSON. Note: Some fields from single payments do not occur in a bulk payment element */ + payments: Seq[PaymentInitiationBulkElementJson], + transactionStatus: Option[TransactionStatus] = None, + /* Messages to the TPP on operational issues. */ + tppMessage: Option[Seq[TppMessageGeneric]] = None +) extends ApiModel + +object BulkPaymentInitiationWithStatusResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountDetails.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountDetails.scala new file mode 100644 index 0000000000..8fe6066482 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountDetails.scala @@ -0,0 +1,52 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class CardAccountDetails ( + /* This is the data element to be used in the path when retrieving data from a dedicated account. This shall be filled, if addressable resource are created by the ASPSP on the /card-accounts endpoint. */ + resourceId: Option[String] = None, + /* Masked Primary Account Number. */ + maskedPan: String, + /* ISO 4217 Alpha 3 currency code. */ + currency: String, + /* Name of the legal account owner. If there is more than one owner, then e.g. two names might be noted here. For a corporate account, the corporate name is used for this attribute. Even if supported by the ASPSP, the provision of this field might depend on the fact whether an explicit consent to this specific additional account information has been given by the PSU. */ + ownerName: Option[String] = None, + /* Name of the account, as assigned by the ASPSP, in agreement with the account owner in order to provide an additional means of identification of the account. */ + name: Option[String] = None, + /* Name of the account as defined by the PSU within online channels. */ + displayName: Option[String] = None, + /* Product Name of the Bank for this account, proprietary definition. */ + product: Option[String] = None, + /* If true, the amounts of debits on the reports are quoted positive with the related consequence for balances. If false, the amount of debits on the reports are quoted negative. */ + debitAccounting: Option[Boolean] = None, + status: Option[AccountStatus] = None, + /* Specifies the usage of the account: * PRIV: private personal account * ORGA: professional account */ + usage: Option[CardAccountDetailsEnums.Usage] = None, + /* Specifications that might be provided by the ASPSP: - characteristics of the account - characteristics of the relevant card */ + details: Option[String] = None, + creditLimit: Option[Amount] = None, + /* A list of balances regarding this account, e.g. the current balance, the last booked balance. The list might be restricted to the current balance. */ + balances: Option[Seq[Balance]] = None, + _links: Option[LinksAccountDetails] = None +) extends ApiModel + +object CardAccountDetailsEnums { + + type Usage = Usage.Value + object Usage extends Enumeration { + val PRIV = Value("PRIV") + val ORGA = Value("ORGA") + } + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountList.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountList.scala new file mode 100644 index 0000000000..fc3f832cf0 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountList.scala @@ -0,0 +1,19 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class CardAccountList ( + cardAccounts: Seq[CardAccountDetails] +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountReport.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountReport.scala new file mode 100644 index 0000000000..fe78abe566 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountReport.scala @@ -0,0 +1,23 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class CardAccountReport ( + /* Array of transaction details. */ + booked: Option[Seq[CardTransaction]] = None, + /* Array of transaction details. */ + pending: Option[Seq[CardTransaction]] = None, + links: LinksCardAccountReport +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountsTransactionsResponse200.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountsTransactionsResponse200.scala new file mode 100644 index 0000000000..c6823f9898 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountsTransactionsResponse200.scala @@ -0,0 +1,25 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class CardAccountsTransactionsResponse200 ( + cardAccount: Option[AccountReference] = None, + /* If true, the amounts of debits on the reports are quoted positive with the related consequence for balances. If false, the amount of debits on the reports are quoted negative. */ + debitAccounting: Option[Boolean] = None, + cardTransactions: Option[CardAccountReport] = None, + /* A list of balances regarding this account, e.g. the current balance, the last booked balance. The list might be restricted to the current balance. */ + balances: Option[Seq[Balance]] = None, + _links: Option[LinksDownload] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardTransaction.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardTransaction.scala new file mode 100644 index 0000000000..94a91c3e41 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardTransaction.scala @@ -0,0 +1,51 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate +import java.time.OffsetDateTime + + +case class CardTransaction ( + /* Unique end to end identity. */ + cardTransactionId: Option[String] = None, + /* Identification of the Terminal, where the card has been used. */ + terminalId: Option[String] = None, + /* Date of the actual card transaction. */ + transactionDate: Option[LocalDate] = None, + /* Timestamp of the actual card transaction within the acceptance system */ + acceptorTransactionDateTime: Option[OffsetDateTime] = None, + /* The date when an entry is posted to an account on the ASPSPs books. */ + bookingDate: Option[LocalDate] = None, + /* The Date at which assets become available to the account owner in case of a credit, or cease to be available to the account owner in case of a debit entry. For card transactions this is the payment due date of related booked transactions of a card. */ + valueDate: Option[LocalDate] = None, + transactionAmount: Amount, + grandTotalAmount: Option[CardTransactionGrandTotalAmount] = None, + /* Array of exchange rates. */ + currencyExchange: Option[Seq[ReportExchangeRate]] = None, + originalAmount: Option[Amount] = None, + markupFee: Option[Amount] = None, + markupFeePercentage: Option[String] = None, + cardAcceptorId: Option[String] = None, + cardAcceptorAddress: Option[Address] = None, + /* Merchant phone number It consists of a \"+\" followed by the country code (from 1 to 3 characters) then a \"-\" and finally, any combination of numbers, \"(\", \")\", \"+\" and \"-\" (up to 30 characters). pattern according to ISO20022 \\+[0-9]{1,3}-[0-9()+\\-]{1,30} */ + cardAcceptorPhone: Option[String] = None, + /* Merchant category code. */ + merchantCategoryCode: Option[String] = None, + /* Masked Primary Account Number. */ + maskedPAN: Option[String] = None, + transactionDetails: Option[String] = None, + invoiced: Option[Boolean] = None, + /* Proprietary bank transaction code as used within a community or within an ASPSP e.g. for MT94x based transaction reports. */ + proprietaryBankTransactionCode: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardTransactionGrandTotalAmount.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardTransactionGrandTotalAmount.scala new file mode 100644 index 0000000000..a5a87800e4 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardTransactionGrandTotalAmount.scala @@ -0,0 +1,22 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class CardTransactionGrandTotalAmount ( + /* ISO 4217 Alpha 3 currency code. */ + currency: String, + /* The amount given with fractional digits, where fractions must be compliant to the currency definition. Up to 14 significant figures. Negative amounts are signed by minus. The decimal separator is a dot. **Example:** Valid representations for EUR with up to two decimals are: * 1056 * 5768.2 * -1.50 * 5877.78 */ + amount: String +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ChallengeData.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ChallengeData.scala new file mode 100644 index 0000000000..9121ffe5de --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ChallengeData.scala @@ -0,0 +1,39 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class ChallengeData ( + /* PNG data (max. 512 kilobyte) to be displayed to the PSU, Base64 encoding, cp. [RFC4648]. This attribute is used only, when PHOTO_OTP or CHIP_OTP is the selected SCA method. */ + image: Option[Array[Byte]] = None, + /* A collection of strings as challenge data. */ + data: Option[Seq[String]] = None, + /* A link where the ASPSP will provides the challenge image for the TPP. */ + imageLink: Option[String] = None, + /* The maximal length for the OTP to be typed in by the PSU. */ + otpMaxLength: Option[Int] = None, + /* The format type of the OTP to be typed in. The admitted values are \"characters\" or \"integer\". */ + otpFormat: Option[ChallengeDataEnums.OtpFormat] = None, + /* Additional explanation for the PSU to explain e.g. fallback mechanism for the chosen SCA method. The TPP is obliged to show this to the PSU. */ + additionalInformation: Option[String] = None +) extends ApiModel + +object ChallengeDataEnums { + + type OtpFormat = OtpFormat.Value + object OtpFormat extends Enumeration { + val Characters = Value("characters") + val Integer = Value("integer") + } + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ChargeBearer.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ChargeBearer.scala new file mode 100644 index 0000000000..b799020f54 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ChargeBearer.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class ChargeBearer ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CheckAvailabilityOfFunds200Response.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CheckAvailabilityOfFunds200Response.scala new file mode 100644 index 0000000000..0e522f3981 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CheckAvailabilityOfFunds200Response.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class CheckAvailabilityOfFunds200Response ( + /* Equals true if sufficient funds are available at the time of the request, false otherwise. This data element is allways contained in a confirmation of funds response. This data element is contained in a payment status response, if supported by the ASPSP, if a funds check has been performed and if the transactionStatus is \"ACTC\", \"ACWC\" or \"ACCP\". */ + fundsAvailable: Boolean +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConfirmationOfFunds.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConfirmationOfFunds.scala new file mode 100644 index 0000000000..c055853640 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConfirmationOfFunds.scala @@ -0,0 +1,24 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class ConfirmationOfFunds ( + /* Card Number of the card issued by the PIISP. Should be delivered if available. */ + cardNumber: Option[String] = None, + account: AccountReference, + /* Name payee. */ + payee: Option[String] = None, + instructedAmount: Amount +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentInformationResponse200Json.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentInformationResponse200Json.scala new file mode 100644 index 0000000000..d76af42b41 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentInformationResponse200Json.scala @@ -0,0 +1,33 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class ConsentInformationResponse200Json ( + access: AccountAccess, + /* \"true\", if the consent is for recurring access to the account data. \"false\", if the consent is for one access to the account data. */ + recurringIndicator: Boolean, + /* This parameter is defining a valid until date (including the mentioned date) for the requested consent. The content is the local ASPSP date in ISO-Date format, e.g. 2017-10-30. Future dates might get adjusted by ASPSP. If a maximal available date is requested, a date in far future is to be used: \"9999-12-31\". In both cases the consent object to be retrieved by the get consent request will contain the adjusted date. */ + validUntil: LocalDate, + /* This field indicates the requested maximum frequency for an access without PSU involvement per day. For a one-off access, this attribute is set to \"1\". The frequency needs to be greater equal to one. If not otherwise agreed bilaterally between TPP and ASPSP, the frequency is less equal to 4. */ + frequencyPerDay: Int, + /* This date is containing the date of the last action on the consent object either through the XS2A interface or the PSU/ASPSP interface having an impact on the status. */ + lastActionDate: LocalDate, + consentStatus: ConsentStatus, + _links: Option[LinksGetConsent] = None +) extends ApiModel + +object ConsentInformationResponse200JsonEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentStatus.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentStatus.scala new file mode 100644 index 0000000000..e1bc72f5eb --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentStatus.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class ConsentStatus ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentStatusResponse200.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentStatusResponse200.scala new file mode 100644 index 0000000000..820187815b --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentStatusResponse200.scala @@ -0,0 +1,24 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class ConsentStatusResponse200 ( + consentStatus: ConsentStatus, + /* Text to be displayed to the PSU. */ + psuMessage: Option[String] = None +) extends ApiModel + +object ConsentStatusResponse200Enums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Consents.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Consents.scala new file mode 100644 index 0000000000..8ab02b790c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Consents.scala @@ -0,0 +1,28 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class Consents ( + access: AccountAccess, + /* \"true\", if the consent is for recurring access to the account data. \"false\", if the consent is for one access to the account data. */ + recurringIndicator: Boolean, + /* This parameter is defining a valid until date (including the mentioned date) for the requested consent. The content is the local ASPSP date in ISO-Date format, e.g. 2017-10-30. Future dates might get adjusted by ASPSP. If a maximal available date is requested, a date in far future is to be used: \"9999-12-31\". In both cases the consent object to be retrieved by the get consent request will contain the adjusted date. */ + validUntil: LocalDate, + /* This field indicates the requested maximum frequency for an access without PSU involvement per day. For a one-off access, this attribute is set to \"1\". The frequency needs to be greater equal to one. If not otherwise agreed bilaterally between TPP and ASPSP, the frequency is less equal to 4. */ + frequencyPerDay: Int, + /* If \"true\" indicates that a payment initiation service will be addressed in the same \"session\". */ + combinedServiceIndicator: Boolean +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentsResponse201.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentsResponse201.scala new file mode 100644 index 0000000000..ad09853427 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentsResponse201.scala @@ -0,0 +1,31 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class ConsentsResponse201 ( + consentStatus: ConsentStatus, + /* ID of the corresponding consent object as returned by an account information consent request. */ + consentId: String, + /* This data element might be contained, if SCA is required and if the PSU has a choice between different authentication methods. Depending on the risk management of the ASPSP this choice might be offered before or after the PSU has been identified with the first relevant factor, or if an access token is transported. If this data element is contained, then there is also a hyperlink of type 'startAuthorisationWithAuthenticationMethodSelection' contained in the response body. These methods shall be presented towards the PSU for selection by the TPP. */ + scaMethods: Option[Seq[AuthenticationObject]] = None, + chosenScaMethod: Option[AuthenticationObject] = None, + challengeData: Option[ChallengeData] = None, + links: LinksConsents, + /* Text to be displayed to the PSU. */ + psuMessage: Option[String] = None +) extends ApiModel + +object ConsentsResponse201Enums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/DayOfExecution.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/DayOfExecution.scala new file mode 100644 index 0000000000..fc28dfb4c9 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/DayOfExecution.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class DayOfExecution ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/EntryDetailsElement.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/EntryDetailsElement.scala new file mode 100644 index 0000000000..aabd98476e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/EntryDetailsElement.scala @@ -0,0 +1,54 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class EntryDetailsElement ( + /* Unique end to end identity. */ + endToEndId: Option[String] = None, + /* Identification of Mandates, e.g. a SEPA Mandate ID. */ + mandateId: Option[String] = None, + /* Identification of a Cheque. */ + checkId: Option[String] = None, + /* Identification of Creditors, e.g. a SEPA Creditor ID. */ + creditorId: Option[String] = None, + transactionAmount: Amount, + /* Array of exchange rates. */ + currencyExchange: Option[Seq[ReportExchangeRate]] = None, + /* Creditor name. */ + creditorName: Option[String] = None, + creditorAccount: Option[AccountReference] = None, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Ultimate creditor. */ + ultimateCreditor: Option[String] = None, + /* Debtor name. */ + debtorName: Option[String] = None, + debtorAccount: Option[AccountReference] = None, + /* BICFI */ + debtorAgent: Option[String] = None, + /* Ultimate debtor. */ + ultimateDebtor: Option[String] = None, + /* Unstructured remittance information. */ + remittanceInformationUnstructured: Option[String] = None, + /* Array of unstructured remittance information. */ + remittanceInformationUnstructuredArray: Option[Seq[String]] = None, + remittanceInformationStructured: Option[RemittanceInformationStructured] = None, + /* Array of structured remittance information. */ + remittanceInformationStructuredArray: Option[Seq[RemittanceInformationStructured]] = None, + purposeCode: Option[PurposeCode] = None +) extends ApiModel + +object EntryDetailsElementEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400AIS.scala new file mode 100644 index 0000000000..10bac123da --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400AIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error400AIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode400AIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error400AISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error400AISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400AISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400AISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..1c2a29fed3 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400AISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error400AISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode400AIS +) extends ApiModel + +object Error400AISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGAIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGAIS.scala new file mode 100644 index 0000000000..efe1dc39d5 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGAIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error400NGAIS ( + tppMessages: Option[Seq[TppMessage400AIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGPIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGPIIS.scala new file mode 100644 index 0000000000..8acb87bc52 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGPIIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error400NGPIIS ( + tppMessages: Option[Seq[TppMessage400PIIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGPIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGPIS.scala new file mode 100644 index 0000000000..9ceed6273e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGPIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error400NGPIS ( + tppMessages: Option[Seq[TppMessage400PIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGSB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGSB.scala new file mode 100644 index 0000000000..551bce142e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGSB.scala @@ -0,0 +1,20 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error400NGSB ( + tppMessages: Option[Seq[TppMessage400SB]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGSBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGSBS.scala new file mode 100644 index 0000000000..f5b6ea65df --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGSBS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error400NGSBS ( + tppMessages: Option[Seq[TppMessage400SBS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PIIS.scala new file mode 100644 index 0000000000..c593fc1d42 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PIIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error400PIIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode400PIIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error400PIISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error400PIISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PIISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PIISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..4bc3963782 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PIISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error400PIISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode400PIIS +) extends ApiModel + +object Error400PIISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PIS.scala new file mode 100644 index 0000000000..f27781f05a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error400PIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode400PIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error400PISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error400PISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..524024d158 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error400PISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode400PIS +) extends ApiModel + +object Error400PISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400SB.scala new file mode 100644 index 0000000000..3a0a4055e2 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400SB.scala @@ -0,0 +1,32 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error400SB ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode400SB, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error400SBAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error400SBEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400SBAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400SBAdditionalErrorsInner.scala new file mode 100644 index 0000000000..38b023428e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400SBAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error400SBAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode400SB +) extends ApiModel + +object Error400SBAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400SBS.scala new file mode 100644 index 0000000000..0c07c4f3ab --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400SBS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error400SBS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode400SBS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error400SBSAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error400SBSEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400SBSAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400SBSAdditionalErrorsInner.scala new file mode 100644 index 0000000000..3f2d66f34d --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400SBSAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error400SBSAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode400SBS +) extends ApiModel + +object Error400SBSAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401AIS.scala new file mode 100644 index 0000000000..d131603a9d --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401AIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error401AIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode401AIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error401AISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error401AISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401AISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401AISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..45e6441c4c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401AISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error401AISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode401AIS +) extends ApiModel + +object Error401AISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGAIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGAIS.scala new file mode 100644 index 0000000000..407bbfd0c2 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGAIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error401NGAIS ( + tppMessages: Option[Seq[TppMessage401AIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGPIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGPIIS.scala new file mode 100644 index 0000000000..c4855e6474 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGPIIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error401NGPIIS ( + tppMessages: Option[Seq[TppMessage401PIIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGPIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGPIS.scala new file mode 100644 index 0000000000..2124155a3a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGPIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error401NGPIS ( + tppMessages: Option[Seq[TppMessage401PIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGSB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGSB.scala new file mode 100644 index 0000000000..33d40bd369 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGSB.scala @@ -0,0 +1,20 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error401NGSB ( + tppMessages: Option[Seq[TppMessage401SB]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGSBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGSBS.scala new file mode 100644 index 0000000000..7664002eb7 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGSBS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error401NGSBS ( + tppMessages: Option[Seq[TppMessage401SBS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PIIS.scala new file mode 100644 index 0000000000..a7dd82e3a6 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PIIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error401PIIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode401PIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error401PIISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error401PIISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PIISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PIISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..a5432d7df7 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PIISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error401PIISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode401PIIS +) extends ApiModel + +object Error401PIISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PIS.scala new file mode 100644 index 0000000000..fd3d8e1870 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error401PIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode401PIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error401PISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error401PISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..4b24e7fc83 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error401PISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode401PIS +) extends ApiModel + +object Error401PISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401SB.scala new file mode 100644 index 0000000000..132e2f5d7b --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401SB.scala @@ -0,0 +1,32 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error401SB ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode401SB, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error401SBAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error401SBEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401SBAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401SBAdditionalErrorsInner.scala new file mode 100644 index 0000000000..ae0c39156d --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401SBAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error401SBAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode401SB +) extends ApiModel + +object Error401SBAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401SBS.scala new file mode 100644 index 0000000000..7448ca4c13 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401SBS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error401SBS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode401SBS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error401SBSAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error401SBSEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401SBSAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401SBSAdditionalErrorsInner.scala new file mode 100644 index 0000000000..73e18a0680 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401SBSAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error401SBSAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode401SBS +) extends ApiModel + +object Error401SBSAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403AIS.scala new file mode 100644 index 0000000000..6b87a08cf9 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403AIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error403AIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode403AIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error403AISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error403AISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403AISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403AISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..34333e6678 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403AISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error403AISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode403AIS +) extends ApiModel + +object Error403AISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGAIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGAIS.scala new file mode 100644 index 0000000000..91d0e2a5ab --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGAIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error403NGAIS ( + tppMessages: Option[Seq[TppMessage403AIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGPIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGPIIS.scala new file mode 100644 index 0000000000..799ff2414c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGPIIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error403NGPIIS ( + tppMessages: Option[Seq[TppMessage403PIIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGPIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGPIS.scala new file mode 100644 index 0000000000..9d6ebe709e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGPIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error403NGPIS ( + tppMessages: Option[Seq[TppMessage403PIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGSB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGSB.scala new file mode 100644 index 0000000000..cb49ebb94d --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGSB.scala @@ -0,0 +1,20 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error403NGSB ( + tppMessages: Option[Seq[TppMessage403SB]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGSBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGSBS.scala new file mode 100644 index 0000000000..ce318943b6 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGSBS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error403NGSBS ( + tppMessages: Option[Seq[TppMessage403SBS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PIIS.scala new file mode 100644 index 0000000000..d2b7ca0507 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PIIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error403PIIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode403PIIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error403PIISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error403PIISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PIISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PIISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..7a7b040a11 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PIISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error403PIISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode403PIIS +) extends ApiModel + +object Error403PIISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PIS.scala new file mode 100644 index 0000000000..8de1cc3042 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error403PIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode403PIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error403PISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error403PISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..5f8ed3dfac --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error403PISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode403PIS +) extends ApiModel + +object Error403PISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403SB.scala new file mode 100644 index 0000000000..33766c57dd --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403SB.scala @@ -0,0 +1,32 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error403SB ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode403SB, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error403SBAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error403SBEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403SBAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403SBAdditionalErrorsInner.scala new file mode 100644 index 0000000000..78b94e134b --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403SBAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error403SBAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode403SB +) extends ApiModel + +object Error403SBAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403SBS.scala new file mode 100644 index 0000000000..3025586c17 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403SBS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error403SBS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode403SBS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error403SBSAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error403SBSEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403SBSAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403SBSAdditionalErrorsInner.scala new file mode 100644 index 0000000000..477a8429f4 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403SBSAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error403SBSAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode403SBS +) extends ApiModel + +object Error403SBSAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404AIS.scala new file mode 100644 index 0000000000..5f487c2ca9 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404AIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error404AIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode404AIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error404AISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error404AISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404AISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404AISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..0f8b7b717a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404AISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error404AISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode404AIS +) extends ApiModel + +object Error404AISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGAIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGAIS.scala new file mode 100644 index 0000000000..3ccdcee138 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGAIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error404NGAIS ( + tppMessages: Option[Seq[TppMessage404AIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGPIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGPIIS.scala new file mode 100644 index 0000000000..c9571523a2 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGPIIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error404NGPIIS ( + tppMessages: Option[Seq[TppMessage404PIIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGPIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGPIS.scala new file mode 100644 index 0000000000..69bc2ab81a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGPIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error404NGPIS ( + tppMessages: Option[Seq[TppMessage404PIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGSB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGSB.scala new file mode 100644 index 0000000000..f5707d8e4c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGSB.scala @@ -0,0 +1,20 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error404NGSB ( + tppMessages: Option[Seq[TppMessage404SB]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGSBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGSBS.scala new file mode 100644 index 0000000000..daccac8c3a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGSBS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error404NGSBS ( + tppMessages: Option[Seq[TppMessage404SBS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PIIS.scala new file mode 100644 index 0000000000..5c05e52e45 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PIIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error404PIIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode404PIIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error404PIISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error404PIISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PIISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PIISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..5e9c458ac2 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PIISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error404PIISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode404PIIS +) extends ApiModel + +object Error404PIISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PIS.scala new file mode 100644 index 0000000000..01cccca0c9 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error404PIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode404PIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error404PISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error404PISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..b6feccd2a9 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error404PISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode404PIS +) extends ApiModel + +object Error404PISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404SB.scala new file mode 100644 index 0000000000..55d808ddd1 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404SB.scala @@ -0,0 +1,32 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error404SB ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode404SB, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error404SBAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error404SBEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404SBAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404SBAdditionalErrorsInner.scala new file mode 100644 index 0000000000..fec1282991 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404SBAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error404SBAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode404SB +) extends ApiModel + +object Error404SBAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404SBS.scala new file mode 100644 index 0000000000..faf320757a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404SBS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error404SBS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode404SBS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error404SBSAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error404SBSEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404SBSAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404SBSAdditionalErrorsInner.scala new file mode 100644 index 0000000000..a151f9e9d2 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404SBSAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error404SBSAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode404SBS +) extends ApiModel + +object Error404SBSAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405AIS.scala new file mode 100644 index 0000000000..3e34afa8d1 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405AIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error405AIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode405AIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error405AISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error405AISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405AISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405AISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..ff5ebb2fe4 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405AISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error405AISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode405AIS +) extends ApiModel + +object Error405AISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGAIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGAIS.scala new file mode 100644 index 0000000000..9d976362ea --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGAIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error405NGAIS ( + tppMessages: Option[Seq[TppMessage405AIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGPIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGPIIS.scala new file mode 100644 index 0000000000..5d05c87ee5 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGPIIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error405NGPIIS ( + tppMessages: Option[Seq[TppMessage405PIIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGPIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGPIS.scala new file mode 100644 index 0000000000..30fb777977 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGPIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error405NGPIS ( + tppMessages: Option[Seq[TppMessage405PIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGPISCANC.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGPISCANC.scala new file mode 100644 index 0000000000..9778bb18eb --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGPISCANC.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error405NGPISCANC ( + tppMessages: Option[Seq[TppMessage405PISCANC]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGSB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGSB.scala new file mode 100644 index 0000000000..b3840f8b4b --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGSB.scala @@ -0,0 +1,20 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error405NGSB ( + tppMessages: Option[Seq[TppMessage405SB]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGSBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGSBS.scala new file mode 100644 index 0000000000..f78dbd8e4f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGSBS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error405NGSBS ( + tppMessages: Option[Seq[TppMessage405SBS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PIIS.scala new file mode 100644 index 0000000000..e01de17a61 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PIIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error405PIIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode405PIIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error405PIISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error405PIISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PIISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PIISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..8d64a92476 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PIISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error405PIISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode405PIIS +) extends ApiModel + +object Error405PIISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PIS.scala new file mode 100644 index 0000000000..75402fdec3 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error405PIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode405PIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error405PISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error405PISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..fd59954439 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error405PISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode405PIS +) extends ApiModel + +object Error405PISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PISCANC.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PISCANC.scala new file mode 100644 index 0000000000..83a80dcf47 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PISCANC.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error405PISCANC ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode405PISCANC, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error405PISCANCAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error405PISCANCEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PISCANCAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PISCANCAdditionalErrorsInner.scala new file mode 100644 index 0000000000..5802a09f57 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PISCANCAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error405PISCANCAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode405PISCANC +) extends ApiModel + +object Error405PISCANCAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405SB.scala new file mode 100644 index 0000000000..799cc30ebc --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405SB.scala @@ -0,0 +1,32 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error405SB ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode405SB, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error405SBAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error405SBEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405SBAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405SBAdditionalErrorsInner.scala new file mode 100644 index 0000000000..34e2e4e51b --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405SBAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error405SBAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode405SB +) extends ApiModel + +object Error405SBAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405SBS.scala new file mode 100644 index 0000000000..c0582a7ad7 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405SBS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error405SBS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode405SBS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error405SBSAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error405SBSEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405SBSAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405SBSAdditionalErrorsInner.scala new file mode 100644 index 0000000000..a6cd535d94 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405SBSAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error405SBSAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode405SBS +) extends ApiModel + +object Error405SBSAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error406AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error406AIS.scala new file mode 100644 index 0000000000..5a6cdf51e6 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error406AIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error406AIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode406AIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error406AISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error406AISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error406AISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error406AISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..4e879b9979 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error406AISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error406AISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode406AIS +) extends ApiModel + +object Error406AISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error406NGAIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error406NGAIS.scala new file mode 100644 index 0000000000..354d7f25a6 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error406NGAIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error406NGAIS ( + tppMessages: Option[Seq[TppMessage406AIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409AIS.scala new file mode 100644 index 0000000000..a69013717a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409AIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error409AIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode409AIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error409AISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error409AISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409AISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409AISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..1d3d550a83 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409AISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error409AISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode409AIS +) extends ApiModel + +object Error409AISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGAIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGAIS.scala new file mode 100644 index 0000000000..9dca575ba3 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGAIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error409NGAIS ( + tppMessages: Option[Seq[TppMessage409AIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGPIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGPIIS.scala new file mode 100644 index 0000000000..2ccee38f24 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGPIIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error409NGPIIS ( + tppMessages: Option[Seq[TppMessage409PIIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGPIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGPIS.scala new file mode 100644 index 0000000000..458c05b70a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGPIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error409NGPIS ( + tppMessages: Option[Seq[TppMessage409PIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGSB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGSB.scala new file mode 100644 index 0000000000..3227e0178c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGSB.scala @@ -0,0 +1,20 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error409NGSB ( + tppMessages: Option[Seq[TppMessage409SB]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGSBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGSBS.scala new file mode 100644 index 0000000000..bb33988dac --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGSBS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error409NGSBS ( + tppMessages: Option[Seq[TppMessage409SBS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PIIS.scala new file mode 100644 index 0000000000..ae4da986aa --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PIIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error409PIIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode409PIIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error409PIISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error409PIISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PIISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PIISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..a1d6a39278 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PIISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error409PIISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode409PIIS +) extends ApiModel + +object Error409PIISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PIS.scala new file mode 100644 index 0000000000..dc6175c331 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error409PIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode409PIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error409PISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error409PISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..9a02a9923d --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error409PISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode409PIS +) extends ApiModel + +object Error409PISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409SB.scala new file mode 100644 index 0000000000..20766aab2a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409SB.scala @@ -0,0 +1,32 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error409SB ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode409SB, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error409SBAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error409SBEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409SBAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409SBAdditionalErrorsInner.scala new file mode 100644 index 0000000000..3f302bf80e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409SBAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error409SBAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode409SB +) extends ApiModel + +object Error409SBAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409SBS.scala new file mode 100644 index 0000000000..ef7de856ca --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409SBS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error409SBS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode409SBS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error409SBSAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error409SBSEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409SBSAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409SBSAdditionalErrorsInner.scala new file mode 100644 index 0000000000..0203a26666 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409SBSAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error409SBSAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode409SBS +) extends ApiModel + +object Error409SBSAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error429AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error429AIS.scala new file mode 100644 index 0000000000..70f5be1cc6 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error429AIS.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.net.URI + + +case class Error429AIS ( + /* A URI reference [RFC3986] that identifies the problem type. Remark For Future: These URI will be provided by NextGenPSD2 in future. */ + `type`: URI, + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode429AIS, + /* Array of Error Information Blocks. Might be used if more than one error is to be communicated */ + additionalErrors: Option[Seq[Error429AISAdditionalErrorsInner]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + +object Error429AISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error429AISAdditionalErrorsInner.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error429AISAdditionalErrorsInner.scala new file mode 100644 index 0000000000..8ed8f611f8 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error429AISAdditionalErrorsInner.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error429AISAdditionalErrorsInner ( + /* Short human readable description of error type. Could be in local language. To be provided by ASPSPs. */ + title: Option[String] = None, + /* Detailed human readable text specific to this instance of the error. XPath might be used to point to the issue generating the error in addition. Remark for Future: In future, a dedicated field might be introduced for the XPath. */ + detail: Option[String] = None, + code: MessageCode429AIS +) extends ApiModel + +object Error429AISAdditionalErrorsInnerEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error429NGAIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error429NGAIS.scala new file mode 100644 index 0000000000..c8f0d8e6d4 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error429NGAIS.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class Error429NGAIS ( + tppMessages: Option[Seq[TppMessage429AIS]] = None, + _links: Option[LinksAll] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ExchangeRate.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ExchangeRate.scala new file mode 100644 index 0000000000..ff65d99894 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ExchangeRate.scala @@ -0,0 +1,27 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class ExchangeRate ( + /* ISO 4217 Alpha 3 currency code */ + sourceCurrency: String, + rate: String, + unitCurrency: String, + /* ISO 4217 Alpha 3 currency code */ + targetCurrency: String, + rateDate: LocalDate, + rateContract: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ExecutionRule.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ExecutionRule.scala new file mode 100644 index 0000000000..9b3395d09e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ExecutionRule.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class ExecutionRule ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/FrequencyCode.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/FrequencyCode.scala new file mode 100644 index 0000000000..bc48d94ba3 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/FrequencyCode.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class FrequencyCode ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetPaymentInformation200Response.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetPaymentInformation200Response.scala new file mode 100644 index 0000000000..7ccc7e59bf --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetPaymentInformation200Response.scala @@ -0,0 +1,51 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate +import java.time.OffsetDateTime + + +case class GetPaymentInformation200Response ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor name. */ + creditorName: String, + creditorAddress: Option[Address] = None, + /* Unstructured remittance information. */ + remittanceInformationUnstructured: Option[String] = None, + transactionStatus: Option[TransactionStatus] = None, + /* Messages to the TPP on operational issues. */ + tppMessage: Option[Seq[TppMessageGeneric]] = None, + /* The first applicable day of execution starting from this date is the first payment. */ + startDate: LocalDate, + /* The last applicable day of execution. If not given, it is an infinite standing order. */ + endDate: Option[LocalDate] = None, + executionRule: Option[ExecutionRule] = None, + frequency: FrequencyCode, + dayOfExecution: Option[DayOfExecution] = None, + /* If this element equals 'true', the PSU prefers only one booking entry. If this element equals 'false', the PSU prefers individual booking of all contained individual transactions. The ASPSP will follow this preference according to contracts agreed on with the PSU. */ + batchBookingPreferred: Option[Boolean] = None, + requestedExecutionDate: Option[LocalDate] = None, + acceptorTransactionDateTime: Option[OffsetDateTime] = None, + paymentInformationId: Option[String] = None, + /* A list of generic JSON bodies payment initiations for bulk payments via JSON. Note: Some fields from single payments do not occur in a bulk payment element */ + payments: Seq[PaymentInitiationBulkElementJson] +) extends ApiModel + +object GetPaymentInformation200ResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetTransactionDetails200Response.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetTransactionDetails200Response.scala new file mode 100644 index 0000000000..dcd2b4ec15 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetTransactionDetails200Response.scala @@ -0,0 +1,19 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class GetTransactionDetails200Response ( + transactionsDetails: TransactionDetailsBody +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetTransactionList200Response.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetTransactionList200Response.scala new file mode 100644 index 0000000000..ab4053e644 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetTransactionList200Response.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class GetTransactionList200Response ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetTransactionList200Response1.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetTransactionList200Response1.scala new file mode 100644 index 0000000000..02ee211214 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetTransactionList200Response1.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class GetTransactionList200Response1 ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/HrefType.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/HrefType.scala new file mode 100644 index 0000000000..297156f114 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/HrefType.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class HrefType ( + /* Link to a resource. */ + href: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/InitiatePayment201Response.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/InitiatePayment201Response.scala new file mode 100644 index 0000000000..11ce248e04 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/InitiatePayment201Response.scala @@ -0,0 +1,35 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class InitiatePayment201Response ( + transactionStatus: TransactionStatus, + /* Resource identification of the generated payment initiation resource. */ + paymentId: String, + transactionFees: Option[Amount] = None, + /* If equals 'true', the transaction will involve specific transaction cost as shown by the ASPSP in their public price list or as agreed between ASPSP and PSU. If equals 'false', the transaction will not involve additional specific transaction costs to the PSU. */ + transactionFeeIndicator: Option[Boolean] = None, + /* This data element might be contained, if SCA is required and if the PSU has a choice between different authentication methods. Depending on the risk management of the ASPSP this choice might be offered before or after the PSU has been identified with the first relevant factor, or if an access token is transported. If this data element is contained, then there is also an hyperlink of type 'startAuthorisationWithAuthenticationMethodSelection' contained in the response body. These methods shall be presented towards the PSU for selection by the TPP. */ + scaMethods: Option[Seq[AuthenticationObject]] = None, + chosenScaMethod: Option[AuthenticationObject] = None, + challengeData: Option[ChallengeData] = None, + links: LinksPaymentInitiationMultiLevelSca, + /* Text to be displayed to the PSU */ + psuMessage: Option[String] = None, + tppMessages: Option[Seq[TppMessage2XX]] = None +) extends ApiModel + +object InitiatePayment201ResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/InitiatePaymentRequest.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/InitiatePaymentRequest.scala new file mode 100644 index 0000000000..5f96c1e086 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/InitiatePaymentRequest.scala @@ -0,0 +1,51 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate +import java.time.OffsetDateTime + + +case class InitiatePaymentRequest ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor agent name. */ + creditorAgentName: Option[String] = None, + /* Creditor name. */ + creditorName: String, + creditorAddress: Option[Address] = None, + /* Unstructured remittance information. */ + remittanceInformationUnstructured: Option[String] = None, + /* The first applicable day of execution starting from this date is the first payment. */ + startDate: LocalDate, + /* The last applicable day of execution. If not given, it is an infinite standing order. */ + endDate: Option[LocalDate] = None, + executionRule: Option[ExecutionRule] = None, + frequency: FrequencyCode, + dayOfExecution: Option[DayOfExecution] = None, + /* The format is following the regular expression \\d{1,2}. The array is restricted to 11 entries. The values contained in the array entries shall all be different and the maximum value of one entry is 12. This attribute is contained if and only if the frequency equals \"MonthlyVariable\". Example: An execution on January, April and October each year is addressed by [\"1\", \"4\", \"10\"]. */ + monthsOfExecution: Option[InitiatePaymentRequestEnums.type] = None, + /* If this element equals 'true', the PSU prefers only one booking entry. If this element equals 'false', the PSU prefers individual booking of all contained individual transactions. The ASPSP will follow this preference according to contracts agreed on with the PSU. */ + batchBookingPreferred: Option[Boolean] = None, + requestedExecutionDate: Option[LocalDate] = None, + requestedExecutionTime: Option[OffsetDateTime] = None, + /* A list of generic JSON bodies payment initiations for bulk payments via JSON. Note: Some fields from single payments do not occur in a bulk payment element */ + payments: Seq[PaymentInitiationBulkElementJson] +) extends ApiModel + +object InitiatePaymentRequestEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/InitiatePaymentRequest1.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/InitiatePaymentRequest1.scala new file mode 100644 index 0000000000..52c1d1b2f8 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/InitiatePaymentRequest1.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class InitiatePaymentRequest1 ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAccountDetails.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAccountDetails.scala new file mode 100644 index 0000000000..f25fa3651c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAccountDetails.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class LinksAccountDetails ( + balances: Option[HrefType] = None, + transactions: Option[HrefType] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAccountReport.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAccountReport.scala new file mode 100644 index 0000000000..0c3bf1f3ce --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAccountReport.scala @@ -0,0 +1,23 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class LinksAccountReport ( + account: HrefType, + first: Option[HrefType] = None, + next: Option[HrefType] = None, + previous: Option[HrefType] = None, + last: Option[HrefType] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAll.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAll.scala new file mode 100644 index 0000000000..0cd24750b9 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAll.scala @@ -0,0 +1,50 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class LinksAll ( + scaRedirect: Option[HrefType] = None, + scaOAuth: Option[HrefType] = None, + confirmation: Option[HrefType] = None, + startAuthorisation: Option[HrefType] = None, + startAuthorisationWithPsuIdentification: Option[HrefType] = None, + updatePsuIdentification: Option[HrefType] = None, + startAuthorisationWithProprietaryData: Option[HrefType] = None, + updateProprietaryData: Option[HrefType] = None, + startAuthorisationWithPsuAuthentication: Option[HrefType] = None, + updatePsuAuthentication: Option[HrefType] = None, + startAuthorisationWithEncryptedPsuAuthentication: Option[HrefType] = None, + updateEncryptedPsuAuthentication: Option[HrefType] = None, + updateAdditionalPsuAuthentication: Option[HrefType] = None, + updateAdditionalEncryptedPsuAuthentication: Option[HrefType] = None, + startAuthorisationWithAuthenticationMethodSelection: Option[HrefType] = None, + selectAuthenticationMethod: Option[HrefType] = None, + startAuthorisationWithTransactionAuthorisation: Option[HrefType] = None, + authoriseTransaction: Option[HrefType] = None, + self: Option[HrefType] = None, + status: Option[HrefType] = None, + scaStatus: Option[HrefType] = None, + account: Option[HrefType] = None, + balances: Option[HrefType] = None, + transactions: Option[HrefType] = None, + transactionDetails: Option[HrefType] = None, + cardAccount: Option[HrefType] = None, + cardTransactions: Option[HrefType] = None, + first: Option[HrefType] = None, + next: Option[HrefType] = None, + previous: Option[HrefType] = None, + last: Option[HrefType] = None, + download: Option[HrefType] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAuthorisationConfirmation.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAuthorisationConfirmation.scala new file mode 100644 index 0000000000..7d55256fd5 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAuthorisationConfirmation.scala @@ -0,0 +1,19 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class LinksAuthorisationConfirmation ( + scaStatus: Option[HrefType] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksCardAccountReport.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksCardAccountReport.scala new file mode 100644 index 0000000000..efd1b4e325 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksCardAccountReport.scala @@ -0,0 +1,24 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class LinksCardAccountReport ( + cardAccount: Option[HrefType] = None, + card: Option[HrefType] = None, + first: Option[HrefType] = None, + next: Option[HrefType] = None, + previous: Option[HrefType] = None, + last: Option[HrefType] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksConsents.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksConsents.scala new file mode 100644 index 0000000000..cf18a7a16f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksConsents.scala @@ -0,0 +1,30 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class LinksConsents ( + scaRedirect: Option[HrefType] = None, + scaOAuth: Option[HrefType] = None, + confirmation: Option[HrefType] = None, + startAuthorisation: Option[HrefType] = None, + startAuthorisationWithPsuIdentification: Option[HrefType] = None, + startAuthorisationWithPsuAuthentication: Option[HrefType] = None, + startAuthorisationWithEncryptedPsuAuthentication: Option[HrefType] = None, + startAuthorisationWithAuthenticationMethodSelection: Option[HrefType] = None, + startAuthorisationWithTransactionAuthorisation: Option[HrefType] = None, + self: Option[HrefType] = None, + status: Option[HrefType] = None, + scaStatus: Option[HrefType] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksDownload.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksDownload.scala new file mode 100644 index 0000000000..e342f0fcb7 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksDownload.scala @@ -0,0 +1,19 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class LinksDownload ( + download: HrefType +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksGetConsent.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksGetConsent.scala new file mode 100644 index 0000000000..83ea20bf8e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksGetConsent.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class LinksGetConsent ( + account: Option[HrefType] = None, + cardAccount: Option[HrefType] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksPaymentInitiation.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksPaymentInitiation.scala new file mode 100644 index 0000000000..c07287943b --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksPaymentInitiation.scala @@ -0,0 +1,30 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class LinksPaymentInitiation ( + scaRedirect: Option[HrefType] = None, + scaOAuth: Option[HrefType] = None, + confirmation: Option[HrefType] = None, + startAuthorisation: Option[HrefType] = None, + startAuthorisationWithPsuIdentification: Option[HrefType] = None, + startAuthorisationWithPsuAuthentication: Option[HrefType] = None, + startAuthorisationWithEncryptedPsuAuthentication: Option[HrefType] = None, + startAuthorisationWithAuthenticationMethodSelection: Option[HrefType] = None, + startAuthorisationWithTransactionAuthorisation: Option[HrefType] = None, + self: Option[HrefType] = None, + status: Option[HrefType] = None, + scaStatus: Option[HrefType] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksPaymentInitiationCancel.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksPaymentInitiationCancel.scala new file mode 100644 index 0000000000..55762151ea --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksPaymentInitiationCancel.scala @@ -0,0 +1,23 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class LinksPaymentInitiationCancel ( + startAuthorisation: Option[HrefType] = None, + startAuthorisationWithPsuIdentification: Option[HrefType] = None, + startAuthorisationWithPsuAuthentication: Option[HrefType] = None, + startAuthorisationWithEncryptedPsuAuthentication: Option[HrefType] = None, + startAuthorisationWithAuthenticationMethodSelection: Option[HrefType] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksPaymentInitiationMultiLevelSca.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksPaymentInitiationMultiLevelSca.scala new file mode 100644 index 0000000000..4586d2a90c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksPaymentInitiationMultiLevelSca.scala @@ -0,0 +1,28 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class LinksPaymentInitiationMultiLevelSca ( + /* Link to a resource */ + startAuthorisation: Option[String] = None, + /* Link to a resource */ + startAuthorisationWithPsuIdentification: Option[String] = None, + /* Link to a resource */ + startAuthorisationWithPsuAuthentication: Option[String] = None, + /* Link to a resource */ + self: Option[String] = None, + /* Link to a resource */ + status: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksSelectPsuAuthenticationMethod.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksSelectPsuAuthenticationMethod.scala new file mode 100644 index 0000000000..5e2608d84c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksSelectPsuAuthenticationMethod.scala @@ -0,0 +1,27 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class LinksSelectPsuAuthenticationMethod ( + scaRedirect: Option[HrefType] = None, + scaOAuth: Option[HrefType] = None, + confirmation: Option[HrefType] = None, + updatePsuIdentification: Option[HrefType] = None, + updatePsuAuthentication: Option[HrefType] = None, + updateAdditionalPsuAuthentication: Option[HrefType] = None, + updateAdditionalEncryptedPsuAuthentication: Option[HrefType] = None, + authoriseTransaction: Option[HrefType] = None, + scaStatus: Option[HrefType] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksSigningBasket.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksSigningBasket.scala new file mode 100644 index 0000000000..872c1abde8 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksSigningBasket.scala @@ -0,0 +1,29 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class LinksSigningBasket ( + scaRedirect: Option[HrefType] = None, + scaOAuth: Option[HrefType] = None, + startAuthorisation: Option[HrefType] = None, + startAuthorisationWithPsuIdentification: Option[HrefType] = None, + startAuthorisationWithPsuAuthentication: Option[HrefType] = None, + startAuthorisationWithEncryptedPsuAuthentication: Option[HrefType] = None, + startAuthorisationWithAuthenticationMethodSelection: Option[HrefType] = None, + startAuthorisationWithTransactionAuthorisation: Option[HrefType] = None, + self: Option[HrefType] = None, + status: Option[HrefType] = None, + scaStatus: Option[HrefType] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksStartScaProcess.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksStartScaProcess.scala new file mode 100644 index 0000000000..54ada32ce3 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksStartScaProcess.scala @@ -0,0 +1,27 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class LinksStartScaProcess ( + scaRedirect: Option[HrefType] = None, + scaOAuth: Option[HrefType] = None, + confirmation: Option[HrefType] = None, + updatePsuIdentification: Option[HrefType] = None, + startAuthorisationWithPsuAuthentication: Option[HrefType] = None, + startAuthorisationWithEncryptedPsuAuthentication: Option[HrefType] = None, + selectAuthenticationMethod: Option[HrefType] = None, + authoriseTransaction: Option[HrefType] = None, + scaStatus: Option[HrefType] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksTransactionDetails.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksTransactionDetails.scala new file mode 100644 index 0000000000..4930ddd227 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksTransactionDetails.scala @@ -0,0 +1,19 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class LinksTransactionDetails ( + transactionDetails: HrefType +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksUpdatePsuAuthentication.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksUpdatePsuAuthentication.scala new file mode 100644 index 0000000000..d07984785e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksUpdatePsuAuthentication.scala @@ -0,0 +1,23 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class LinksUpdatePsuAuthentication ( + updateAdditionalPsuAuthentication: Option[HrefType] = None, + updateAdditionalEncryptedPsuAuthentication: Option[HrefType] = None, + selectAuthenticationMethod: Option[HrefType] = None, + authoriseTransaction: Option[HrefType] = None, + scaStatus: Option[HrefType] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksUpdatePsuIdentification.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksUpdatePsuIdentification.scala new file mode 100644 index 0000000000..7098d007fd --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksUpdatePsuIdentification.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class LinksUpdatePsuIdentification ( + scaStatus: Option[HrefType] = None, + selectAuthenticationMethod: Option[HrefType] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode200InitiationStatus.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode200InitiationStatus.scala new file mode 100644 index 0000000000..e336c06338 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode200InitiationStatus.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode200InitiationStatus ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode201PaymentInitiation.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode201PaymentInitiation.scala new file mode 100644 index 0000000000..7981f5cfb3 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode201PaymentInitiation.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode201PaymentInitiation ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode2XX.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode2XX.scala new file mode 100644 index 0000000000..76bf720abb --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode2XX.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode2XX ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400AIS.scala new file mode 100644 index 0000000000..7f4cb42943 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400AIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode400AIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400PIIS.scala new file mode 100644 index 0000000000..78e37123b6 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400PIIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode400PIIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400PIS.scala new file mode 100644 index 0000000000..be2f041d6d --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400PIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode400PIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400SB.scala new file mode 100644 index 0000000000..398ed9fe15 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400SB.scala @@ -0,0 +1,18 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode400SB ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400SBS.scala new file mode 100644 index 0000000000..59779ad4b5 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400SBS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode400SBS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401AIS.scala new file mode 100644 index 0000000000..7411c8844c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401AIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode401AIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401PIIS.scala new file mode 100644 index 0000000000..4a2f998e74 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401PIIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode401PIIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401PIS.scala new file mode 100644 index 0000000000..5266963c17 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401PIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode401PIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401SB.scala new file mode 100644 index 0000000000..017c829886 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401SB.scala @@ -0,0 +1,18 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode401SB ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401SBS.scala new file mode 100644 index 0000000000..1fd9e6cb29 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401SBS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode401SBS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403AIS.scala new file mode 100644 index 0000000000..358c8bf280 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403AIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode403AIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403PIIS.scala new file mode 100644 index 0000000000..eaaa87f24b --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403PIIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode403PIIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403PIS.scala new file mode 100644 index 0000000000..24f157e16f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403PIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode403PIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403SB.scala new file mode 100644 index 0000000000..182f6e251b --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403SB.scala @@ -0,0 +1,18 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode403SB ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403SBS.scala new file mode 100644 index 0000000000..8a2d9c1250 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403SBS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode403SBS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404AIS.scala new file mode 100644 index 0000000000..076de9ffe1 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404AIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode404AIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404PIIS.scala new file mode 100644 index 0000000000..9ad5edcebe --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404PIIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode404PIIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404PIS.scala new file mode 100644 index 0000000000..44ebe4b0d5 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404PIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode404PIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404SB.scala new file mode 100644 index 0000000000..3ca941afba --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404SB.scala @@ -0,0 +1,18 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode404SB ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404SBS.scala new file mode 100644 index 0000000000..5129fb3604 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404SBS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode404SBS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405AIS.scala new file mode 100644 index 0000000000..0960578189 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405AIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode405AIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405PIIS.scala new file mode 100644 index 0000000000..a37df32f2a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405PIIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode405PIIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405PIS.scala new file mode 100644 index 0000000000..9cee5f94ed --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405PIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode405PIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405PISCANC.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405PISCANC.scala new file mode 100644 index 0000000000..85eec67aa7 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405PISCANC.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode405PISCANC ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405SB.scala new file mode 100644 index 0000000000..ee0965927c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405SB.scala @@ -0,0 +1,18 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode405SB ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405SBS.scala new file mode 100644 index 0000000000..1c7881169c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405SBS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode405SBS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode406AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode406AIS.scala new file mode 100644 index 0000000000..477168a589 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode406AIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode406AIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409AIS.scala new file mode 100644 index 0000000000..edd4130967 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409AIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode409AIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409PIIS.scala new file mode 100644 index 0000000000..9120292a6f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409PIIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode409PIIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409PIS.scala new file mode 100644 index 0000000000..7d22e1bc26 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409PIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode409PIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409SB.scala new file mode 100644 index 0000000000..db18a320fc --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409SB.scala @@ -0,0 +1,18 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode409SB ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409SBS.scala new file mode 100644 index 0000000000..af149e4e69 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409SBS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode409SBS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode429AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode429AIS.scala new file mode 100644 index 0000000000..85c316c993 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode429AIS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class MessageCode429AIS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/OtherType.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/OtherType.scala new file mode 100644 index 0000000000..c6e1672ae8 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/OtherType.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class OtherType ( + /* Proprietary identification of the account. */ + identification: String, + /* An entry provided by an external ISO code list. */ + schemeNameCode: Option[String] = None, + /* A scheme name defined in a proprietary way. */ + schemeNameProprietary: Option[String] = None, + /* Issuer of the identification. */ + issuer: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentExchangeRate.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentExchangeRate.scala new file mode 100644 index 0000000000..dcba0c5945 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentExchangeRate.scala @@ -0,0 +1,33 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentExchangeRate ( + /* ISO 4217 Alpha 3 currency code. */ + unitCurrency: Option[String] = None, + exchangeRate: Option[String] = None, + contractIdentification: Option[String] = None, + rateType: Option[PaymentExchangeRateEnums.RateType] = None +) extends ApiModel + +object PaymentExchangeRateEnums { + + type RateType = RateType.Value + object RateType extends Enumeration { + val SPOT = Value("SPOT") + val SALE = Value("SALE") + val AGRD = Value("AGRD") + } + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitationRequestMultiLevelScaResponse201.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitationRequestMultiLevelScaResponse201.scala new file mode 100644 index 0000000000..cd6d47e9c0 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitationRequestMultiLevelScaResponse201.scala @@ -0,0 +1,31 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitationRequestMultiLevelScaResponse201 ( + transactionStatus: TransactionStatus, + /* Resource identification of the generated payment initiation resource. */ + paymentId: String, + transactionFees: Option[Amount] = None, + /* If equals 'true', the transaction will involve specific transaction cost as shown by the ASPSP in their public price list or as agreed between ASPSP and PSU. If equals 'false', the transaction will not involve additional specific transaction costs to the PSU. */ + transactionFeeIndicator: Option[Boolean] = None, + links: LinksPaymentInitiationMultiLevelSca, + /* Text to be displayed to the PSU */ + psuMessage: Option[String] = None, + tppMessages: Option[Seq[TppMessage2XX]] = None +) extends ApiModel + +object PaymentInitationRequestMultiLevelScaResponse201Enums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitationRequestResponse201.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitationRequestResponse201.scala new file mode 100644 index 0000000000..328c4fd306 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitationRequestResponse201.scala @@ -0,0 +1,35 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitationRequestResponse201 ( + transactionStatus: TransactionStatus, + /* Resource identification of the generated payment initiation resource. */ + paymentId: String, + transactionFees: Option[Amount] = None, + /* If equals 'true', the transaction will involve specific transaction cost as shown by the ASPSP in their public price list or as agreed between ASPSP and PSU. If equals 'false', the transaction will not involve additional specific transaction costs to the PSU. */ + transactionFeeIndicator: Option[Boolean] = None, + /* This data element might be contained, if SCA is required and if the PSU has a choice between different authentication methods. Depending on the risk management of the ASPSP this choice might be offered before or after the PSU has been identified with the first relevant factor, or if an access token is transported. If this data element is contained, then there is also an hyperlink of type 'startAuthorisationWithAuthenticationMethodSelection' contained in the response body. These methods shall be presented towards the PSU for selection by the TPP. */ + scaMethods: Option[Seq[AuthenticationObject]] = None, + chosenScaMethod: Option[AuthenticationObject] = None, + challengeData: Option[ChallengeData] = None, + links: LinksPaymentInitiation, + /* Text to be displayed to the PSU */ + psuMessage: Option[String] = None, + tppMessages: Option[Seq[TppMessage2XX]] = None +) extends ApiModel + +object PaymentInitationRequestResponse201Enums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationBulkElementJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationBulkElementJson.scala new file mode 100644 index 0000000000..5b97fe6b9f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationBulkElementJson.scala @@ -0,0 +1,30 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationBulkElementJson ( + endToEndIdentification: Option[String] = None, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor agent name. */ + creditorAgentName: Option[String] = None, + /* Creditor name. */ + creditorName: String, + creditorAddress: Option[Address] = None, + /* Unstructured remittance information. */ + remittanceInformationUnstructured: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCancelResponse202.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCancelResponse202.scala new file mode 100644 index 0000000000..c06089ced5 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCancelResponse202.scala @@ -0,0 +1,27 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationCancelResponse202 ( + transactionStatus: TransactionStatus, + /* This data element might be contained, if SCA is required and if the PSU has a choice between different authentication methods. Depending on the risk management of the ASPSP this choice might be offered before or after the PSU has been identified with the first relevant factor, or if an access token is transported. If this data element is contained, then there is also a hyperlink of type 'startAuthorisationWithAuthenticationMethodSelection' contained in the response body. These methods shall be presented towards the PSU for selection by the TPP. */ + scaMethods: Option[Seq[AuthenticationObject]] = None, + chosenScaMethod: Option[AuthenticationObject] = None, + challengeData: Option[ChallengeData] = None, + _links: Option[LinksPaymentInitiationCancel] = None +) extends ApiModel + +object PaymentInitiationCancelResponse202Enums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCancelResponse204202.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCancelResponse204202.scala new file mode 100644 index 0000000000..218c8578f6 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCancelResponse204202.scala @@ -0,0 +1,27 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationCancelResponse204202 ( + transactionStatus: TransactionStatus, + /* This data element might be contained, if SCA is required and if the PSU has a choice between different authentication methods. Depending on the risk management of the ASPSP this choice might be offered before or after the PSU has been identified with the first relevant factor, or if an access token is transported. If this data element is contained, then there is also an hyperlink of type 'startAuthorisationWithAuthenticationMethodSelection' contained in the response body. These methods shall be presented towards the PSU for selection by the TPP. */ + scaMethods: Option[Seq[AuthenticationObject]] = None, + chosenScaMethod: Option[AuthenticationObject] = None, + challengeData: Option[ChallengeData] = None, + _links: Option[LinksPaymentInitiationCancel] = None +) extends ApiModel + +object PaymentInitiationCancelResponse204202Enums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCrossBorderBulkElementJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCrossBorderBulkElementJson.scala new file mode 100644 index 0000000000..b1b4603eb8 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCrossBorderBulkElementJson.scala @@ -0,0 +1,26 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationCrossBorderBulkElementJson ( + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + remittanceInformationUnstructured: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCrossBorderJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCrossBorderJson.scala new file mode 100644 index 0000000000..161a2f4bd3 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCrossBorderJson.scala @@ -0,0 +1,27 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationCrossBorderJson ( + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + remittanceInformationUnstructured: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCrossBorderWithStatusResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCrossBorderWithStatusResponse.scala new file mode 100644 index 0000000000..2648511c73 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCrossBorderWithStatusResponse.scala @@ -0,0 +1,31 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationCrossBorderWithStatusResponse ( + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + remittanceInformationUnstructured: Option[String] = None, + transactionStatus: Option[TransactionStatus] = None +) extends ApiModel + +object PaymentInitiationCrossBorderWithStatusResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationJson.scala new file mode 100644 index 0000000000..935860d1c8 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationJson.scala @@ -0,0 +1,31 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationJson ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor agent name. */ + creditorAgentName: Option[String] = None, + /* Creditor name. */ + creditorName: String, + creditorAddress: Option[Address] = None, + /* Unstructured remittance information. */ + remittanceInformationUnstructured: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationRequestResponse201.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationRequestResponse201.scala new file mode 100644 index 0000000000..a35b2b8436 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationRequestResponse201.scala @@ -0,0 +1,38 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationRequestResponse201 ( + transactionStatus: TransactionStatus, + /* Resource identification of the generated payment initiation resource. */ + paymentId: String, + transactionFees: Option[Amount] = None, + currencyConversionFee: Option[Amount] = None, + estimatedTotalAmount: Option[Amount] = None, + estimatedInterbankSettlementAmount: Option[Amount] = None, + /* If equals 'true', the transaction will involve specific transaction cost as shown by the ASPSP in their public price list or as agreed between ASPSP and PSU. If equals 'false', the transaction will not involve additional specific transaction costs to the PSU unless the fee amount is given specifically in the data elements transactionFees and/or currencyConversionFees. If this data element is not used, there is no information about transaction fees unless the fee amount is given explicitly in the data element transactionFees and/or currencyConversionFees. */ + transactionFeeIndicator: Option[Boolean] = None, + /* This data element might be contained, if SCA is required and if the PSU has a choice between different authentication methods. Depending on the risk management of the ASPSP this choice might be offered before or after the PSU has been identified with the first relevant factor, or if an access token is transported. If this data element is contained, then there is also a hyperlink of type 'startAuthorisationWithAuthenticationMethodSelection' contained in the response body. These methods shall be presented towards the PSU for selection by the TPP. */ + scaMethods: Option[Seq[AuthenticationObject]] = None, + chosenScaMethod: Option[AuthenticationObject] = None, + challengeData: Option[ChallengeData] = None, + links: LinksPaymentInitiation, + /* Text to be displayed to the PSU. */ + psuMessage: Option[String] = None, + tppMessages: Option[Seq[TppMessage201PaymentInitiation]] = None +) extends ApiModel + +object PaymentInitiationRequestResponse201Enums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctBulkElementJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctBulkElementJson.scala new file mode 100644 index 0000000000..dbdb003ab9 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctBulkElementJson.scala @@ -0,0 +1,28 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationSctBulkElementJson ( + endToEndIdentification: Option[String] = None, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + /* Unstructured remittance information */ + remittanceInformationUnstructured: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctInstBulkElementJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctInstBulkElementJson.scala new file mode 100644 index 0000000000..d9f88e9cfa --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctInstBulkElementJson.scala @@ -0,0 +1,27 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationSctInstBulkElementJson ( + endToEndIdentification: Option[String] = None, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + remittanceInformationUnstructured: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctInstJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctInstJson.scala new file mode 100644 index 0000000000..41bcd490c0 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctInstJson.scala @@ -0,0 +1,28 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationSctInstJson ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + remittanceInformationUnstructured: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctInstWithStatusResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctInstWithStatusResponse.scala new file mode 100644 index 0000000000..609e243aee --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctInstWithStatusResponse.scala @@ -0,0 +1,32 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationSctInstWithStatusResponse ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + remittanceInformationUnstructured: Option[String] = None, + transactionStatus: Option[TransactionStatus] = None +) extends ApiModel + +object PaymentInitiationSctInstWithStatusResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctJson.scala new file mode 100644 index 0000000000..a382fca790 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctJson.scala @@ -0,0 +1,29 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationSctJson ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + /* Unstructured remittance information */ + remittanceInformationUnstructured: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctWithStatusResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctWithStatusResponse.scala new file mode 100644 index 0000000000..7e6178d1e3 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctWithStatusResponse.scala @@ -0,0 +1,33 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationSctWithStatusResponse ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + /* Unstructured remittance information */ + remittanceInformationUnstructured: Option[String] = None, + transactionStatus: Option[TransactionStatus] = None +) extends ApiModel + +object PaymentInitiationSctWithStatusResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationStatusResponse200Json.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationStatusResponse200Json.scala new file mode 100644 index 0000000000..ac2ed44ea5 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationStatusResponse200Json.scala @@ -0,0 +1,34 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationStatusResponse200Json ( + transactionStatus: TransactionStatus, + /* Equals true if sufficient funds are available at the time of the request, false otherwise. This data element is allways contained in a confirmation of funds response. This data element is contained in a payment status response, if supported by the ASPSP, if a funds check has been performed and if the transactionStatus is \"ACTC\", \"ACWC\" or \"ACCP\". */ + fundsAvailable: Option[Boolean] = None, + /* Text to be displayed to the PSU. */ + psuMessage: Option[String] = None, + /* List of owner names. Should only be delivered after successful SCA. Could be restricted to the current PSU by the ASPSP. */ + ownerNames: Option[Seq[AccountOwner]] = None, + /* Name of the PSU. In case of a corporate account, this might be the person acting on behalf of the corporate. */ + psuName: Option[String] = None, + /* Should refer to next steps if the problem can be resolved via the interface e.g. for re-submission of credentials. */ + _links: Option[Map[String, HrefType]] = None, + /* Messages to the TPP on operational issues. */ + tppMessage: Option[Seq[TppMessageGeneric]] = None +) extends ApiModel + +object PaymentInitiationStatusResponse200JsonEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationTarget2BulkElementJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationTarget2BulkElementJson.scala new file mode 100644 index 0000000000..36eca5dd86 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationTarget2BulkElementJson.scala @@ -0,0 +1,27 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationTarget2BulkElementJson ( + endToEndIdentification: Option[String] = None, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + remittanceInformationUnstructured: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationTarget2Json.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationTarget2Json.scala new file mode 100644 index 0000000000..4996edc61f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationTarget2Json.scala @@ -0,0 +1,28 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationTarget2Json ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + remittanceInformationUnstructured: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationTarget2WithStatusResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationTarget2WithStatusResponse.scala new file mode 100644 index 0000000000..4459149239 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationTarget2WithStatusResponse.scala @@ -0,0 +1,32 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationTarget2WithStatusResponse ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + remittanceInformationUnstructured: Option[String] = None, + transactionStatus: Option[TransactionStatus] = None +) extends ApiModel + +object PaymentInitiationTarget2WithStatusResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationWithStatusResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationWithStatusResponse.scala new file mode 100644 index 0000000000..0fc387a283 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationWithStatusResponse.scala @@ -0,0 +1,35 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PaymentInitiationWithStatusResponse ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor name. */ + creditorName: String, + creditorAddress: Option[Address] = None, + /* Unstructured remittance information. */ + remittanceInformationUnstructured: Option[String] = None, + transactionStatus: Option[TransactionStatus] = None, + /* Messages to the TPP on operational issues. */ + tppMessage: Option[Seq[TppMessageGeneric]] = None +) extends ApiModel + +object PaymentInitiationWithStatusResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationCrossBorderJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationCrossBorderJson.scala new file mode 100644 index 0000000000..41d0ed46f1 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationCrossBorderJson.scala @@ -0,0 +1,38 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class PeriodicPaymentInitiationCrossBorderJson ( + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + remittanceInformationUnstructured: Option[String] = None, + /* The first applicable day of execution starting from this date is the first payment. */ + startDate: LocalDate, + /* The last applicable day of execution If not given, it is an infinite standing order. */ + endDate: Option[LocalDate] = None, + executionRule: Option[ExecutionRule] = None, + frequency: FrequencyCode, + dayOfExecution: Option[DayOfExecution] = None +) extends ApiModel + +object PeriodicPaymentInitiationCrossBorderJsonEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationCrossBorderWithStatusResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationCrossBorderWithStatusResponse.scala new file mode 100644 index 0000000000..998bd0b2a2 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationCrossBorderWithStatusResponse.scala @@ -0,0 +1,39 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class PeriodicPaymentInitiationCrossBorderWithStatusResponse ( + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + remittanceInformationUnstructured: Option[String] = None, + /* The first applicable day of execution starting from this date is the first payment. */ + startDate: LocalDate, + /* The last applicable day of execution If not given, it is an infinite standing order. */ + endDate: Option[LocalDate] = None, + executionRule: Option[ExecutionRule] = None, + frequency: FrequencyCode, + dayOfExecution: Option[DayOfExecution] = None, + transactionStatus: Option[TransactionStatus] = None +) extends ApiModel + +object PeriodicPaymentInitiationCrossBorderWithStatusResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationJson.scala new file mode 100644 index 0000000000..b67e6f92dd --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationJson.scala @@ -0,0 +1,42 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class PeriodicPaymentInitiationJson ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor name. */ + creditorName: String, + creditorAddress: Option[Address] = None, + /* Unstructured remittance information. */ + remittanceInformationUnstructured: Option[String] = None, + /* The first applicable day of execution starting from this date is the first payment. */ + startDate: LocalDate, + /* The last applicable day of execution. If not given, it is an infinite standing order. */ + endDate: Option[LocalDate] = None, + executionRule: Option[ExecutionRule] = None, + frequency: FrequencyCode, + dayOfExecution: Option[DayOfExecution] = None, + /* The format is following the regular expression \\d{1,2}. The array is restricted to 11 entries. The values contained in the array entries shall all be different and the maximum value of one entry is 12. This attribute is contained if and only if the frequency equals \"MonthlyVariable\". Example: An execution on January, April and October each year is addressed by [\"1\", \"4\", \"10\"]. */ + monthsOfExecution: Option[PeriodicPaymentInitiationJsonEnums.type ] = None +) extends ApiModel + +object PeriodicPaymentInitiationJsonEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationSctInstJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationSctInstJson.scala new file mode 100644 index 0000000000..774ae5ce20 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationSctInstJson.scala @@ -0,0 +1,39 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class PeriodicPaymentInitiationSctInstJson ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + remittanceInformationUnstructured: Option[String] = None, + /* The first applicable day of execution starting from this date is the first payment. */ + startDate: LocalDate, + /* The last applicable day of execution If not given, it is an infinite standing order. */ + endDate: Option[LocalDate] = None, + executionRule: Option[ExecutionRule] = None, + frequency: FrequencyCode, + dayOfExecution: Option[DayOfExecution] = None +) extends ApiModel + +object PeriodicPaymentInitiationSctInstJsonEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationSctInstWithStatusResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationSctInstWithStatusResponse.scala new file mode 100644 index 0000000000..34b968fb26 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationSctInstWithStatusResponse.scala @@ -0,0 +1,41 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class PeriodicPaymentInitiationSctInstWithStatusResponse ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + /* Unstructured remittance information */ + remittanceInformationUnstructured: Option[String] = None, + /* The first applicable day of execution starting from this date is the first payment. */ + startDate: LocalDate, + /* The last applicable day of execution If not given, it is an infinite standing order. */ + endDate: Option[LocalDate] = None, + executionRule: Option[ExecutionRule] = None, + frequency: FrequencyCode, + dayOfExecution: Option[DayOfExecution] = None, + transactionStatus: Option[TransactionStatus] = None +) extends ApiModel + +object PeriodicPaymentInitiationSctInstWithStatusResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationSctJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationSctJson.scala new file mode 100644 index 0000000000..4c5bf00022 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationSctJson.scala @@ -0,0 +1,40 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class PeriodicPaymentInitiationSctJson ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + /* Unstructured remittance information */ + remittanceInformationUnstructured: Option[String] = None, + /* The first applicable day of execution starting from this date is the first payment. */ + startDate: LocalDate, + /* The last applicable day of execution If not given, it is an infinite standing order. */ + endDate: Option[LocalDate] = None, + executionRule: Option[ExecutionRule] = None, + frequency: FrequencyCode, + dayOfExecution: Option[DayOfExecution] = None +) extends ApiModel + +object PeriodicPaymentInitiationSctJsonEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationSctWithStatusResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationSctWithStatusResponse.scala new file mode 100644 index 0000000000..3906897294 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationSctWithStatusResponse.scala @@ -0,0 +1,41 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class PeriodicPaymentInitiationSctWithStatusResponse ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + /* Unstructured remittance information */ + remittanceInformationUnstructured: Option[String] = None, + /* The first applicable day of execution starting from this date is the first payment. */ + startDate: LocalDate, + /* The last applicable day of execution If not given, it is an infinite standing order. */ + endDate: Option[LocalDate] = None, + executionRule: Option[ExecutionRule] = None, + frequency: FrequencyCode, + dayOfExecution: Option[DayOfExecution] = None, + transactionStatus: Option[TransactionStatus] = None +) extends ApiModel + +object PeriodicPaymentInitiationSctWithStatusResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationTarget2Json.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationTarget2Json.scala new file mode 100644 index 0000000000..bcf2718342 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationTarget2Json.scala @@ -0,0 +1,39 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class PeriodicPaymentInitiationTarget2Json ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + remittanceInformationUnstructured: Option[String] = None, + /* The first applicable day of execution starting from this date is the first payment. */ + startDate: LocalDate, + /* The last applicable day of execution If not given, it is an infinite standing order. */ + endDate: Option[LocalDate] = None, + executionRule: Option[ExecutionRule] = None, + frequency: FrequencyCode, + dayOfExecution: Option[DayOfExecution] = None +) extends ApiModel + +object PeriodicPaymentInitiationTarget2JsonEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationTarget2WithStatusResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationTarget2WithStatusResponse.scala new file mode 100644 index 0000000000..daf6caaa8e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationTarget2WithStatusResponse.scala @@ -0,0 +1,40 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class PeriodicPaymentInitiationTarget2WithStatusResponse ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor Name */ + creditorName: String, + creditorAddress: Option[Address] = None, + remittanceInformationUnstructured: Option[String] = None, + /* The first applicable day of execution starting from this date is the first payment. */ + startDate: LocalDate, + /* The last applicable day of execution If not given, it is an infinite standing order. */ + endDate: Option[LocalDate] = None, + executionRule: Option[ExecutionRule] = None, + frequency: FrequencyCode, + dayOfExecution: Option[DayOfExecution] = None, + transactionStatus: Option[TransactionStatus] = None +) extends ApiModel + +object PeriodicPaymentInitiationTarget2WithStatusResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationWithStatusResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationWithStatusResponse.scala new file mode 100644 index 0000000000..7d9fe199b2 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationWithStatusResponse.scala @@ -0,0 +1,43 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class PeriodicPaymentInitiationWithStatusResponse ( + endToEndIdentification: Option[String] = None, + debtorAccount: AccountReference, + instructedAmount: Amount, + creditorAccount: AccountReference, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Creditor name. */ + creditorName: String, + creditorAddress: Option[Address] = None, + /* Unstructured remittance information. */ + remittanceInformationUnstructured: Option[String] = None, + /* The first applicable day of execution starting from this date is the first payment. */ + startDate: LocalDate, + /* The last applicable day of execution. If not given, it is an infinite standing order. */ + endDate: Option[LocalDate] = None, + executionRule: Option[ExecutionRule] = None, + frequency: FrequencyCode, + dayOfExecution: Option[DayOfExecution] = None, + transactionStatus: Option[TransactionStatus] = None, + /* Messages to the TPP on operational issues. */ + tppMessage: Option[Seq[TppMessageGeneric]] = None +) extends ApiModel + +object PeriodicPaymentInitiationWithStatusResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationXmlPart2StandingorderTypeJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationXmlPart2StandingorderTypeJson.scala new file mode 100644 index 0000000000..c5031acad6 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationXmlPart2StandingorderTypeJson.scala @@ -0,0 +1,31 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class PeriodicPaymentInitiationXmlPart2StandingorderTypeJson ( + /* The first applicable day of execution starting from this date is the first payment. */ + startDate: LocalDate, + /* The last applicable day of execution. If not given, it is an infinite standing order. */ + endDate: Option[LocalDate] = None, + executionRule: Option[ExecutionRule] = None, + frequency: FrequencyCode, + dayOfExecution: Option[DayOfExecution] = None, + /* The format is following the regular expression \\d{1,2}. The array is restricted to 11 entries. The values contained in the array entries shall all be different and the maximum value of one entry is 12. This attribute is contained if and only if the frequency equals \"MonthlyVariable\". Example: An execution on January, April and October each year is addressed by [\"1\", \"4\", \"10\"]. */ + monthsOfExecution: Option[PeriodicPaymentInitiationXmlPart2StandingorderTypeJsonEnums.type] = None +) extends ApiModel + +object PeriodicPaymentInitiationXmlPart2StandingorderTypeJsonEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PsuData.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PsuData.scala new file mode 100644 index 0000000000..018763be81 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PsuData.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PsuData ( + /* Password. */ + password: String, + /* Encrypted password. */ + encryptedPassword: Option[String] = None, + /* Additional password in plaintext. */ + additionalPassword: Option[String] = None, + /* Additional encrypted password. */ + additionalEncryptedPassword: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PurposeCode.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PurposeCode.scala new file mode 100644 index 0000000000..0be7f2782c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PurposeCode.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class PurposeCode ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadAccountBalanceResponse200.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadAccountBalanceResponse200.scala new file mode 100644 index 0000000000..915785dbe3 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadAccountBalanceResponse200.scala @@ -0,0 +1,21 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class ReadAccountBalanceResponse200 ( + account: Option[AccountReference] = None, + /* A list of balances regarding this account, e.g. the current balance, the last booked balance. The list might be restricted to the current balance. */ + balances: Seq[Balance] +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadAccountDetails200Response.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadAccountDetails200Response.scala new file mode 100644 index 0000000000..3a943822c4 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadAccountDetails200Response.scala @@ -0,0 +1,19 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class ReadAccountDetails200Response ( + account: AccountDetails +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadCardAccountBalanceResponse200.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadCardAccountBalanceResponse200.scala new file mode 100644 index 0000000000..5445cb45bb --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadCardAccountBalanceResponse200.scala @@ -0,0 +1,23 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class ReadCardAccountBalanceResponse200 ( + cardAccount: Option[AccountReference] = None, + /* If true, the amounts of debits on the reports are quoted positive with the related consequence for balances. If false, the amount of debits on the reports are quoted negative. */ + debitAccounting: Option[Boolean] = None, + /* A list of balances regarding this account, e.g. the current balance, the last booked balance. The list might be restricted to the current balance. */ + balances: Seq[Balance] +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadCardAccountDetails200Response.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadCardAccountDetails200Response.scala new file mode 100644 index 0000000000..6841104fbb --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadCardAccountDetails200Response.scala @@ -0,0 +1,19 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class ReadCardAccountDetails200Response ( + cardAccount: CardAccountDetails +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/RemittanceInformationStructured.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/RemittanceInformationStructured.scala new file mode 100644 index 0000000000..0d84d89b2d --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/RemittanceInformationStructured.scala @@ -0,0 +1,21 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class RemittanceInformationStructured ( + reference: String, + referenceType: Option[String] = None, + referenceIssuer: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReportExchangeRate.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReportExchangeRate.scala new file mode 100644 index 0000000000..5d747ae03c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReportExchangeRate.scala @@ -0,0 +1,28 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class ReportExchangeRate ( + /* ISO 4217 Alpha 3 currency code. */ + sourceCurrency: String, + exchangeRate: String, + /* ISO 4217 Alpha 3 currency code. */ + unitCurrency: String, + /* ISO 4217 Alpha 3 currency code. */ + targetCurrency: String, + quotationDate: LocalDate, + contractIdentification: Option[String] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ScaStatus.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ScaStatus.scala new file mode 100644 index 0000000000..b1e8a0e6ad --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ScaStatus.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class ScaStatus ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ScaStatusAuthorisationConfirmation.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ScaStatusAuthorisationConfirmation.scala new file mode 100644 index 0000000000..a1b9bcece5 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ScaStatusAuthorisationConfirmation.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class ScaStatusAuthorisationConfirmation ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ScaStatusResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ScaStatusResponse.scala new file mode 100644 index 0000000000..db13a76d36 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ScaStatusResponse.scala @@ -0,0 +1,31 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class ScaStatusResponse ( + scaStatus: String, + /* Text to be displayed to the PSU. */ + psuMessage: Option[String] = None, + /* Name of the PSU. In case of a corporate account, this might be the person acting on behalf of the corporate. */ + psuName: Option[String] = None, + /* Additional Service: Trusted Beneficiaries Within this data element, the ASPSP might optionally communicate towards the TPP whether the creditor was part of the related trusted beneficiary list. This attribute is only contained in case of a final scaStatus. */ + trustedBeneficiaryFlag: Option[Boolean] = None, + _links: Option[LinksAll] = None, + /* Messages to the TPP on operational issues. */ + tppMessage: Option[Seq[TppMessageGeneric]] = None +) extends ApiModel + +object ScaStatusResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SelectPsuAuthenticationMethod.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SelectPsuAuthenticationMethod.scala new file mode 100644 index 0000000000..ce5a9e9f76 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SelectPsuAuthenticationMethod.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class SelectPsuAuthenticationMethod ( + /* An identification provided by the ASPSP for the later identification of the authentication method selection. */ + authenticationMethodId: String +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SelectPsuAuthenticationMethodResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SelectPsuAuthenticationMethodResponse.scala new file mode 100644 index 0000000000..12b444ee5c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SelectPsuAuthenticationMethodResponse.scala @@ -0,0 +1,31 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class SelectPsuAuthenticationMethodResponse ( + transactionFees: Option[Amount] = None, + currencyConversionFees: Option[Amount] = None, + estimatedTotalAmount: Option[Amount] = None, + estimatedInterbankSettlementAmount: Option[Amount] = None, + chosenScaMethod: Option[AuthenticationObject] = None, + challengeData: Option[ChallengeData] = None, + _links: Option[LinksSelectPsuAuthenticationMethod] = None, + scaStatus: ScaStatus, + /* Text to be displayed to the PSU. */ + psuMessage: Option[String] = None +) extends ApiModel + +object SelectPsuAuthenticationMethodResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ServiceLevelCode.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ServiceLevelCode.scala new file mode 100644 index 0000000000..b678ff3b20 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ServiceLevelCode.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class ServiceLevelCode ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasket.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasket.scala new file mode 100644 index 0000000000..90ff73edd8 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasket.scala @@ -0,0 +1,22 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class SigningBasket ( + /* A list of paymentIds. */ + paymentIds: Option[Seq[String]] = None, + /* A list of consentIds. */ + consentIds: Option[Seq[String]] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasketResponse200.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasketResponse200.scala new file mode 100644 index 0000000000..aa2947e7a3 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasketResponse200.scala @@ -0,0 +1,27 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class SigningBasketResponse200 ( + /* A list of paymentIds. */ + payments: Option[Seq[String]] = None, + /* A list of consentIds. */ + consents: Option[Seq[String]] = None, + transactionStatus: TransactionStatusSBS, + _links: Option[LinksSigningBasket] = None +) extends ApiModel + +object SigningBasketResponse200Enums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasketResponse201.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasketResponse201.scala new file mode 100644 index 0000000000..2805b317b8 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasketResponse201.scala @@ -0,0 +1,32 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class SigningBasketResponse201 ( + transactionStatus: TransactionStatusSBS, + /* Resource identification of the generated signing basket resource. */ + basketId: String, + /* This data element might be contained, if SCA is required and if the PSU has a choice between different authentication methods. Depending on the risk management of the ASPSP this choice might be offered before or after the PSU has been identified with the first relevant factor, or if an access token is transported. If this data element is contained, then there is also a hyperlink of type 'startAuthorisationWithAuthenticationMethodSelection' contained in the response body. These methods shall be presented towards the PSU for selection by the TPP. */ + scaMethods: Option[Seq[AuthenticationObject]] = None, + chosenScaMethod: Option[AuthenticationObject] = None, + challengeData: Option[ChallengeData] = None, + links: LinksSigningBasket, + /* Text to be displayed to the PSU. */ + psuMessage: Option[String] = None, + tppMessages: Option[Seq[TppMessage2XX]] = None +) extends ApiModel + +object SigningBasketResponse201Enums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasketStatusResponse200.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasketStatusResponse200.scala new file mode 100644 index 0000000000..c10bd8fd3f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasketStatusResponse200.scala @@ -0,0 +1,22 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class SigningBasketStatusResponse200 ( + transactionStatus: TransactionStatusSBS +) extends ApiModel + +object SigningBasketStatusResponse200Enums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/StandingOrderDetails.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/StandingOrderDetails.scala new file mode 100644 index 0000000000..ea2f2c3729 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/StandingOrderDetails.scala @@ -0,0 +1,37 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class StandingOrderDetails ( + /* The first applicable day of execution starting from this date is the first payment. */ + startDate: LocalDate, + frequency: FrequencyCode, + /* The last applicable day of execution. If not given, it is an infinite standing order. */ + endDate: Option[LocalDate] = None, + executionRule: Option[ExecutionRule] = None, + /* This element is only used in case of frequency equals \"Monthly\". If this element equals false it has no effect. If this element equals true, then the execution rule is overruled if the day of execution would fall into a different month using the execution rule. Example: executionRule equals \"preceding\", dayOfExecution equals \"02\" and the second of a month is a Sunday. In this case, the transaction date would be on the last day of the month before. This would be overruled if withinAMonthFlag equals true and the payment is processed on Monday the third of the Month. Remark: This attribute is rarely supported in the market. */ + withinAMonthFlag: Option[Boolean] = None, + /* The format is following the regular expression \\d{1,2}. The array is restricted to 11 entries. The values contained in the array entries shall all be different and the maximum value of one entry is 12. This attribute is contained if and only if the frequency equals \"MonthlyVariable\". Example: An execution on January, April and October each year is addressed by [\"1\", \"4\", \"10\"]. */ + monthsOfExecution: Option[StandingOrderDetailsEnums.type] = None, + /* This is multiplying the given frequency resulting the exact frequency, e.g. Frequency=weekly and multiplicator=3 means every 3 weeks. Remark: This attribute is rarely supported in the market. */ + multiplicator: Option[Int] = None, + dayOfExecution: Option[DayOfExecution] = None, + limitAmount: Option[Amount] = None +) extends ApiModel + +object StandingOrderDetailsEnums { + + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/StartPaymentAuthorisationRequest.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/StartPaymentAuthorisationRequest.scala new file mode 100644 index 0000000000..6f14367996 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/StartPaymentAuthorisationRequest.scala @@ -0,0 +1,23 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class StartPaymentAuthorisationRequest ( + psuData: PsuData, + /* An identification provided by the ASPSP for the later identification of the authentication method selection. */ + authenticationMethodId: String, + /* SCA authentication data, depending on the chosen authentication method. If the data is binary, then it is base64 encoded. */ + scaAuthenticationData: String +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/StartScaprocessResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/StartScaprocessResponse.scala new file mode 100644 index 0000000000..e4418d30a1 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/StartScaprocessResponse.scala @@ -0,0 +1,31 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class StartScaprocessResponse ( + scaStatus: ScaStatus, + /* Resource identification of the related SCA. */ + authorisationId: String, + /* This data element might be contained, if SCA is required and if the PSU has a choice between different authentication methods. Depending on the risk management of the ASPSP this choice might be offered before or after the PSU has been identified with the first relevant factor, or if an access token is transported. If this data element is contained, then there is also a hyperlink of type 'startAuthorisationWithAuthenticationMethodSelection' contained in the response body. These methods shall be presented towards the PSU for selection by the TPP. */ + scaMethods: Option[Seq[AuthenticationObject]] = None, + chosenScaMethod: Option[AuthenticationObject] = None, + challengeData: Option[ChallengeData] = None, + links: LinksStartScaProcess, + /* Text to be displayed to the PSU. */ + psuMessage: Option[String] = None +) extends ApiModel + +object StartScaprocessResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage201PaymentInitiation.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage201PaymentInitiation.scala new file mode 100644 index 0000000000..4e77cb0830 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage201PaymentInitiation.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage201PaymentInitiation ( + category: TppMessageCategory, + code: MessageCode201PaymentInitiation, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage201PaymentInitiationEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage2XX.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage2XX.scala new file mode 100644 index 0000000000..4c170705db --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage2XX.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage2XX ( + category: TppMessageCategory, + code: MessageCode2XX, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage2XXEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400AIS.scala new file mode 100644 index 0000000000..358b1289c7 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400AIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage400AIS ( + category: TppMessageCategory, + code: MessageCode400AIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage400AISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400PIIS.scala new file mode 100644 index 0000000000..caafa99de6 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400PIIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage400PIIS ( + category: TppMessageCategory, + code: MessageCode400PIIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage400PIISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400PIS.scala new file mode 100644 index 0000000000..8cc6612852 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400PIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage400PIS ( + category: TppMessageCategory, + code: MessageCode400PIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage400PISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400SB.scala new file mode 100644 index 0000000000..98cce23dde --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400SB.scala @@ -0,0 +1,26 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage400SB ( + category: TppMessageCategory, + code: MessageCode400SB, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage400SBEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400SBS.scala new file mode 100644 index 0000000000..0b0e8687d4 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400SBS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage400SBS ( + category: TppMessageCategory, + code: MessageCode400SBS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage400SBSEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401AIS.scala new file mode 100644 index 0000000000..4bc43551c3 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401AIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage401AIS ( + category: TppMessageCategory, + code: MessageCode401AIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage401AISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401PIIS.scala new file mode 100644 index 0000000000..3389d0aacd --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401PIIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage401PIIS ( + category: TppMessageCategory, + code: MessageCode401PIIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage401PIISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401PIS.scala new file mode 100644 index 0000000000..aa0c3a6c34 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401PIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage401PIS ( + category: TppMessageCategory, + code: MessageCode401PIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage401PISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401SB.scala new file mode 100644 index 0000000000..9500b5e4be --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401SB.scala @@ -0,0 +1,26 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage401SB ( + category: TppMessageCategory, + code: MessageCode401SB, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage401SBEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401SBS.scala new file mode 100644 index 0000000000..a754387e10 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401SBS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage401SBS ( + category: TppMessageCategory, + code: MessageCode401SBS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage401SBSEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403AIS.scala new file mode 100644 index 0000000000..67efc51249 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403AIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage403AIS ( + category: TppMessageCategory, + code: MessageCode403AIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage403AISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403PIIS.scala new file mode 100644 index 0000000000..e0dd761035 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403PIIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage403PIIS ( + category: TppMessageCategory, + code: MessageCode403PIIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage403PIISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403PIS.scala new file mode 100644 index 0000000000..c10ed97bc5 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403PIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage403PIS ( + category: TppMessageCategory, + code: MessageCode403PIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage403PISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403SB.scala new file mode 100644 index 0000000000..bec10b25fc --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403SB.scala @@ -0,0 +1,26 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage403SB ( + category: TppMessageCategory, + code: MessageCode403SB, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage403SBEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403SBS.scala new file mode 100644 index 0000000000..c47c1b2b39 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403SBS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage403SBS ( + category: TppMessageCategory, + code: MessageCode403SBS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage403SBSEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404AIS.scala new file mode 100644 index 0000000000..2b32d9e817 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404AIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage404AIS ( + category: TppMessageCategory, + code: MessageCode404AIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage404AISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404PIIS.scala new file mode 100644 index 0000000000..8ec506a49a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404PIIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage404PIIS ( + category: TppMessageCategory, + code: MessageCode404PIIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage404PIISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404PIS.scala new file mode 100644 index 0000000000..254378bad1 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404PIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage404PIS ( + category: TppMessageCategory, + code: MessageCode404PIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage404PISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404SB.scala new file mode 100644 index 0000000000..56b8f8a6a2 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404SB.scala @@ -0,0 +1,26 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage404SB ( + category: TppMessageCategory, + code: MessageCode404SB, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage404SBEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404SBS.scala new file mode 100644 index 0000000000..fdd2c59040 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404SBS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage404SBS ( + category: TppMessageCategory, + code: MessageCode404SBS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage404SBSEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405AIS.scala new file mode 100644 index 0000000000..ceef329a84 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405AIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage405AIS ( + category: TppMessageCategory, + code: MessageCode405AIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage405AISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405PIIS.scala new file mode 100644 index 0000000000..8d23b84c11 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405PIIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage405PIIS ( + category: TppMessageCategory, + code: MessageCode405PIIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage405PIISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405PIS.scala new file mode 100644 index 0000000000..a21acf4d63 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405PIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage405PIS ( + category: TppMessageCategory, + code: MessageCode405PIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage405PISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405PISCANC.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405PISCANC.scala new file mode 100644 index 0000000000..395920326f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405PISCANC.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage405PISCANC ( + category: TppMessageCategory, + code: MessageCode405PISCANC, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage405PISCANCEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405SB.scala new file mode 100644 index 0000000000..ae1aef35c0 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405SB.scala @@ -0,0 +1,26 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage405SB ( + category: TppMessageCategory, + code: MessageCode405SB, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage405SBEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405SBS.scala new file mode 100644 index 0000000000..ab5b37dea3 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405SBS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage405SBS ( + category: TppMessageCategory, + code: MessageCode405SBS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage405SBSEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage406AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage406AIS.scala new file mode 100644 index 0000000000..01e7a65977 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage406AIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage406AIS ( + category: TppMessageCategory, + code: MessageCode406AIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage406AISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409AIS.scala new file mode 100644 index 0000000000..87d9115a04 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409AIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage409AIS ( + category: TppMessageCategory, + code: MessageCode409AIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage409AISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409PIIS.scala new file mode 100644 index 0000000000..fd1bba3273 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409PIIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage409PIIS ( + category: TppMessageCategory, + code: MessageCode409PIIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage409PIISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409PIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409PIS.scala new file mode 100644 index 0000000000..b323f9132f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409PIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage409PIS ( + category: TppMessageCategory, + code: MessageCode409PIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage409PISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409SB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409SB.scala new file mode 100644 index 0000000000..70eb133aeb --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409SB.scala @@ -0,0 +1,26 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage409SB ( + category: TppMessageCategory, + code: MessageCode409SB, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage409SBEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409SBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409SBS.scala new file mode 100644 index 0000000000..6668c54084 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409SBS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage409SBS ( + category: TppMessageCategory, + code: MessageCode409SBS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage409SBSEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage429AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage429AIS.scala new file mode 100644 index 0000000000..11f22521a6 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage429AIS.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessage429AIS ( + category: TppMessageCategory, + code: MessageCode429AIS, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessage429AISEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessageCategory.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessageCategory.scala new file mode 100644 index 0000000000..3f7f93328c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessageCategory.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessageCategory ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessageGeneric.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessageGeneric.scala new file mode 100644 index 0000000000..e7430db398 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessageGeneric.scala @@ -0,0 +1,27 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessageGeneric ( + category: TppMessageCategory, + /* Code of the TPP message category. */ + code: String, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessageGenericEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessageInitiationStatusResponse200.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessageInitiationStatusResponse200.scala new file mode 100644 index 0000000000..744a03ca01 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessageInitiationStatusResponse200.scala @@ -0,0 +1,26 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TppMessageInitiationStatusResponse200 ( + category: TppMessageCategory, + code: MessageCode200InitiationStatus, + path: Option[String] = None, + /* Additional explaining text to the TPP. */ + text: Option[String] = None +) extends ApiModel + +object TppMessageInitiationStatusResponse200Enums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionAuthorisation.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionAuthorisation.scala new file mode 100644 index 0000000000..c03886214c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionAuthorisation.scala @@ -0,0 +1,20 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TransactionAuthorisation ( + /* SCA authentication data, depending on the chosen authentication method. If the data is binary, then it is base64 encoded. */ + scaAuthenticationData: String +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionDetails.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionDetails.scala new file mode 100644 index 0000000000..a3afc1793b --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionDetails.scala @@ -0,0 +1,60 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class TransactionDetails ( + /* the Transaction Id can be used as access-ID in the API, where more details on an transaction is offered. If this data attribute is provided this shows that the AIS can get access on more details about this transaction using the GET Transaction Details Request */ + transactionId: Option[String] = None, + /* Is the identification of the transaction as used e.g. for reference for deltafunction on application level. The same identification as for example used within camt.05x messages. */ + entryReference: Option[String] = None, + /* Unique end to end identity. */ + endToEndId: Option[String] = None, + /* Identification of Mandates, e.g. a SEPA Mandate ID. */ + mandateId: Option[String] = None, + /* Identification of a Cheque. */ + checkId: Option[String] = None, + /* Identification of Creditors, e.g. a SEPA Creditor ID. */ + creditorId: Option[String] = None, + /* The Date when an entry is posted to an account on the ASPSPs books. */ + bookingDate: Option[LocalDate] = None, + /* The Date at which assets become available to the account owner in case of a credit. */ + valueDate: Option[LocalDate] = None, + transactionAmount: Amount, + /* Array of exchange rates */ + exchangeRate: Option[Seq[ExchangeRate]] = None, + /* Creditor Name */ + creditorName: Option[String] = None, + creditorAccount: Option[AccountReference] = None, + /* Ultimate Creditor */ + ultimateCreditor: Option[String] = None, + /* Debtor Name */ + debtorName: Option[String] = None, + debtorAccount: Option[AccountReference] = None, + /* Ultimate Debtor */ + ultimateDebtor: Option[String] = None, + remittanceInformationUnstructured: Option[String] = None, + /* Reference as contained in the structured remittance reference structure (without the surrounding XML structure). Different from other places the content is containt in plain form not in form of a structered field. */ + remittanceInformationStructured: Option[String] = None, + purposeCode: Option[PurposeCode] = None, + /* Bank transaction code as used by the ASPSP and using the sub elements of this structured code defined by ISO 20022. This code type is concatenating the three ISO20022 Codes * Domain Code, * Family Code, and * SubFamiliy Code by hyphens, resulting in �DomainCode�-�FamilyCode�-�SubFamilyCode�. */ + bankTransactionCode: Option[String] = None, + /* Proprietary bank transaction code as used within a community or within an ASPSP e.g. for MT94x based transaction reports. */ + proprietaryBankTransactionCode: Option[String] = None, + _links: Option[LinksTransactionDetails] = None +) extends ApiModel + +object TransactionDetailsEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionDetailsBody.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionDetailsBody.scala new file mode 100644 index 0000000000..88def80f57 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionDetailsBody.scala @@ -0,0 +1,19 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TransactionDetailsBody ( + transactionDetails: Transactions +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionStatus.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionStatus.scala new file mode 100644 index 0000000000..2b5291b68c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionStatus.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TransactionStatus ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionStatusSB.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionStatusSB.scala new file mode 100644 index 0000000000..1d9f2d8757 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionStatusSB.scala @@ -0,0 +1,18 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TransactionStatusSB ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionStatusSBS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionStatusSBS.scala new file mode 100644 index 0000000000..00ede7944e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionStatusSBS.scala @@ -0,0 +1,18 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TransactionStatusSBS ( +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Transactions.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Transactions.scala new file mode 100644 index 0000000000..3bc5448e16 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Transactions.scala @@ -0,0 +1,79 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +import java.time.LocalDate + + +case class Transactions ( + /* This identification is given by the attribute transactionId of the corresponding entry of a transaction list. */ + transactionId: Option[String] = None, + /* Is the identification of the transaction as used e.g. for reference for deltafunction on application level. The same identification as for example used within camt.05x messages. */ + entryReference: Option[String] = None, + /* Unique end to end identity. */ + endToEndId: Option[String] = None, + /* If this indicator equals true, then the related entry is a batch entry. */ + batchIndicator: Option[Boolean] = None, + /* Shall be used if and only if the batchIndicator is contained and equals true. */ + batchNumberOfTransactions: Option[Int] = None, + /* Identification of Mandates, e.g. a SEPA Mandate ID. */ + mandateId: Option[String] = None, + /* Identification of a Cheque. */ + checkId: Option[String] = None, + /* Identification of Creditors, e.g. a SEPA Creditor ID. */ + creditorId: Option[String] = None, + /* The date when an entry is posted to an account on the ASPSPs books. */ + bookingDate: Option[LocalDate] = None, + /* The Date at which assets become available to the account owner in case of a credit, or cease to be available to the account owner in case of a debit entry. **Usage:** If entry status is pending and value date is present, then the value date refers to an expected/requested value date. */ + valueDate: Option[LocalDate] = None, + transactionAmount: Amount, + /* Array of exchange rates. */ + currencyExchange: Option[Seq[ReportExchangeRate]] = None, + /* Creditor name. */ + creditorName: Option[String] = None, + creditorAccount: Option[AccountReference] = None, + /* BICFI */ + creditorAgent: Option[String] = None, + /* Ultimate creditor. */ + ultimateCreditor: Option[String] = None, + /* Debtor name. */ + debtorName: Option[String] = None, + debtorAccount: Option[AccountReference] = None, + /* BICFI */ + debtorAgent: Option[String] = None, + /* Ultimate debtor. */ + ultimateDebtor: Option[String] = None, + /* Unstructured remittance information. */ + remittanceInformationUnstructured: Option[String] = None, + /* Array of unstructured remittance information. */ + remittanceInformationUnstructuredArray: Option[Seq[String]] = None, + /* Structured remittance information Max */ + remittanceInformationStructured: Option[String] = None, + /* Array of structured remittance information. */ + remittanceInformationStructuredArray: Option[Seq[RemittanceInformationStructured]] = None, + /* Might be used by the ASPSP to transport details about transactions within a batch. */ + entryDetails: Option[Seq[EntryDetailsElement]] = None, + /* Might be used by the ASPSP to transport additional transaction related information to the PSU */ + additionalInformation: Option[String] = None, + additionalInformationStructured: Option[AdditionalInformationStructured] = None, + purposeCode: Option[PurposeCode] = None, + /* Bank transaction code as used by the ASPSP and using the sub elements of this structured code defined by ISO 20022. This code type is concatenating the three ISO20022 Codes * Domain Code, * Family Code, and * SubFamily Code by hyphens, resulting in 'DomainCode'-'FamilyCode'-'SubFamilyCode'. For standing order reports the following codes are applicable: * \"PMNT-ICDT-STDO\" for credit transfers, * \"PMNT-IRCT-STDO\" for instant credit transfers * \"PMNT-ICDT-XBST\" for cross-border credit transfers * \"PMNT-IRCT-XBST\" for cross-border real time credit transfers and * \"PMNT-MCOP-OTHR\" for specific standing orders which have a dynamical amount to move left funds e.g. on month end to a saving account */ + bankTransactionCode: Option[String] = None, + /* Proprietary bank transaction code as used within a community or within an ASPSP e.g. for MT94x based transaction reports. */ + proprietaryBankTransactionCode: Option[String] = None, + balanceAfterTransaction: Option[Balance] = None, + _links: Option[LinksTransactionDetails] = None +) extends ApiModel + +object TransactionsEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionsResponse200Json.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionsResponse200Json.scala new file mode 100644 index 0000000000..108fc0e97c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionsResponse200Json.scala @@ -0,0 +1,23 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class TransactionsResponse200Json ( + account: Option[AccountReference] = None, + transactions: Option[AccountReport] = None, + /* A list of balances regarding this account, e.g. the current balance, the last booked balance. The list might be restricted to the current balance. */ + balances: Option[Seq[Balance]] = None, + _links: Option[LinksDownload] = None +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePaymentPsuData200Response.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePaymentPsuData200Response.scala new file mode 100644 index 0000000000..2103010738 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePaymentPsuData200Response.scala @@ -0,0 +1,41 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class UpdatePaymentPsuData200Response ( + transactionFees: Option[Amount] = None, + currencyConversionFees: Option[Amount] = None, + estimatedTotalAmount: Option[Amount] = None, + estimatedInterbankSettlementAmount: Option[Amount] = None, + /* This data element might be contained, if SCA is required and if the PSU has a choice between different authentication methods. Depending on the risk management of the ASPSP this choice might be offered before or after the PSU has been identified with the first relevant factor, or if an access token is transported. If this data element is contained, then there is also a hyperlink of type 'startAuthorisationWithAuthenticationMethodSelection' contained in the response body. These methods shall be presented towards the PSU for selection by the TPP. */ + scaMethods: Option[Seq[AuthenticationObject]] = None, + links: LinksAuthorisationConfirmation, + scaStatus: ScaStatusAuthorisationConfirmation, + /* Text to be displayed to the PSU. */ + psuMessage: Option[String] = None, + chosenScaMethod: Option[AuthenticationObject] = None, + challengeData: Option[ChallengeData] = None, + /* Resource identification of the related SCA. */ + authorisationId: Option[String] = None, + /* Name of the PSU. In case of a corporate account, this might be the person acting on behalf of the corporate. */ + psuName: Option[String] = None, + /* Additional Service: Trusted Beneficiaries Within this data element, the ASPSP might optionally communicate towards the TPP whether the creditor was part of the related trusted beneficiary list. This attribute is only contained in case of a final scaStatus. */ + trustedBeneficiaryFlag: Option[Boolean] = None, + /* Messages to the TPP on operational issues. */ + tppMessage: Option[Seq[TppMessageGeneric]] = None +) extends ApiModel + +object UpdatePaymentPsuData200ResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePaymentPsuDataRequest.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePaymentPsuDataRequest.scala new file mode 100644 index 0000000000..00fdf15447 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePaymentPsuDataRequest.scala @@ -0,0 +1,25 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class UpdatePaymentPsuDataRequest ( + psuData: PsuData, + /* An identification provided by the ASPSP for the later identification of the authentication method selection. */ + authenticationMethodId: String, + /* SCA authentication data, depending on the chosen authentication method. If the data is binary, then it is base64 encoded. */ + scaAuthenticationData: String, + /* Confirmation Code as retrieved by the TPP from the redirect based SCA process. */ + confirmationCode: String +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuAuthentication.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuAuthentication.scala new file mode 100644 index 0000000000..f83f3db269 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuAuthentication.scala @@ -0,0 +1,19 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class UpdatePsuAuthentication ( + psuData: PsuData +) extends ApiModel + diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuAuthenticationResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuAuthenticationResponse.scala new file mode 100644 index 0000000000..9a20748ce7 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuAuthenticationResponse.scala @@ -0,0 +1,35 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class UpdatePsuAuthenticationResponse ( + transactionFees: Option[Amount] = None, + currencyConversionFees: Option[Amount] = None, + estimatedTotalAmount: Option[Amount] = None, + estimatedInterbankSettlementAmount: Option[Amount] = None, + chosenScaMethod: Option[AuthenticationObject] = None, + challengeData: Option[ChallengeData] = None, + /* This data element might be contained, if SCA is required and if the PSU has a choice between different authentication methods. Depending on the risk management of the ASPSP this choice might be offered before or after the PSU has been identified with the first relevant factor, or if an access token is transported. If this data element is contained, then there is also a hyperlink of type 'startAuthorisationWithAuthenticationMethodSelection' contained in the response body. These methods shall be presented towards the PSU for selection by the TPP. */ + scaMethods: Option[Seq[AuthenticationObject]] = None, + _links: Option[LinksUpdatePsuAuthentication] = None, + scaStatus: String, + /* Text to be displayed to the PSU. */ + psuMessage: Option[String] = None, + /* Resource identification of the related SCA. */ + authorisationId: Option[String] = None +) extends ApiModel + +object UpdatePsuAuthenticationResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuIdenticationResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuIdenticationResponse.scala new file mode 100644 index 0000000000..c4dc61437b --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuIdenticationResponse.scala @@ -0,0 +1,25 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class UpdatePsuIdenticationResponse ( + links: LinksUpdatePsuIdentification, + scaStatus: ScaStatus, + /* Text to be displayed to the PSU */ + psuMessage: Option[String] = None +) extends ApiModel + +object UpdatePsuIdenticationResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuIdentificationResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuIdentificationResponse.scala new file mode 100644 index 0000000000..6f2aef1761 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuIdentificationResponse.scala @@ -0,0 +1,31 @@ +/** + * NextGenPSD2 XS2A Framework + * # Summary The **NextGenPSD2** *Framework Version 1.3.12* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 complient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3.12_2022-07-01 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + + + +case class UpdatePsuIdentificationResponse ( + transactionFees: Option[Amount] = None, + currencyConversionFees: Option[Amount] = None, + estimatedTotalAmount: Option[Amount] = None, + estimatedInterbankSettlementAmount: Option[Amount] = None, + /* This data element might be contained, if SCA is required and if the PSU has a choice between different authentication methods. Depending on the risk management of the ASPSP this choice might be offered before or after the PSU has been identified with the first relevant factor, or if an access token is transported. If this data element is contained, then there is also a hyperlink of type 'startAuthorisationWithAuthenticationMethodSelection' contained in the response body. These methods shall be presented towards the PSU for selection by the TPP. */ + scaMethods: Option[Seq[AuthenticationObject]] = None, + links: LinksUpdatePsuIdentification, + scaStatus: ScaStatus, + /* Text to be displayed to the PSU. */ + psuMessage: Option[String] = None +) extends ApiModel + +object UpdatePsuIdentificationResponseEnums { + +} diff --git a/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/requests.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/requests.scala new file mode 100644 index 0000000000..53dcac8863 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/requests.scala @@ -0,0 +1,17 @@ +/** + * BG PSD2 API + * # Summary The **NextGenPSD2** *Framework Version 1.3* offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] \"If in is \"header\" and the name field is \"Accept\", \"Content-Type\" or \"Authorization\", the parameter definition SHALL be ignored.\" The element \"Accept\" will not be defined in this file at any place. The elements \"Content-Type\" and \"Authorization\" are implicitly defined by the OpenApi tags \"content\" and \"security\". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines.** Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space + * + * The version of the OpenAPI document: 1.3 Dec 20th 2018 + * Contact: info@berlin-group.org + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ +package code.api.berlin.group.v1_3.model + +/** + * This trait needs to be added to any model defined by the api. + */ +trait ApiModel \ No newline at end of file diff --git a/obp-api/src/main/scala/code/api/v5_1_0/APIMethods510.scala b/obp-api/src/main/scala/code/api/v5_1_0/APIMethods510.scala index 06677998b7..09cd23b1fd 100644 --- a/obp-api/src/main/scala/code/api/v5_1_0/APIMethods510.scala +++ b/obp-api/src/main/scala/code/api/v5_1_0/APIMethods510.scala @@ -43,7 +43,7 @@ import com.openbankproject.commons.model._ import com.openbankproject.commons.util.{ApiVersion, ScannedApiVersion} import net.liftweb.common.Full import net.liftweb.http.rest.RestHelper -import net.liftweb.json.{compactRender, parse} +import net.liftweb.json.{compactRender, parse, prettyRender} import net.liftweb.mapper.By import net.liftweb.util.Helpers import net.liftweb.util.Helpers.tryo @@ -212,8 +212,8 @@ trait APIMethods510 { json.extract[RegulatedEntityPostJsonV510] } failMsg = s"$InvalidJsonFormat The `services` field is not valid JSON" - _ <- NewStyle.function.tryons(failMsg, 400, cc.callContext) { - parse(postedData.services) + servicesString <- NewStyle.function.tryons(failMsg, 400, cc.callContext) { + prettyRender(postedData.services) } (entity, callContext) <- createRegulatedEntityNewStyle( certificateAuthorityCaOwnerId = Some(postedData.certificate_authority_ca_owner_id), @@ -226,7 +226,7 @@ trait APIMethods510 { entityPostCode = Some(postedData.entity_post_code), entityCountry = Some(postedData.entity_country), entityWebSite = Some(postedData.entity_web_site), - services = Some(postedData.services), + services = Some(servicesString), cc.callContext ) } yield { diff --git a/obp-api/src/main/scala/code/api/v5_1_0/JSONFactory5.1.0.scala b/obp-api/src/main/scala/code/api/v5_1_0/JSONFactory5.1.0.scala index 73dff2c059..5941752a9b 100644 --- a/obp-api/src/main/scala/code/api/v5_1_0/JSONFactory5.1.0.scala +++ b/obp-api/src/main/scala/code/api/v5_1_0/JSONFactory5.1.0.scala @@ -93,7 +93,7 @@ case class RegulatedEntityPostJsonV510( entity_post_code: String, entity_country: String, entity_web_site: String, - services: String + services: JValue ) case class RegulatedEntitiesJsonV510(entities: List[RegulatedEntityJsonV510]) @@ -279,7 +279,7 @@ case class MetricJsonV510( duration: Long, source_ip: String, target_ip: String, - response_body: String + response_body: JValue ) case class MetricsJsonV510(metrics: List[MetricJsonV510]) @@ -627,7 +627,7 @@ object JSONFactory510 extends CustomJsonFormats { duration = metric.getDuration(), source_ip = metric.getSourceIp(), target_ip = metric.getTargetIp(), - response_body = metric.getResponseBody() + response_body = parse(metric.getResponseBody()) ) } diff --git a/obp-api/src/main/scala/code/snippet/PaymentOTP.scala b/obp-api/src/main/scala/code/snippet/PaymentOTP.scala index 993e20d429..23c01fbbf9 100644 --- a/obp-api/src/main/scala/code/snippet/PaymentOTP.scala +++ b/obp-api/src/main/scala/code/snippet/PaymentOTP.scala @@ -27,7 +27,7 @@ TESOBE (http://www.tesobe.com/) package code.snippet import code.api.berlin.group.v1_3.JSONFactory_BERLIN_GROUP_1_3.StartPaymentAuthorisationJson -import code.api.builder.PaymentInitiationServicePISApi.APIMethods_PaymentInitiationServicePISApi.{startPaymentAuthorisation, updatePaymentPsuData} +import code.api.builder.PaymentInitiationServicePISApi.APIMethods_PaymentInitiationServicePISApi.{startPaymentAuthorisationUpdatePsuAuthentication, updatePaymentPsuDataTransactionAuthorisation} import code.api.util.APIUtil._ import code.api.util.ErrorMessages.FutureTimeoutException import code.api.util.{CallContext, CustomJsonFormats} @@ -145,7 +145,7 @@ class PaymentOTP extends MdcLoggable with RestHelper with APIMethods400 { val pathOfEndpoint = requestParam.map(_.openOr("")) :+ "authorisations" - val authorisationsResult = callEndpoint(startPaymentAuthorisation, pathOfEndpoint, PostRequest) + val authorisationsResult = callEndpoint(startPaymentAuthorisationUpdatePsuAuthentication, pathOfEndpoint, PostRequest) authorisationsResult match { case left @Left((_, _)) => left @@ -154,7 +154,7 @@ class PaymentOTP extends MdcLoggable with RestHelper with APIMethods400 { val authorisationId = json.parse(v).extract[StartPaymentAuthorisationJson].authorisationId val requestBody = s"""{"scaAuthenticationData":"${otpVar.get}"}""" - callEndpoint(updatePaymentPsuData, pathOfEndpoint :+ authorisationId, PutRequest, requestBody) + callEndpoint(updatePaymentPsuDataTransactionAuthorisation, pathOfEndpoint :+ authorisationId, PutRequest, requestBody) } } diff --git a/obp-api/src/test/scala/code/api/berlin/group/v1_3/AccountInformationServiceAISApiTest.scala b/obp-api/src/test/scala/code/api/berlin/group/v1_3/AccountInformationServiceAISApiTest.scala index 5ccb9afeba..807d68467c 100644 --- a/obp-api/src/test/scala/code/api/berlin/group/v1_3/AccountInformationServiceAISApiTest.scala +++ b/obp-api/src/test/scala/code/api/berlin/group/v1_3/AccountInformationServiceAISApiTest.scala @@ -38,13 +38,18 @@ class AccountInformationServiceAISApiTest extends BerlinGroupServerSetupV1_3 wit object getConsentStatus extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.getConsentStatus)) - object startConsentAuthorisation extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.startConsentAuthorisation)) + object startConsentAuthorisationTransactionAuthorisation extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationTransactionAuthorisation)) + object startConsentAuthorisationUpdatePsuAuthentication extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationUpdatePsuAuthentication)) + object startConsentAuthorisationSelectPsuAuthenticationMethod extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationSelectPsuAuthenticationMethod)) object getConsentAuthorisation extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.getConsentAuthorisation)) object getConsentScaStatus extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.getConsentScaStatus)) - object updateConsentsPsuData extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.updateConsentsPsuData)) + object updateConsentsPsuDataTransactionAuthorisation extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataTransactionAuthorisation)) + object updateConsentsPsuDataUpdatePsuAuthentication extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataUpdatePsuAuthentication)) + object updateConsentsPsuDataUpdateSelectPsuAuthenticationMethod extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataUpdateSelectPsuAuthenticationMethod)) + object updateConsentsPsuDataUpdateAuthorisationConfirmation extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataUpdateAuthorisationConfirmation)) feature(s"BG v1.3 - $getAccountList") { @@ -345,8 +350,8 @@ class AccountInformationServiceAISApiTest extends BerlinGroupServerSetupV1_3 wit } } - feature(s"BG v1.3 - ${startConsentAuthorisation.name} ") { - scenario("Authentication User, test succeed", BerlinGroupV1_3, startConsentAuthorisation) { + feature(s"BG v1.3 - ${startConsentAuthorisationTransactionAuthorisation.name} ") { + scenario("Authentication User, test succeed", BerlinGroupV1_3, startConsentAuthorisationTransactionAuthorisation) { val accountsRoutingIban = BankAccountRouting.findAll(By(BankAccountRouting.AccountRoutingScheme, AccountRoutingScheme.IBAN.toString)) val acountRoutingIban = accountsRoutingIban.head val postJsonBody = PostConsentJson( @@ -378,17 +383,33 @@ class AccountInformationServiceAISApiTest extends BerlinGroupServerSetupV1_3 wit val consentId =response.body.extract[PostConsentResponseJson].consentId - Then(s"We test the $startConsentAuthorisation") + Then(s"We test the $startConsentAuthorisationTransactionAuthorisation") val requestStartConsentAuthorisation = (V1_3_BG / "consents"/consentId /"authorisations" ).POST <@ (user1) - val responseStartConsentAuthorisation = makePostRequest(requestStartConsentAuthorisation, "") + val responseStartConsentAuthorisation = makePostRequest(requestStartConsentAuthorisation, """{"scaAuthenticationData":""}""") responseStartConsentAuthorisation.code should be (201) responseStartConsentAuthorisation.body.extract[StartConsentAuthorisationJson].scaStatus should be ("received") } } + + feature(s"BG v1.3 - ${startConsentAuthorisationUpdatePsuAuthentication.name} ") { + scenario("Authentication User, only mocked data, so only test successful case", BerlinGroupV1_3, startConsentAuthorisationUpdatePsuAuthentication) { + val requestStartConsentAuthorisation = (V1_3_BG / "consents"/"consentId" /"authorisations" ).POST <@ (user1) + val responseStartConsentAuthorisation = makePostRequest(requestStartConsentAuthorisation, """{ "psuData": { "password": "start12"}}""") + responseStartConsentAuthorisation.code should be (201) + } + } + + feature(s"BG v1.3 - ${startConsentAuthorisationSelectPsuAuthenticationMethod.name} ") { + scenario("Authentication User, only mocked data, so only test successful case", BerlinGroupV1_3, startConsentAuthorisationSelectPsuAuthenticationMethod) { + val requestStartConsentAuthorisation = (V1_3_BG / "consents"/"consentId" /"authorisations" ).POST <@ (user1) + val responseStartConsentAuthorisation = makePostRequest(requestStartConsentAuthorisation, """{"authenticationMethodId":"authenticationMethodId"}""") + responseStartConsentAuthorisation.code should be (201) + } + } - feature(s"BG v1.3 - ${startConsentAuthorisation.name} and ${getConsentAuthorisation.name} and ${getConsentScaStatus.name} and ${updateConsentsPsuData.name}") { - scenario("Authentication User, test succeed", BerlinGroupV1_3, startConsentAuthorisation) { + feature(s"BG v1.3 - ${startConsentAuthorisationTransactionAuthorisation.name} and ${getConsentAuthorisation.name} and ${getConsentScaStatus.name} and ${updateConsentsPsuDataTransactionAuthorisation.name}") { + scenario("Authentication User, test succeed", BerlinGroupV1_3, startConsentAuthorisationTransactionAuthorisation) { val accountsRoutingIban = BankAccountRouting.findAll(By(BankAccountRouting.AccountRoutingScheme, AccountRoutingScheme.IBAN.toString)) val acountRoutingIban = accountsRoutingIban.head val postJsonBody = PostConsentJson( @@ -420,9 +441,9 @@ class AccountInformationServiceAISApiTest extends BerlinGroupServerSetupV1_3 wit val consentId =response.body.extract[PostConsentResponseJson].consentId - Then(s"We test the $startConsentAuthorisation") + Then(s"We test the $startConsentAuthorisationTransactionAuthorisation") val requestStartConsentAuthorisation = (V1_3_BG / "consents"/consentId /"authorisations" ).POST <@ (user1) - val responseStartConsentAuthorisation = makePostRequest(requestStartConsentAuthorisation, "") + val responseStartConsentAuthorisation = makePostRequest(requestStartConsentAuthorisation, """{"scaAuthenticationData":""}""") responseStartConsentAuthorisation.code should be (201) responseStartConsentAuthorisation.body.extract[StartConsentAuthorisationJson].scaStatus should be ("received") @@ -441,4 +462,29 @@ class AccountInformationServiceAISApiTest extends BerlinGroupServerSetupV1_3 wit } } + feature(s"BG v1.3 - updateConsentsPsuData") { + scenario("Authentication User, only mocked data, just test succeed", BerlinGroupV1_3, updateConsentsPsuDataTransactionAuthorisation) { + val requestStartConsentAuthorisation = (V1_3_BG / "consents"/"consentId" /"authorisations"/ "AUTHORISATIONID" ).PUT <@ (user1) + val responseStartConsentAuthorisation = makePutRequest(requestStartConsentAuthorisation, """{"scaAuthenticationData":""}""") + responseStartConsentAuthorisation.code should be (400) + } + + + scenario("Authentication User, only mocked data, just test succeed -updateConsentsPsuDataUpdatePsuAuthentication", BerlinGroupV1_3, updateConsentsPsuDataUpdatePsuAuthentication) { + val requestStartConsentAuthorisation = (V1_3_BG / "consents"/"consentId" /"authorisations"/ "AUTHORISATIONID" ).PUT <@ (user1) + val responseStartConsentAuthorisation = makePutRequest(requestStartConsentAuthorisation, """{ "psuData":{"password":"start12" }}""") + responseStartConsentAuthorisation.code should be (200) + } + scenario("Authentication User, only mocked data, just test succeed-updateConsentsPsuDataUpdateSelectPsuAuthenticationMethod", BerlinGroupV1_3, updateConsentsPsuDataUpdateSelectPsuAuthenticationMethod) { + val requestStartConsentAuthorisation = (V1_3_BG / "consents"/"consentId" /"authorisations"/ "AUTHORISATIONID" ).PUT <@ (user1) + val responseStartConsentAuthorisation = makePutRequest(requestStartConsentAuthorisation, """{ "authenticationMethodId":""}""") + responseStartConsentAuthorisation.code should be (200) + } + scenario("Authentication User, only mocked data, just test succeed-updateConsentsPsuDataUpdateAuthorisationConfirmation", BerlinGroupV1_3, updateConsentsPsuDataUpdateAuthorisationConfirmation) { + val requestStartConsentAuthorisation = (V1_3_BG / "consents"/"consentId" /"authorisations"/ "AUTHORISATIONID" ).PUT <@ (user1) + val responseStartConsentAuthorisation = makePutRequest(requestStartConsentAuthorisation, """{"confirmationCode":"confirmationCode"}""") + responseStartConsentAuthorisation.code should be (200) + } + } + } \ No newline at end of file diff --git a/obp-api/src/test/scala/code/api/berlin/group/v1_3/PaymentInitiationServicePISApiTest.scala b/obp-api/src/test/scala/code/api/berlin/group/v1_3/PaymentInitiationServicePISApiTest.scala index 280f2ddc5b..57d27118f7 100644 --- a/obp-api/src/test/scala/code/api/berlin/group/v1_3/PaymentInitiationServicePISApiTest.scala +++ b/obp-api/src/test/scala/code/api/berlin/group/v1_3/PaymentInitiationServicePISApiTest.scala @@ -4,6 +4,7 @@ import code.api.BerlinGroup.ScaStatus import code.api.Constant import code.api.Constant.SYSTEM_READ_TRANSACTIONS_BERLIN_GROUP_VIEW_ID import code.api.berlin.group.v1_3.JSONFactory_BERLIN_GROUP_1_3.{CancellationJsonV13, InitiatePaymentResponseJson, StartPaymentAuthorisationJson} +import code.api.berlin.group.v1_3.model.{PsuData, ScaStatusResponse, UpdatePsuAuthenticationResponse} import code.api.builder.PaymentInitiationServicePISApi.APIMethods_PaymentInitiationServicePISApi import code.api.util.APIUtil.OAuth._ import code.api.util.APIUtil.extractErrorMessageCode @@ -24,21 +25,31 @@ import scala.collection.immutable.List class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with DefaultUsers { object PIS extends Tag("Payment Initiation Service (PIS)") - object initiatePayment extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.initiatePayment)) + object initiatePayment extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.initiatePayments)) object getPaymentInformation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.getPaymentInformation)) object getPaymentInitiationStatus extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.getPaymentInitiationStatus)) - object startPaymentAuthorisation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisation)) + object startPaymentAuthorisationTransactionAuthorisation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationTransactionAuthorisation )) + object startPaymentAuthorisationUpdatePsuAuthentication extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationUpdatePsuAuthentication)) + object startPaymentAuthorisationSelectPsuAuthenticationMethod extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationSelectPsuAuthenticationMethod)) object getPaymentInitiationAuthorisation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.getPaymentInitiationAuthorisation)) object getPaymentInitiationScaStatus extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.getPaymentInitiationScaStatus)) - object updatePaymentPsuData extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuData)) + object updatePaymentPsuDataTransactionAuthorisation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataTransactionAuthorisation)) + object updatePaymentPsuDataUpdatePsuAuthentication extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataUpdatePsuAuthentication)) + object updatePaymentPsuDataSelectPsuAuthenticationMethod extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataSelectPsuAuthenticationMethod)) + object updatePaymentPsuDataAuthorisationConfirmation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataAuthorisationConfirmation)) object cancelPayment extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.cancelPayment)) - object startPaymentInitiationCancellationAuthorisation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisation)) + object startPaymentInitiationCancellationAuthorisationTransactionAuthorisation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisationTransactionAuthorisation)) + object startPaymentInitiationCancellationAuthorisationUpdatePsuAuthentication extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisationUpdatePsuAuthentication)) + object startPaymentInitiationCancellationAuthorisationSelectPsuAuthenticationMethod extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisationSelectPsuAuthenticationMethod)) object getPaymentInitiationCancellationAuthorisationInformation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.getPaymentInitiationCancellationAuthorisationInformation)) object getPaymentCancellationScaStatus extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.getPaymentCancellationScaStatus)) - object updatePaymentCancellationPsuData extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuData)) + object updatePaymentCancellationPsuDataTransactionAuthorisation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataTransactionAuthorisation)) + object updatePaymentCancellationPsuDataUpdatePsuAuthentication extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataUpdatePsuAuthentication)) + object updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod)) + object updatePaymentCancellationPsuDataAuthorisationConfirmation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataAuthorisationConfirmation)) feature(s"test the BG v1.3 -${initiatePayment.name}") { scenario("Failed Case - Wrong Json format Body", BerlinGroupV1_3, PIS, initiatePayment) { @@ -289,16 +300,16 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with (responseGet.body \ "fundsAvailable").extract[Boolean] should be (true) } } - feature(s"test the BG v1.3 ${startPaymentAuthorisation.name} and ${getPaymentInitiationAuthorisation.name} and ${getPaymentInitiationScaStatus.name} and ${updatePaymentPsuData.name}") { - scenario(s"${startPaymentAuthorisation.name} Failed Case - Wrong PaymentId", BerlinGroupV1_3, PIS, startPaymentAuthorisation) { + feature(s"test the BG v1.3 ${startPaymentAuthorisationTransactionAuthorisation.name} and ${getPaymentInitiationAuthorisation.name} and ${getPaymentInitiationScaStatus.name} and ${updatePaymentPsuDataTransactionAuthorisation.name}") { + scenario(s"${startPaymentAuthorisationTransactionAuthorisation.name} Failed Case - Wrong PaymentId", BerlinGroupV1_3, PIS, startPaymentAuthorisationTransactionAuthorisation) { val requestPost = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / "PAYMENT_ID" / "authorisations").POST <@ (user1) - val response: APIResponse = makePostRequest(requestPost, """""") + val response: APIResponse = makePostRequest(requestPost, """{"scaAuthenticationData":"123"}""".stripMargin) Then("We should get a 400 ") response.code should equal(400) response.body.extract[ErrorMessage].message should startWith (InvalidTransactionRequestId) } - scenario(s"Successful Case ", BerlinGroupV1_3, PIS, startPaymentAuthorisation) { + scenario(s"Successful Case ", BerlinGroupV1_3, PIS, startPaymentAuthorisationTransactionAuthorisation) { val accountsRoutingIban = BankAccountRouting.findAll(By(BankAccountRouting.AccountRoutingScheme, AccountRoutingScheme.IBAN.toString)).filterNot(_.bankId.value == "DEFAULT_BANK_ID_NOT_SET") val acountRoutingIbanFrom = accountsRoutingIban.head val acountRoutingIbanTo = accountsRoutingIban.last @@ -340,11 +351,11 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with val paymentId = paymentResponseInitiatePaymentJson.paymentId - Then(s"we test the ${startPaymentAuthorisation.name}") + Then(s"we test the ${startPaymentAuthorisationTransactionAuthorisation.name}") val requestPost = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / paymentId / "authorisations").POST <@ (user1) - val response: APIResponse = makePostRequest(requestPost, """""") - Then("We should get a 200 ") - response.code should equal(200) + val response: APIResponse = makePostRequest(requestPost, """{"scaAuthenticationData":"123"}""".stripMargin) + Then("We should get a 201 ") + response.code should equal(201) val startPaymentAuthorisationResponse = response.body.extract[StartPaymentAuthorisationJson] startPaymentAuthorisationResponse.authorisationId should not be null startPaymentAuthorisationResponse.psuMessage should be ("Please check your SMS at a mobile device.") @@ -367,18 +378,17 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with val paymentInitiationScaStatus = (responseGetPaymentInitiationScaStatus.body \ "scaStatus").extract[String] paymentInitiationScaStatus should be (ScaStatus.received.toString) - Then(s"We can test the ${updatePaymentPsuData.name}") + Then(s"We can test the ${updatePaymentPsuDataTransactionAuthorisation.name}") val updatePaymentPsuDataJsonBody = APIMethods_PaymentInitiationServicePISApi .resourceDocs - .filter( _.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuData) + .filter( _.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataTransactionAuthorisation) .head.exampleRequestBody.asInstanceOf[JvalueCaseClass] //All the Json String convert to JvalueCaseClass implicitly .jvalueToCaseclass val requestUpdatePaymentPsuData = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / paymentId / "authorisations"/authorisationId).PUT <@ (user1) val responseUpdatePaymentPsuData: APIResponse = makePutRequest(requestUpdatePaymentPsuData, write(updatePaymentPsuDataJsonBody)) responseUpdatePaymentPsuData.code should be (200) - responseUpdatePaymentPsuData.body.extract[StartPaymentAuthorisationJson].scaStatus should be("finalised") - responseUpdatePaymentPsuData.body.extract[StartPaymentAuthorisationJson].authorisationId should be(authorisationId) + responseUpdatePaymentPsuData.body.extract[ScaStatusResponse].scaStatus should be("finalised") Thread.sleep(100) // wait for 100 milliseconds @@ -397,14 +407,64 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with } } - feature(s"test the BG v1.3 ${startPaymentInitiationCancellationAuthorisation.name} " + + + feature(s"test the BG v1.3 ${updatePaymentPsuDataUpdatePsuAuthentication} and ${updatePaymentPsuDataUpdatePsuAuthentication.name}") { + scenario(s"${startPaymentAuthorisationTransactionAuthorisation.name}" , BerlinGroupV1_3, PIS, updatePaymentPsuDataUpdatePsuAuthentication) { + + val requestPost = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / "PAYMENT_ID" / "authorisations" / "AUTHORISATION_ID").PUT <@ (user1) + val response: APIResponse = makePutRequest(requestPost, """{"psuData": {"password": "start12"}}""".stripMargin) + Then("We should get a 200 ") + response.code should equal(200) + } + } + + feature(s"test the BG v1.3 ${updatePaymentPsuDataSelectPsuAuthenticationMethod} and ${updatePaymentPsuDataSelectPsuAuthenticationMethod.name}") { + scenario(s"${startPaymentAuthorisationTransactionAuthorisation.name}" , BerlinGroupV1_3, PIS, updatePaymentPsuDataSelectPsuAuthenticationMethod) { + val requestPut = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / "PAYMENT_ID" / "authorisations" / "AUTHORISATION_ID").PUT <@ (user1) + val response: APIResponse = makePutRequest(requestPut, """{"authenticationMethodId":""}""".stripMargin) + Then("We should get a 200 ") + response.code should equal(200) + } + } + + feature(s"test the BG v1.3 ${updatePaymentPsuDataAuthorisationConfirmation} and ${updatePaymentPsuDataAuthorisationConfirmation.name}") { + scenario(s"${startPaymentAuthorisationTransactionAuthorisation.name}" , BerlinGroupV1_3, PIS, updatePaymentPsuDataAuthorisationConfirmation) { + + val requestPost = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / "PAYMENT_ID" / "authorisations"/"AUTHORISATION_ID").PUT <@ (user1) + val response: APIResponse = makePutRequest(requestPost, """{"confirmationCode":"confirmationCode"}""".stripMargin) + Then("We should get a 200 ") + response.code should equal(200) + } + } + + + feature(s"test the BG v1.3 ${startPaymentAuthorisationUpdatePsuAuthentication.name}") { + scenario(s"${startPaymentAuthorisationUpdatePsuAuthentication.name} ", BerlinGroupV1_3, PIS, startPaymentAuthorisationUpdatePsuAuthentication) { + + val requestPost = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / "PAYMENT_ID" / "authorisations").POST <@ (user1) + val response: APIResponse = makePostRequest(requestPost, """{ "psuData":{"password":"start12" }}""".stripMargin) + Then("We should get a 201") + response.code should equal(201) + } + } + feature(s"test the BG v1.3 ${startPaymentAuthorisationSelectPsuAuthenticationMethod.name}") { + scenario(s"${startPaymentAuthorisationSelectPsuAuthenticationMethod.name} ", BerlinGroupV1_3, PIS, startPaymentAuthorisationSelectPsuAuthenticationMethod) { + + val requestPost = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / "PAYMENT_ID" / "authorisations").POST <@ (user1) + val response: APIResponse = makePostRequest(requestPost, """{"authenticationMethodId":""}""".stripMargin) + Then("We should get a 201") + response.code should equal(201) + } + } + + feature(s"test the BG v1.3 ${startPaymentInitiationCancellationAuthorisationTransactionAuthorisation.name} " + s"and ${getPaymentInitiationCancellationAuthorisationInformation.name} " + s"and ${getPaymentCancellationScaStatus.name}" + - s"and ${updatePaymentCancellationPsuData.name}") { - scenario(s"${startPaymentInitiationCancellationAuthorisation.name} Failed Case - Wrong PaymentId", BerlinGroupV1_3, PIS, startPaymentInitiationCancellationAuthorisation) { + s"and ${updatePaymentCancellationPsuDataTransactionAuthorisation.name}") { + scenario(s"${startPaymentInitiationCancellationAuthorisationTransactionAuthorisation.name} Failed Case - Wrong PaymentId", BerlinGroupV1_3, PIS, startPaymentInitiationCancellationAuthorisationTransactionAuthorisation) { val requestPost = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / "PAYMENT_ID" / "cancellation-authorisations").POST <@ (user1) - val response: APIResponse = makePostRequest(requestPost, """""") + val response: APIResponse = makePostRequest(requestPost, """{"scaAuthenticationData":""}""") Then("We should get a 400 ") response.code should equal(400) response.body.extract[ErrorMessage].message should startWith (InvalidTransactionRequestId) @@ -447,16 +507,15 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with Then("We should get a 202") responseDelete.code should equal(202) - Then(s"we test the ${startPaymentInitiationCancellationAuthorisation.name}") + Then(s"we test the ${startPaymentInitiationCancellationAuthorisationTransactionAuthorisation.name}") val requestPost = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / paymentId / "cancellation-authorisations").POST <@ (user1) - val response: APIResponse = makePostRequest(requestPost, "") - Then("We should get a 200 ") - response.code should equal(200) - val startPaymentAuthorisationResponse = response.body.extract[StartPaymentAuthorisationJson] + val response: APIResponse = makePostRequest(requestPost, """{"scaAuthenticationData":""}""") + Then("We should get a 201 ") + response.code should equal(201) + val startPaymentAuthorisationResponse = response.body.extract[UpdatePsuAuthenticationResponse] startPaymentAuthorisationResponse.authorisationId should not be null - startPaymentAuthorisationResponse.psuMessage should be ("Please check your SMS at a mobile device.") + startPaymentAuthorisationResponse.psuMessage should be (Some("Please check your SMS at a mobile device.")) startPaymentAuthorisationResponse.scaStatus should be (ScaStatus.received.toString) - startPaymentAuthorisationResponse._links.scaStatus should not be null Then(s"We can test the ${getPaymentInitiationCancellationAuthorisationInformation.name}") val requestGetPaymentInitiationCancellationAuthorisationInformation = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / paymentId / "cancellation-authorisations").GET <@ (user1) @@ -473,19 +532,59 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with val cancellationScaStatus = (responseGetPaymentCancellationScaStatus.body \ "scaStatus").extract[String] cancellationScaStatus should be (ScaStatus.received.toString) - Then(s"We can test the ${updatePaymentCancellationPsuData.name}") - val updatePaymentCancellationPsuDataJsonBody = APIMethods_PaymentInitiationServicePISApi - .resourceDocs - .filter( _.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuData) - .head.exampleRequestBody.asInstanceOf[JvalueCaseClass] //All the Json String convert to JvalueCaseClass implicitly - .jvalueToCaseclass + Then(s"We can test the ${updatePaymentCancellationPsuDataTransactionAuthorisation.name}") val requestUpdatePaymentCancellationPsuData = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / paymentId / "cancellation-authorisations"/cancelationId).PUT <@ (user1) - val responseUpdatePaymentCancellationPsuData: APIResponse = makePutRequest(requestUpdatePaymentCancellationPsuData, write(updatePaymentCancellationPsuDataJsonBody)) + val responseUpdatePaymentCancellationPsuData: APIResponse = makePutRequest(requestUpdatePaymentCancellationPsuData, """{"scaAuthenticationData":"123"}""") responseUpdatePaymentCancellationPsuData.code should be (200) - responseUpdatePaymentCancellationPsuData.body.extract[StartPaymentAuthorisationJson].scaStatus should be("finalised") - responseUpdatePaymentCancellationPsuData.body.extract[StartPaymentAuthorisationJson].authorisationId should be(cancelationId) + responseUpdatePaymentCancellationPsuData.body.extract[ScaStatusResponse].scaStatus should be("finalised") + + } + } + + feature(s"test the BG v1.3 ${updatePaymentCancellationPsuDataUpdatePsuAuthentication.name}" ) { + scenario(s"${updatePaymentCancellationPsuDataUpdatePsuAuthentication.name}", BerlinGroupV1_3, PIS, updatePaymentCancellationPsuDataUpdatePsuAuthentication) { + + val requestPost = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / "PAYMENT_ID" / "cancellation-authorisations" /"authorisationId").PUT <@ (user1) + val response: APIResponse = makePutRequest(requestPost, """{"psuData":{"password":"start12"}}""") + Then("We should get a 200 ") + response.code should equal(200) + } + } + + feature(s"test the BG v1.3 ${updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod.name}" ) { + scenario(s"${updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod.name}", BerlinGroupV1_3, PIS, updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod) { + val requestPost = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / "PAYMENT_ID" / "cancellation-authorisations"/"authorisationId").PUT <@ (user1) + val response: APIResponse = makePutRequest(requestPost, """{"authenticationMethodId":""}""") + Then("We should get a 200 ") + response.code should equal(200) + } + } + + feature(s"test the BG v1.3 ${updatePaymentCancellationPsuDataAuthorisationConfirmation.name}" ) { + scenario(s"${updatePaymentCancellationPsuDataAuthorisationConfirmation.name}", BerlinGroupV1_3, PIS, updatePaymentCancellationPsuDataAuthorisationConfirmation) { + val requestPost = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / "PAYMENT_ID" / "cancellation-authorisations"/"authorisationId").PUT <@ (user1) + val response: APIResponse = makePutRequest(requestPost, """{"confirmationCode":"confirmationCode"}""") + Then("We should get a 200 ") + response.code should equal(200) + } + } + feature(s"test the BG v1.3 ${startPaymentInitiationCancellationAuthorisationUpdatePsuAuthentication.name}") { + scenario(s"${startPaymentInitiationCancellationAuthorisationUpdatePsuAuthentication.name}", BerlinGroupV1_3, PIS, startPaymentInitiationCancellationAuthorisationUpdatePsuAuthentication) { + val requestPost = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / "PAYMENT_ID" / "cancellation-authorisations").POST <@ (user1) + val response: APIResponse = makePostRequest(requestPost, """{"psuData":{"password":"start12"}}""") + Then("We should get a 201 ") + response.code should equal(201) + } + } + + feature(s"test the BG v1.3 ${startPaymentInitiationCancellationAuthorisationSelectPsuAuthenticationMethod.name}") { + scenario(s"${startPaymentInitiationCancellationAuthorisationSelectPsuAuthenticationMethod.name}", BerlinGroupV1_3, PIS, startPaymentInitiationCancellationAuthorisationSelectPsuAuthenticationMethod) { + val requestPost = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / "PAYMENT_ID" / "cancellation-authorisations").POST <@ (user1) + val response: APIResponse = makePostRequest(requestPost, """{"authenticationMethodId":""}""") + Then("We should get a 201 ") + response.code should equal(201) } }