From efbe6fb4f29710325e92b32d5d4c72fb6e2ae92a Mon Sep 17 00:00:00 2001 From: hongwei Date: Mon, 29 Jan 2024 15:34:45 +0100 Subject: [PATCH 01/28] docfix/tweaked the BGV13 document --- .../v1_3/AccountInformationServiceAISApi.scala | 13 ++++++++----- .../group/v1_3/JSONFactory_BERLIN_GROUP_1_3.scala | 13 +++++++++++++ 2 files changed, 21 insertions(+), 5 deletions(-) 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..0ea139f88e 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 @@ -123,8 +123,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 ) @@ -1055,10 +1054,11 @@ The ASPSP might make the usage of this access method unnecessary, since the rela * The signing basket needs to be authorised yet. """, - emptyObjectJson, + emptyObjectJson,//TODO in the `psd2-api v1.3.12-2022-07-06.yaml` it is a oneOf field, if OBP need it we can add it back. json.parse("""{ "scaStatus": "received", "psuMessage": "Please use your BankApp for transaction Authorisation.", + "authorisationId": "123auth456.", "_links": { "scaStatus": {"href":"/v1.3/consents/qwer3456tzui7890/authorisations/123auth456"} @@ -1132,7 +1132,10 @@ Maybe in a later version the access path will change. """, json.parse("""{"scaAuthenticationData":"123"}"""), - emptyObjectJson, + PutConsentResponseJson( + scaStatus = "received", + _links = ConsentLinksV13("/v1.3/consents/1234-wertiq-983/authorisations") + ), List(UserNotLoggedIn, UnknownError), ApiTag("Account Information Service (AIS)") :: apiTagBerlinGroupM :: Nil ) @@ -1184,7 +1187,7 @@ 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)) } } } 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..0b6a3e9a9a 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 @@ -218,6 +218,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 +236,7 @@ object JSONFactory_BERLIN_GROUP_1_3 extends CustomJsonFormats { case class StartConsentAuthorisationJson( scaStatus: String, + authorisationId: String, pushMessage: String, _links: ScaStatusJsonV13 ) @@ -502,6 +508,12 @@ object JSONFactory_BERLIN_GROUP_1_3 extends CustomJsonFormats { _links= ConsentLinksV13(s"/v1.3/consents/${consent.consentId}/authorisations") ) } + def createPutConsentResponseJson(consent: ConsentTrait) : PutConsentResponseJson = { + PutConsentResponseJson( + scaStatus = consent.status.toLowerCase(), + _links= ConsentLinksV13(s"/v1.3/consents/${consent.consentId}/authorisations") + ) + } def createGetConsentResponseJson(createdConsent: ConsentTrait) : GetConsentResponseJson = { val jsonWebTokenAsJValue: Box[ConsentJWT] = JwtUtil.getSignedPayloadAsJson(createdConsent.jsonWebToken) @@ -522,6 +534,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?? ) From 74aabe222168e39fd330f3e5e2708044de9611bd Mon Sep 17 00:00:00 2001 From: hongwei Date: Mon, 5 Feb 2024 12:29:24 +0100 Subject: [PATCH 02/28] bugfix/use JValue for the response, fixe the Swagger issue --- .../api/ResourceDocs1_4_0/SwaggerDefinitionsJSON.scala | 5 +++-- .../src/main/scala/code/api/v5_1_0/APIMethods510.scala | 8 ++++---- .../src/main/scala/code/api/v5_1_0/JSONFactory5.1.0.scala | 6 +++--- 3 files changed, 10 insertions(+), 9 deletions(-) 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/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()) ) } From 5cb6b6db9e48167ee4d14ef7ea80645fc38ffd24 Mon Sep 17 00:00:00 2001 From: hongwei Date: Tue, 6 Feb 2024 15:45:05 +0100 Subject: [PATCH 03/28] feature/seperate BG1.3 initiatePayments to 3 endpoints --- .../v1_3/PaymentInitiationServicePISApi.scala | 439 +++++++++++------- .../PaymentInitiationServicePISApiTest.scala | 2 +- 2 files changed, 283 insertions(+), 158 deletions(-) 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..4af1f0b279 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 @@ -7,7 +7,7 @@ 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.bankconnectors.Connector import code.fx.fx import code.api.Constant._ @@ -22,6 +22,7 @@ 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.Full import net.liftweb.http.js.JE.JsRaw import net.liftweb.http.rest.RestHelper @@ -51,7 +52,9 @@ object APIMethods_PaymentInitiationServicePISApi extends RestHelper { getPaymentInitiationCancellationAuthorisationInformation :: getPaymentInitiationScaStatus :: getPaymentInitiationStatus :: - initiatePayment :: + initiatePayments :: + initiateBulkPayments :: + initiatePeriodicPayments :: startPaymentAuthorisation :: startPaymentInitiationCancellationAuthorisation :: updatePaymentCancellationPsuData :: @@ -453,164 +456,286 @@ 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( + 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) } + } resourceDocs += ResourceDoc( startPaymentAuthorisation, 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..1a5eb46670 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 @@ -24,7 +24,7 @@ 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)) From f34f1b2ab1ecfe2cc4275466e8c299253149ac21 Mon Sep 17 00:00:00 2001 From: hongwei Date: Tue, 6 Feb 2024 16:13:14 +0100 Subject: [PATCH 04/28] feature/add the all BG1.3.12 models --- .../group/v1_3/model/AccountAccess.scala | 42 ++++++++++ .../group/v1_3/model/AccountDetails.scala | 55 ++++++++++++++ .../berlin/group/v1_3/model/AccountList.scala | 19 +++++ .../group/v1_3/model/AccountReference.scala | 30 ++++++++ .../group/v1_3/model/AccountReport.scala | 23 ++++++ .../group/v1_3/model/AccountStatus.scala | 18 +++++ .../api/berlin/group/v1_3/model/Address.scala | 24 ++++++ .../api/berlin/group/v1_3/model/Amount.scala | 22 ++++++ .../v1_3/model/AuthenticationObject.scala | 30 ++++++++ .../group/v1_3/model/AuthenticationType.scala | 18 +++++ .../group/v1_3/model/Authorisations.scala | 20 +++++ .../api/berlin/group/v1_3/model/Balance.scala | 31 ++++++++ .../berlin/group/v1_3/model/BalanceType.scala | 18 +++++ ...BulkPaymentInitiationCrossBorderJson.scala | 25 ++++++ ...tiationCrossBorderWithStatusResponse.scala | 29 +++++++ .../BulkPaymentInitiationSctInstJson.scala | 25 ++++++ ...tInitiationSctInstWithStatusResponse.scala | 29 +++++++ .../model/BulkPaymentInitiationSctJson.scala | 25 ++++++ ...ymentInitiationSctWithStatusResponse.scala | 29 +++++++ .../BulkPaymentInitiationTarget2Json.scala | 25 ++++++ ...tInitiationTarget2WithStatusResponse.scala | 29 +++++++ .../group/v1_3/model/CardAccountDetails.scala | 46 +++++++++++ .../group/v1_3/model/CardAccountList.scala | 19 +++++ .../group/v1_3/model/CardAccountReport.scala | 23 ++++++ .../CardAccountsTransactionsResponse200.scala | 23 ++++++ .../group/v1_3/model/CardTransaction.scala | 43 +++++++++++ .../group/v1_3/model/ChallengeData.scala | 38 ++++++++++ .../CheckAvailabilityOfFunds200Response.scala | 19 +++++ .../v1_3/model/ConfirmationOfFunds.scala | 24 ++++++ .../ConsentInformationResponse200Json.scala | 32 ++++++++ .../group/v1_3/model/ConsentStatus.scala | 18 +++++ .../v1_3/model/ConsentStatusResponse200.scala | 22 ++++++ .../berlin/group/v1_3/model/Consents.scala | 28 +++++++ .../v1_3/model/ConsentsResponse201.scala | 31 ++++++++ .../group/v1_3/model/DayOfExecution.scala | 18 +++++ .../berlin/group/v1_3/model/Error400AIS.scala | 32 ++++++++ .../Error400AISAdditionalErrorsInner.scala | 26 +++++++ .../group/v1_3/model/Error400NGAIS.scala | 20 +++++ .../group/v1_3/model/Error400NGPIIS.scala | 20 +++++ .../group/v1_3/model/Error400NGPIS.scala | 20 +++++ .../group/v1_3/model/Error400NGSB.scala | 20 +++++ .../group/v1_3/model/Error400PIIS.scala | 32 ++++++++ .../Error400PIISAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error400PIS.scala | 32 ++++++++ .../Error400PISAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error400SB.scala | 32 ++++++++ .../Error400SBAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error401AIS.scala | 32 ++++++++ .../Error401AISAdditionalErrorsInner.scala | 26 +++++++ .../group/v1_3/model/Error401NGAIS.scala | 20 +++++ .../group/v1_3/model/Error401NGPIIS.scala | 20 +++++ .../group/v1_3/model/Error401NGPIS.scala | 20 +++++ .../group/v1_3/model/Error401NGSB.scala | 20 +++++ .../group/v1_3/model/Error401PIIS.scala | 32 ++++++++ .../Error401PIISAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error401PIS.scala | 32 ++++++++ .../Error401PISAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error401SB.scala | 32 ++++++++ .../Error401SBAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error403AIS.scala | 32 ++++++++ .../Error403AISAdditionalErrorsInner.scala | 26 +++++++ .../group/v1_3/model/Error403NGAIS.scala | 20 +++++ .../group/v1_3/model/Error403NGPIIS.scala | 20 +++++ .../group/v1_3/model/Error403NGPIS.scala | 20 +++++ .../group/v1_3/model/Error403NGSB.scala | 20 +++++ .../group/v1_3/model/Error403PIIS.scala | 32 ++++++++ .../Error403PIISAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error403PIS.scala | 32 ++++++++ .../Error403PISAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error403SB.scala | 32 ++++++++ .../Error403SBAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error404AIS.scala | 32 ++++++++ .../Error404AISAdditionalErrorsInner.scala | 26 +++++++ .../group/v1_3/model/Error404NGAIS.scala | 20 +++++ .../group/v1_3/model/Error404NGPIIS.scala | 20 +++++ .../group/v1_3/model/Error404NGPIS.scala | 20 +++++ .../group/v1_3/model/Error404NGSB.scala | 20 +++++ .../group/v1_3/model/Error404PIIS.scala | 32 ++++++++ .../Error404PIISAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error404PIS.scala | 32 ++++++++ .../Error404PISAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error404SB.scala | 32 ++++++++ .../Error404SBAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error405AIS.scala | 32 ++++++++ .../Error405AISAdditionalErrorsInner.scala | 26 +++++++ .../group/v1_3/model/Error405NGAIS.scala | 20 +++++ .../group/v1_3/model/Error405NGPIIS.scala | 20 +++++ .../group/v1_3/model/Error405NGPIS.scala | 20 +++++ .../group/v1_3/model/Error405NGPISCANC.scala | 20 +++++ .../group/v1_3/model/Error405NGSB.scala | 20 +++++ .../group/v1_3/model/Error405PIIS.scala | 32 ++++++++ .../Error405PIISAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error405PIS.scala | 32 ++++++++ .../Error405PISAdditionalErrorsInner.scala | 26 +++++++ .../group/v1_3/model/Error405PISCANC.scala | 32 ++++++++ ...Error405PISCANCAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error405SB.scala | 32 ++++++++ .../Error405SBAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error406AIS.scala | 32 ++++++++ .../Error406AISAdditionalErrorsInner.scala | 26 +++++++ .../group/v1_3/model/Error406NGAIS.scala | 20 +++++ .../berlin/group/v1_3/model/Error409AIS.scala | 32 ++++++++ .../Error409AISAdditionalErrorsInner.scala | 26 +++++++ .../group/v1_3/model/Error409NGAIS.scala | 20 +++++ .../group/v1_3/model/Error409NGPIIS.scala | 20 +++++ .../group/v1_3/model/Error409NGPIS.scala | 20 +++++ .../group/v1_3/model/Error409NGSB.scala | 20 +++++ .../group/v1_3/model/Error409PIIS.scala | 32 ++++++++ .../Error409PIISAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error409PIS.scala | 32 ++++++++ .../Error409PISAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error409SB.scala | 32 ++++++++ .../Error409SBAdditionalErrorsInner.scala | 26 +++++++ .../berlin/group/v1_3/model/Error429AIS.scala | 32 ++++++++ .../Error429AISAdditionalErrorsInner.scala | 26 +++++++ .../group/v1_3/model/Error429NGAIS.scala | 20 +++++ .../group/v1_3/model/ExchangeRate.scala | 27 +++++++ .../group/v1_3/model/ExecutionRule.scala | 18 +++++ .../group/v1_3/model/FrequencyCode.scala | 18 +++++ .../GetPaymentInformation200Response.scala | 45 +++++++++++ .../model/GetTransactionList200Response.scala | 18 +++++ .../GetTransactionList200Response1.scala | 18 +++++ .../model/InitiatePayment201Response.scala | 35 +++++++++ .../v1_3/model/InitiatePaymentRequest.scala | 44 +++++++++++ .../v1_3/model/InitiatePaymentRequest1.scala | 18 +++++ .../v1_3/model/LinksAccountDetails.scala | 22 ++++++ .../group/v1_3/model/LinksAccountReport.scala | 28 +++++++ .../berlin/group/v1_3/model/LinksAll.scala | 76 +++++++++++++++++++ .../v1_3/model/LinksCardAccountReport.scala | 28 +++++++ .../group/v1_3/model/LinksConsents.scala | 40 ++++++++++ .../group/v1_3/model/LinksDownload.scala | 20 +++++ .../v1_3/model/LinksPaymentInitiation.scala | 40 ++++++++++ .../model/LinksPaymentInitiationCancel.scala | 28 +++++++ .../LinksPaymentInitiationMultiLevelSca.scala | 28 +++++++ .../LinksSelectPsuAuthenticationMethod.scala | 30 ++++++++ .../group/v1_3/model/LinksSigningBasket.scala | 40 ++++++++++ .../v1_3/model/LinksStartScaProcess.scala | 34 +++++++++ .../v1_3/model/LinksTransactionDetails.scala | 20 +++++ .../model/LinksUpdatePsuAuthentication.scala | 24 ++++++ .../model/LinksUpdatePsuIdentification.scala | 20 +++++ .../group/v1_3/model/MessageCode2XX.scala | 18 +++++ .../group/v1_3/model/MessageCode400AIS.scala | 18 +++++ .../group/v1_3/model/MessageCode400PIIS.scala | 18 +++++ .../group/v1_3/model/MessageCode400PIS.scala | 18 +++++ .../group/v1_3/model/MessageCode400SB.scala | 18 +++++ .../group/v1_3/model/MessageCode401AIS.scala | 18 +++++ .../group/v1_3/model/MessageCode401PIIS.scala | 18 +++++ .../group/v1_3/model/MessageCode401PIS.scala | 18 +++++ .../group/v1_3/model/MessageCode401SB.scala | 18 +++++ .../group/v1_3/model/MessageCode403AIS.scala | 18 +++++ .../group/v1_3/model/MessageCode403PIIS.scala | 18 +++++ .../group/v1_3/model/MessageCode403PIS.scala | 18 +++++ .../group/v1_3/model/MessageCode403SB.scala | 18 +++++ .../group/v1_3/model/MessageCode404AIS.scala | 18 +++++ .../group/v1_3/model/MessageCode404PIIS.scala | 18 +++++ .../group/v1_3/model/MessageCode404PIS.scala | 18 +++++ .../group/v1_3/model/MessageCode404SB.scala | 18 +++++ .../group/v1_3/model/MessageCode405AIS.scala | 18 +++++ .../group/v1_3/model/MessageCode405PIIS.scala | 18 +++++ .../group/v1_3/model/MessageCode405PIS.scala | 18 +++++ .../v1_3/model/MessageCode405PISCANC.scala | 18 +++++ .../group/v1_3/model/MessageCode405SB.scala | 18 +++++ .../group/v1_3/model/MessageCode406AIS.scala | 18 +++++ .../group/v1_3/model/MessageCode409AIS.scala | 18 +++++ .../group/v1_3/model/MessageCode409PIIS.scala | 18 +++++ .../group/v1_3/model/MessageCode409PIS.scala | 18 +++++ .../group/v1_3/model/MessageCode409SB.scala | 18 +++++ .../group/v1_3/model/MessageCode429AIS.scala | 18 +++++ ...ationRequestMultiLevelScaResponse201.scala | 31 ++++++++ .../PaymentInitationRequestResponse201.scala | 35 +++++++++ ...aymentInitiationCancelResponse204202.scala | 27 +++++++ ...InitiationCrossBorderBulkElementJson.scala | 26 +++++++ .../PaymentInitiationCrossBorderJson.scala | 27 +++++++ ...tiationCrossBorderWithStatusResponse.scala | 31 ++++++++ .../PaymentInitiationSctBulkElementJson.scala | 28 +++++++ ...mentInitiationSctInstBulkElementJson.scala | 27 +++++++ .../model/PaymentInitiationSctInstJson.scala | 28 +++++++ ...tInitiationSctInstWithStatusResponse.scala | 32 ++++++++ .../v1_3/model/PaymentInitiationSctJson.scala | 29 +++++++ ...ymentInitiationSctWithStatusResponse.scala | 33 ++++++++ ...ymentInitiationStatusResponse200Json.scala | 22 ++++++ ...mentInitiationTarget2BulkElementJson.scala | 27 +++++++ .../model/PaymentInitiationTarget2Json.scala | 28 +++++++ ...tInitiationTarget2WithStatusResponse.scala | 32 ++++++++ ...odicPaymentInitiationCrossBorderJson.scala | 38 ++++++++++ ...tiationCrossBorderWithStatusResponse.scala | 39 ++++++++++ ...PeriodicPaymentInitiationSctInstJson.scala | 39 ++++++++++ ...tInitiationSctInstWithStatusResponse.scala | 41 ++++++++++ .../PeriodicPaymentInitiationSctJson.scala | 40 ++++++++++ ...ymentInitiationSctWithStatusResponse.scala | 41 ++++++++++ ...PeriodicPaymentInitiationTarget2Json.scala | 39 ++++++++++ ...tInitiationTarget2WithStatusResponse.scala | 40 ++++++++++ ...tiationXmlPart2StandingorderTypeJson.scala | 29 +++++++ .../api/berlin/group/v1_3/model/PsuData.scala | 20 +++++ .../berlin/group/v1_3/model/PurposeCode.scala | 18 +++++ .../model/ReadAccountBalanceResponse200.scala | 21 +++++ .../ReadCardAccountBalanceResponse200.scala | 21 +++++ .../RemittanceInformationStructured.scala | 21 +++++ .../berlin/group/v1_3/model/ScaStatus.scala | 18 +++++ .../group/v1_3/model/ScaStatusResponse.scala | 22 ++++++ .../model/SelectPsuAuthenticationMethod.scala | 20 +++++ ...electPsuAuthenticationMethodResponse.scala | 27 +++++++ .../group/v1_3/model/SigningBasket.scala | 22 ++++++ .../v1_3/model/SigningBasketResponse200.scala | 26 +++++++ .../v1_3/model/SigningBasketResponse201.scala | 32 ++++++++ .../SigningBasketStatusResponse200.scala | 22 ++++++ .../v1_3/model/StartScaprocessResponse.scala | 29 +++++++ .../group/v1_3/model/TppMessage2XX.scala | 26 +++++++ .../group/v1_3/model/TppMessage400AIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage400PIIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage400PIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage400SB.scala | 26 +++++++ .../group/v1_3/model/TppMessage401AIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage401PIIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage401PIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage401SB.scala | 26 +++++++ .../group/v1_3/model/TppMessage403AIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage403PIIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage403PIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage403SB.scala | 26 +++++++ .../group/v1_3/model/TppMessage404AIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage404PIIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage404PIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage404SB.scala | 26 +++++++ .../group/v1_3/model/TppMessage405AIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage405PIIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage405PIS.scala | 26 +++++++ .../v1_3/model/TppMessage405PISCANC.scala | 26 +++++++ .../group/v1_3/model/TppMessage405SB.scala | 26 +++++++ .../group/v1_3/model/TppMessage406AIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage409AIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage409PIIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage409PIS.scala | 26 +++++++ .../group/v1_3/model/TppMessage409SB.scala | 26 +++++++ .../group/v1_3/model/TppMessage429AIS.scala | 26 +++++++ .../group/v1_3/model/TppMessageCategory.scala | 18 +++++ .../v1_3/model/TransactionAuthorisation.scala | 20 +++++ .../group/v1_3/model/TransactionDetails.scala | 60 +++++++++++++++ .../group/v1_3/model/TransactionStatus.scala | 18 +++++ .../v1_3/model/TransactionStatusSB.scala | 18 +++++ .../model/TransactionsResponse200Json.scala | 23 ++++++ .../UpdatePaymentPsuData200Response.scala | 29 +++++++ .../model/UpdatePaymentPsuDataRequest.scala | 23 ++++++ .../v1_3/model/UpdatePsuAuthentication.scala | 19 +++++ .../UpdatePsuAuthenticationResponse.scala | 29 +++++++ .../model/UpdatePsuIdenticationResponse.scala | 25 ++++++ .../berlin/group/v1_3/model/requests.scala | 17 +++++ 247 files changed, 6434 insertions(+) create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountAccess.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountDetails.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountList.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountReference.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountReport.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountStatus.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Address.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Amount.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthenticationObject.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthenticationType.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Authorisations.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Balance.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BalanceType.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationCrossBorderJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationCrossBorderWithStatusResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationSctInstJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationSctInstWithStatusResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationSctJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationSctWithStatusResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationTarget2Json.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationTarget2WithStatusResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountDetails.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountList.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountReport.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountsTransactionsResponse200.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardTransaction.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ChallengeData.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CheckAvailabilityOfFunds200Response.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConfirmationOfFunds.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentInformationResponse200Json.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentStatus.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentStatusResponse200.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Consents.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentsResponse201.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/DayOfExecution.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400AISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGAIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGPIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGPIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGSB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PIISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400SBAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401AISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGAIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGPIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGPIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGSB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PIISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401SBAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403AISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGAIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGPIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGPIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGSB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PIISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403SBAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404AISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGAIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGPIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGPIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGSB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PIISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404SBAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405AISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGAIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGPIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGPIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGPISCANC.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGSB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PIISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PISCANC.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PISCANCAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405SBAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error406AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error406AISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error406NGAIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409AISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGAIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGPIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGPIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGSB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PIISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409SBAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error429AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error429AISAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error429NGAIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ExchangeRate.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ExecutionRule.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/FrequencyCode.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetPaymentInformation200Response.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetTransactionList200Response.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetTransactionList200Response1.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/InitiatePayment201Response.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/InitiatePaymentRequest.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/InitiatePaymentRequest1.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAccountDetails.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAccountReport.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAll.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksCardAccountReport.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksConsents.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksDownload.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksPaymentInitiation.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksPaymentInitiationCancel.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksPaymentInitiationMultiLevelSca.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksSelectPsuAuthenticationMethod.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksSigningBasket.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksStartScaProcess.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksTransactionDetails.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksUpdatePsuAuthentication.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksUpdatePsuIdentification.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode2XX.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405PISCANC.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode406AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode429AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitationRequestMultiLevelScaResponse201.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitationRequestResponse201.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCancelResponse204202.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCrossBorderBulkElementJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCrossBorderJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCrossBorderWithStatusResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctBulkElementJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctInstBulkElementJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctInstJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctInstWithStatusResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationSctWithStatusResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationStatusResponse200Json.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationTarget2BulkElementJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationTarget2Json.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationTarget2WithStatusResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationCrossBorderJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationCrossBorderWithStatusResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationSctInstJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationSctInstWithStatusResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationSctJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationSctWithStatusResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationTarget2Json.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationTarget2WithStatusResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationXmlPart2StandingorderTypeJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PsuData.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PurposeCode.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadAccountBalanceResponse200.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadCardAccountBalanceResponse200.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/RemittanceInformationStructured.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ScaStatus.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ScaStatusResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SelectPsuAuthenticationMethod.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SelectPsuAuthenticationMethodResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasket.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasketResponse200.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasketResponse201.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasketStatusResponse200.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/StartScaprocessResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage2XX.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405PISCANC.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage406AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409PIIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409PIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409SB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage429AIS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessageCategory.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionAuthorisation.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionDetails.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionStatus.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionStatusSB.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionsResponse200Json.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePaymentPsuData200Response.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePaymentPsuDataRequest.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuAuthentication.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuAuthenticationResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuIdenticationResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/requests.scala 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..b7d1f624a9 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountAccess.scala @@ -0,0 +1,42 @@ +/** + * 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 AccountAccess ( + /* Is asking for detailed account information. If the array is empty, 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 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, 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 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, 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 or balances shall be empty, if used. */ + transactions: Option[Seq[AccountReference]] = None, + /* Optional if supported by API provider. Only the values \"allAccounts\" or \"allAccountsWithBalances\" is admitted. */ + availableAccounts: Option[AccountAccessEnums.AvailableAccounts] = None, + /* Optional if supported by API provider. Only the value \"allAccounts\" is admitted. */ + allPsd2: Option[AccountAccessEnums.AllPsd2] = None +) extends ApiModel + +object AccountAccessEnums { + + type AvailableAccounts = AvailableAccounts.Value + type AllPsd2 = AllPsd2.Value + object AvailableAccounts extends Enumeration { + val AllAccounts = Value("allAccounts") + val AllAccountsWithBalances = Value("allAccountsWithBalances") + } + + object AllPsd2 extends Enumeration { + val AllAccounts = Value("allAccounts") + } + +} 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..b5fc3926e9 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountDetails.scala @@ -0,0 +1,55 @@ +/** + * 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 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 account given by the bank or the PSU in online-banking. */ + name: 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 migght be restricted to the current ballance. */ + 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..ff64886471 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountList.scala @@ -0,0 +1,19 @@ +/** + * 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 AccountList ( + accounts: Seq[AccountDetails] +) 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..faaff4de58 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountReference.scala @@ -0,0 +1,30 @@ +/** + * 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 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, + /* ISO 4217 Alpha 3 currency code */ + currency: 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..95955c1698 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountReport.scala @@ -0,0 +1,23 @@ +/** + * 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 AccountReport ( + /* Array of transaction details */ + booked: Option[Seq[TransactionDetails]] = None, + /* Array of transaction details */ + pending: Option[Seq[TransactionDetails]] = 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..0fc66c3071 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountStatus.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 AccountStatus ( +) 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..479684c361 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Address.scala @@ -0,0 +1,24 @@ +/** + * 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 Address ( + street: Option[String] = None, + buildingNumber: Option[String] = None, + city: Option[String] = None, + postalCode: 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..db4f0829be --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Amount.scala @@ -0,0 +1,22 @@ +/** + * 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 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..3469775a5a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthenticationObject.scala @@ -0,0 +1,30 @@ +/** + * 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 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..f148a5b4cd --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthenticationType.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 AuthenticationType ( +) extends ApiModel + 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..e79dc02bdc --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Authorisations.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 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..fc2f8061e7 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Balance.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 + +import java.time.LocalDate +import java.time.OffsetDateTime + + +case class Balance ( + balanceAmount: Amount, + balanceType: BalanceType, + /* 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, + /* Reference date of the balance */ + referenceDate: Option[LocalDate] = None, + /* \"entryReference\" of the last commited 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..6d491bc590 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BalanceType.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 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/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/CardAccountDetails.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountDetails.scala new file mode 100644 index 0000000000..a42d30ba61 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountDetails.scala @@ -0,0 +1,46 @@ +/** + * 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 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 account given by the bank or the PSU in online-banking. */ + name: Option[String] = None, + /* Product name of the bank for this account, proprietary definition. */ + product: Option[String] = 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 migght be restricted to the current ballance. */ + 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..34cba451f2 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountList.scala @@ -0,0 +1,19 @@ +/** + * 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 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..efdbc63ef2 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountReport.scala @@ -0,0 +1,23 @@ +/** + * 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 CardAccountReport ( + /* Array of transaction details */ + booked: Seq[CardTransaction], + /* 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..a1aa32824e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardAccountsTransactionsResponse200.scala @@ -0,0 +1,23 @@ +/** + * 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 CardAccountsTransactionsResponse200 ( + cardAccount: Option[AccountReference] = None, + cardTransactions: Option[CardAccountReport] = None, + /* A list of balances regarding this account, e.g. the current balance, the last booked balance. The list migght be restricted to the current ballance. */ + 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..3e35378851 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardTransaction.scala @@ -0,0 +1,43 @@ +/** + * 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 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, + /* The Date when an entry is posted to an account on the ASPSPs books. */ + bookingDate: Option[LocalDate] = None, + transactionAmount: Amount, + /* Array of exchange rates */ + exchangeRate: Option[Seq[ExchangeRate]] = None, + originalAmount: Option[Amount] = None, + markupFee: Option[Amount] = None, + markupFeePercentage: Option[String] = None, + cardAcceptorId: Option[String] = None, + cardAcceptorAddress: Option[Address] = None, + /* Card Acceptor Category Code of the Card Acceptor as given in the related card transaction. */ + cardAcceptorCategoryCode: 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/ChallengeData.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ChallengeData.scala new file mode 100644 index 0000000000..16e670301c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ChallengeData.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 + + +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, + /* String challenge data */ + data: Option[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/CheckAvailabilityOfFunds200Response.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CheckAvailabilityOfFunds200Response.scala new file mode 100644 index 0000000000..7ff1631af9 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CheckAvailabilityOfFunds200Response.scala @@ -0,0 +1,19 @@ +/** + * 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 CheckAvailabilityOfFunds200Response ( + 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..6b27b98ff0 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConfirmationOfFunds.scala @@ -0,0 +1,24 @@ +/** + * 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 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..a034e8bc9a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentInformationResponse200Json.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.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 requesting a valid until 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\". */ + 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 +) 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..fb37b32802 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentStatus.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 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..5ccc3c6a9c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentStatusResponse200.scala @@ -0,0 +1,22 @@ +/** + * 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 ConsentStatusResponse200 ( + consentStatus: ConsentStatus +) 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..fe0dd33a84 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Consents.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 + +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 requesting a valid until 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\". */ + 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..ab9972637e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ConsentsResponse201.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 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 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: LinksConsents, + /* Text to be displayed to the PSU, e.g. in a Decoupled SCA Approach. */ + message: 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..fc974d9fc6 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/DayOfExecution.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 DayOfExecution ( +) extends ApiModel + 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..66a6ba8f85 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400AIS.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 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..e07c8ea864 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400AISAdditionalErrorsInner.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 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..d0e5ad0bb6 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGAIS.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 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..39a9ddeb59 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGPIIS.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 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..e08cbf34dd --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGPIS.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 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..1a474e88c2 --- /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/Error400PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PIIS.scala new file mode 100644 index 0000000000..151e158f93 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PIIS.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 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..3ae1eb8309 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PIISAdditionalErrorsInner.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 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..db35bacbca --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PIS.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 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..e9660ce83e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400PISAdditionalErrorsInner.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 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..2f8318e1f4 --- /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/Error401AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401AIS.scala new file mode 100644 index 0000000000..0941fa83f5 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401AIS.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 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..593c09c159 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401AISAdditionalErrorsInner.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 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..a52003a878 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGAIS.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 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..f3f18efa51 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGPIIS.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 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..e1e77b1593 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGPIS.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 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..ef1daccf2b --- /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/Error401PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PIIS.scala new file mode 100644 index 0000000000..d13e28e586 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PIIS.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 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..a9fd6b7b3d --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PIISAdditionalErrorsInner.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 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..2605088111 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PIS.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 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..21f930cef5 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401PISAdditionalErrorsInner.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 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..40c23dea38 --- /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/Error403AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403AIS.scala new file mode 100644 index 0000000000..7743b673cc --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403AIS.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 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..0a06bce6dd --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403AISAdditionalErrorsInner.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 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..4462c46c83 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGAIS.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 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..432eb3d235 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGPIIS.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 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..90093811ad --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGPIS.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 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..34ce6109e9 --- /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/Error403PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PIIS.scala new file mode 100644 index 0000000000..9a2fdf3cda --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PIIS.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 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..80b2611238 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PIISAdditionalErrorsInner.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 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..94f6c2ceb6 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PIS.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 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..560daee361 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403PISAdditionalErrorsInner.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 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..e2fc2b46bd --- /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/Error404AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404AIS.scala new file mode 100644 index 0000000000..f15c0b5c46 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404AIS.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 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..cfd4148ee2 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404AISAdditionalErrorsInner.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 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..1acb3257df --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGAIS.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 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..59b69a1712 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGPIIS.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 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..ec07e5fed4 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGPIS.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 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..424c06d9d9 --- /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/Error404PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PIIS.scala new file mode 100644 index 0000000000..4e34bf60e1 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PIIS.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 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..c0d8f44c6c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PIISAdditionalErrorsInner.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 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..41e717504f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PIS.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 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..fef5a16a20 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404PISAdditionalErrorsInner.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 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..875c04f2b5 --- /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/Error405AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405AIS.scala new file mode 100644 index 0000000000..6eee277eab --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405AIS.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 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..b2bfd0bf84 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405AISAdditionalErrorsInner.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 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..99c7da5959 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGAIS.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 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..cbc7728682 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGPIIS.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 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..4d353d7709 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGPIS.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 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..4c8f25a09e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGPISCANC.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 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..a9ba399ba4 --- /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/Error405PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PIIS.scala new file mode 100644 index 0000000000..18141909c0 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PIIS.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 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..f099a5d0de --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PIISAdditionalErrorsInner.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 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..332f0ec5af --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PIS.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 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..abd1bc8a47 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PISAdditionalErrorsInner.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 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..50ea5cc851 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PISCANC.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 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..53c702b521 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405PISCANCAdditionalErrorsInner.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 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..601d37051f --- /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/Error406AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error406AIS.scala new file mode 100644 index 0000000000..6841053975 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error406AIS.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 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..ad2ff43623 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error406AISAdditionalErrorsInner.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 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..1d060b8794 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error406NGAIS.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 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..0a785a35b0 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409AIS.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 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..1e9622987a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409AISAdditionalErrorsInner.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 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..450c40650a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGAIS.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 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..63e0bf4402 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGPIIS.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 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..998af9c069 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGPIS.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 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..b91aeb2567 --- /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/Error409PIIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PIIS.scala new file mode 100644 index 0000000000..b331f6df68 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PIIS.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 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..7e63581805 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PIISAdditionalErrorsInner.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 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..5d896f58fc --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PIS.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 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..b5170c7b85 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409PISAdditionalErrorsInner.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 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..be707ac73e --- /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/Error429AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error429AIS.scala new file mode 100644 index 0000000000..da2d209f09 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error429AIS.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 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..7147cd0577 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error429AISAdditionalErrorsInner.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 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..8a64fefd46 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error429NGAIS.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 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..26271f70bf --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ExecutionRule.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 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..a6ce7f09d0 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/FrequencyCode.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 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..dbe1a15370 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetPaymentInformation200Response.scala @@ -0,0 +1,45 @@ +/** + * 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 GetPaymentInformation200Response ( + 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, + /* 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, + /* A list of JSON bodies for cross-border payments. */ + payments: Seq[PaymentInitiationCrossBorderJson] +) extends ApiModel + +object GetPaymentInformation200ResponseEnums { + +} 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..6c01fa790a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetTransactionList200Response.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 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..e694e2242c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetTransactionList200Response1.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 GetTransactionList200Response1 ( +) 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..6a1755c2b6 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/InitiatePaymentRequest.scala @@ -0,0 +1,44 @@ +/** + * 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 InitiatePaymentRequest ( + 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, + /* 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, + /* A List of JSON bodies for cross-border payments. */ + payments: Seq[PaymentInitiationCrossBorderBulkElementJson] +) 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..ca3700a8f2 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/InitiatePaymentRequest1.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 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..5ea0da175c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAccountDetails.scala @@ -0,0 +1,22 @@ +/** + * 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 LinksAccountDetails ( + /* Link to a resource */ + balances: Option[String] = None, + /* Link to a resource */ + transactions: Option[String] = 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..9917ea6242 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAccountReport.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 LinksAccountReport ( + /* Link to a resource */ + account: String, + /* Link to a resource */ + first: Option[String] = None, + /* Link to a resource */ + next: Option[String] = None, + /* Link to a resource */ + previous: Option[String] = None, + /* Link to a resource */ + last: Option[String] = 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..31af0a0f24 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAll.scala @@ -0,0 +1,76 @@ +/** + * 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 LinksAll ( + /* Link to a resource */ + scaRedirect: Option[String] = None, + /* Link to a resource */ + scaOAuth: Option[String] = None, + /* Link to a resource */ + startAuthorisation: Option[String] = None, + /* Link to a resource */ + startAuthorisationWithPsuIdentification: Option[String] = None, + /* Link to a resource */ + updatePsuIdentification: Option[String] = None, + /* Link to a resource */ + startAuthorisationWithProprietaryData: Option[String] = None, + /* Link to a resource */ + updateProprietaryData: Option[String] = None, + /* Link to a resource */ + startAuthorisationWithPsuAuthentication: Option[String] = None, + /* Link to a resource */ + updatePsuAuthentication: Option[String] = None, + /* Link to a resource */ + startAuthorisationWithEncryptedPsuAuthentication: Option[String] = None, + /* Link to a resource */ + updateEncryptedPsuAuthentication: Option[String] = None, + /* Link to a resource */ + startAuthorisationWithAuthenticationMethodSelection: Option[String] = None, + /* Link to a resource */ + selectAuthenticationMethod: Option[String] = None, + /* Link to a resource */ + startAuthorisationWithTransactionAuthorisation: Option[String] = None, + /* Link to a resource */ + authoriseTransaction: Option[String] = None, + /* Link to a resource */ + self: Option[String] = None, + /* Link to a resource */ + status: Option[String] = None, + /* Link to a resource */ + scaStatus: Option[String] = None, + /* Link to a resource */ + account: Option[String] = None, + /* Link to a resource */ + balances: Option[String] = None, + /* Link to a resource */ + transactions: Option[String] = None, + /* Link to a resource */ + transactionDetails: Option[String] = None, + /* Link to a resource */ + cardAccount: Option[String] = None, + /* Link to a resource */ + cardTransactions: Option[String] = None, + /* Link to a resource */ + first: Option[String] = None, + /* Link to a resource */ + next: Option[String] = None, + /* Link to a resource */ + previous: Option[String] = None, + /* Link to a resource */ + last: Option[String] = None, + /* Link to a resource */ + download: Option[String] = 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..96481269e9 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksCardAccountReport.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 LinksCardAccountReport ( + /* Link to a resource */ + cardAccount: String, + /* Link to a resource */ + first: Option[String] = None, + /* Link to a resource */ + next: Option[String] = None, + /* Link to a resource */ + previous: Option[String] = None, + /* Link to a resource */ + last: Option[String] = 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..61b1198abe --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksConsents.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 + + + +case class LinksConsents ( + /* Link to a resource */ + scaRedirect: Option[String] = None, + /* Link to a resource */ + scaOAuth: Option[String] = None, + /* 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 */ + startAuthorisationWithEncryptedPsuAuthentication: Option[String] = None, + /* Link to a resource */ + startAuthorisationWithAuthenticationMethodSelection: Option[String] = None, + /* Link to a resource */ + startAuthorisationWithTransactionAuthorisation: Option[String] = None, + /* Link to a resource */ + self: Option[String] = None, + /* Link to a resource */ + status: Option[String] = None, + /* Link to a resource */ + scaStatus: Option[String] = 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..1a2cbcd67a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksDownload.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 LinksDownload ( + /* Link to a resource */ + download: String +) 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..42dd8d927f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksPaymentInitiation.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 + + + +case class LinksPaymentInitiation ( + /* Link to a resource */ + scaRedirect: Option[String] = None, + /* Link to a resource */ + scaOAuth: Option[String] = None, + /* 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 */ + startAuthorisationWithEncryptedPsuAuthentication: Option[String] = None, + /* Link to a resource */ + startAuthorisationWithAuthenticationMethodSelection: Option[String] = None, + /* Link to a resource */ + startAuthorisationWithTransactionAuthorisation: Option[String] = None, + /* Link to a resource */ + self: Option[String] = None, + /* Link to a resource */ + status: Option[String] = None, + /* Link to a resource */ + scaStatus: Option[String] = 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..e13a73b805 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksPaymentInitiationCancel.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 LinksPaymentInitiationCancel ( + /* 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 */ + startAuthorisationWithEncryptedPsuAuthentication: Option[String] = None, + /* Link to a resource */ + startAuthorisationWithAuthenticationMethodSelection: Option[String] = 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..f73a623822 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksSelectPsuAuthenticationMethod.scala @@ -0,0 +1,30 @@ +/** + * 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 LinksSelectPsuAuthenticationMethod ( + /* Link to a resource */ + scaRedirect: Option[String] = None, + /* Link to a resource */ + scaOAuth: Option[String] = None, + /* Link to a resource */ + updatePsuIdentification: Option[String] = None, + /* Link to a resource */ + updatePsuAuthentication: Option[String] = None, + /* Link to a resource */ + authoriseTransaction: Option[String] = None, + /* Link to a resource */ + scaStatus: Option[String] = 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..1ab1c28049 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksSigningBasket.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 + + + +case class LinksSigningBasket ( + /* Link to a resource */ + scaRedirect: Option[String] = None, + /* Link to a resource */ + scaOAuth: Option[String] = None, + /* 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 */ + startAuthorisationWithEncryptedPsuAuthentication: Option[String] = None, + /* Link to a resource */ + startAuthorisationWithAuthenticationMethodSelection: Option[String] = None, + /* Link to a resource */ + startAuthorisationWithTransactionAuthorisation: Option[String] = None, + /* Link to a resource */ + self: Option[String] = None, + /* Link to a resource */ + status: Option[String] = None, + /* Link to a resource */ + scaStatus: Option[String] = 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..dad1700e68 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksStartScaProcess.scala @@ -0,0 +1,34 @@ +/** + * 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 LinksStartScaProcess ( + /* Link to a resource */ + scaRedirect: Option[String] = None, + /* Link to a resource */ + scaOAuth: Option[String] = None, + /* Link to a resource */ + updatePsuIdentification: Option[String] = None, + /* Link to a resource */ + startAuthorisationWithPsuAuthentication: Option[String] = None, + /* Link to a resource */ + startAuthorisationWithEncryptedPsuAuthentication: Option[String] = None, + /* Link to a resource */ + selectAuthenticationMethod: Option[String] = None, + /* Link to a resource */ + authoriseTransaction: Option[String] = None, + /* Link to a resource */ + scaStatus: Option[String] = 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..b6586129a5 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksTransactionDetails.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 LinksTransactionDetails ( + /* Link to a resource */ + transactionDetails: String +) 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..f418a3b1b0 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksUpdatePsuAuthentication.scala @@ -0,0 +1,24 @@ +/** + * 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 LinksUpdatePsuAuthentication ( + /* Link to a resource */ + selectAuthenticationMethod: Option[String] = None, + /* Link to a resource */ + authoriseTransaction: Option[String] = None, + /* Link to a resource */ + scaStatus: Option[String] = 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..e1911c13e1 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksUpdatePsuIdentification.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 LinksUpdatePsuIdentification ( + /* Link to a resource */ + scaStatus: Option[String] = None +) 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..e3827a096b --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode2XX.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 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..400ff62e86 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400AIS.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 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..eda2b5724a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400PIIS.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 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..ec65ef6d9d --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400PIS.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 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/MessageCode401AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401AIS.scala new file mode 100644 index 0000000000..c56f56e3fb --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401AIS.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 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..f398f987d0 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401PIIS.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 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..a779d4595e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401PIS.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 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/MessageCode403AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403AIS.scala new file mode 100644 index 0000000000..e1fc5cfff1 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403AIS.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 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..cb19fa569a --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403PIIS.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 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..898ec6f754 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403PIS.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 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/MessageCode404AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404AIS.scala new file mode 100644 index 0000000000..93827dc3fd --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404AIS.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 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..590e1f3f25 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404PIIS.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 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..4ca78a5d18 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404PIS.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 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/MessageCode405AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405AIS.scala new file mode 100644 index 0000000000..fa837a8a8f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405AIS.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 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..7a45bf6982 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405PIIS.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 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..49538662ed --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405PIS.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 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..10f3bd6a3c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405PISCANC.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 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/MessageCode406AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode406AIS.scala new file mode 100644 index 0000000000..e8c4442319 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode406AIS.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 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..fa3ccbbbac --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409AIS.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 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..c48e5a2ced --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409PIIS.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 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..f1f2354ceb --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409PIS.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 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/MessageCode429AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode429AIS.scala new file mode 100644 index 0000000000..92e258267d --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode429AIS.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 MessageCode429AIS ( +) extends ApiModel + 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/PaymentInitiationCancelResponse204202.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCancelResponse204202.scala new file mode 100644 index 0000000000..140859673d --- /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/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..51d5f29393 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationStatusResponse200Json.scala @@ -0,0 +1,22 @@ +/** + * 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 PaymentInitiationStatusResponse200Json ( + transactionStatus: TransactionStatus +) 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/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/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/PeriodicPaymentInitiationXmlPart2StandingorderTypeJson.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationXmlPart2StandingorderTypeJson.scala new file mode 100644 index 0000000000..17d99844f5 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationXmlPart2StandingorderTypeJson.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 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 +) 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..e467b10b41 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PsuData.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 PsuData ( + /* Password */ + password: String +) 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..be458cff27 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PurposeCode.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 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..1dc9e7fad5 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadAccountBalanceResponse200.scala @@ -0,0 +1,21 @@ +/** + * 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 ReadAccountBalanceResponse200 ( + account: Option[AccountReference] = None, + /* A list of balances regarding this account, e.g. the current balance, the last booked balance. The list migght be restricted to the current ballance. */ + balances: Seq[Balance] +) 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..4e21fd49d6 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadCardAccountBalanceResponse200.scala @@ -0,0 +1,21 @@ +/** + * 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 ReadCardAccountBalanceResponse200 ( + cardAccount: Option[AccountReference] = None, + /* A list of balances regarding this account, e.g. the current balance, the last booked balance. The list migght be restricted to the current ballance. */ + balances: Seq[Balance] +) 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..d55a404502 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/RemittanceInformationStructured.scala @@ -0,0 +1,21 @@ +/** + * 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 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/ScaStatus.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ScaStatus.scala new file mode 100644 index 0000000000..ccee8122ab --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ScaStatus.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 ScaStatus ( +) 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..cf5ee9f3e3 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ScaStatusResponse.scala @@ -0,0 +1,22 @@ +/** + * 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 ScaStatusResponse ( + scaStatus: Option[ScaStatus] = 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..25a29e8949 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SelectPsuAuthenticationMethod.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 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..d1283bba93 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SelectPsuAuthenticationMethodResponse.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 SelectPsuAuthenticationMethodResponse ( + 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/SigningBasket.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasket.scala new file mode 100644 index 0000000000..6a8bc077b1 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasket.scala @@ -0,0 +1,22 @@ +/** + * 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 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..f9e02164a5 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasketResponse200.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 SigningBasketResponse200 ( + /* A list of paymentIds */ + payments: Option[Seq[String]] = None, + /* A list of consentIds */ + consents: Option[Seq[String]] = None, + transactionStatus: TransactionStatus +) 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..7aec66d4ba --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasketResponse201.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 SigningBasketResponse201 ( + transactionStatus: TransactionStatus, + /* 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 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: 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..ae559b2544 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/SigningBasketStatusResponse200.scala @@ -0,0 +1,22 @@ +/** + * 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 SigningBasketStatusResponse200 ( + transactionStatus: TransactionStatusSB +) extends ApiModel + +object SigningBasketStatusResponse200Enums { + +} 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..e58206d138 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/StartScaprocessResponse.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 StartScaprocessResponse ( + scaStatus: ScaStatus, + /* 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: 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/TppMessage2XX.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage2XX.scala new file mode 100644 index 0000000000..b8ab040a10 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage2XX.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 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..0c25d4447f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400AIS.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 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..191834b10f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400PIIS.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 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..6bf2813b54 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400PIS.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 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/TppMessage401AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401AIS.scala new file mode 100644 index 0000000000..e6c3e432fa --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401AIS.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 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..38d47c5e05 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401PIIS.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 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..cb42f6bd51 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401PIS.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 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/TppMessage403AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403AIS.scala new file mode 100644 index 0000000000..42e8e3691b --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403AIS.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 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..7f74f09f85 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403PIIS.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 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..f1f8c36906 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403PIS.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 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/TppMessage404AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404AIS.scala new file mode 100644 index 0000000000..4c558f68ce --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404AIS.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 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..497888fe4e --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404PIIS.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 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..08c0bbb460 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404PIS.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 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/TppMessage405AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405AIS.scala new file mode 100644 index 0000000000..50b6e6b38d --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405AIS.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 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..c176024c91 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405PIIS.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 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..9dc8309cfb --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405PIS.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 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..5e2b876698 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405PISCANC.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 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/TppMessage406AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage406AIS.scala new file mode 100644 index 0000000000..d370148d11 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage406AIS.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 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..e0f9501a88 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409AIS.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 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..2c52e14ac3 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409PIIS.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 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..6eaa725066 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409PIS.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 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/TppMessage429AIS.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage429AIS.scala new file mode 100644 index 0000000000..873668d684 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage429AIS.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 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..76d479d2a4 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessageCategory.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 TppMessageCategory ( +) extends ApiModel + 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..a520cf6260 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionAuthorisation.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 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..83ef147cf5 --- /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/TransactionStatus.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionStatus.scala new file mode 100644 index 0000000000..a43b945d0f --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionStatus.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 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/TransactionsResponse200Json.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionsResponse200Json.scala new file mode 100644 index 0000000000..b90b995309 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionsResponse200Json.scala @@ -0,0 +1,23 @@ +/** + * 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 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 migght be restricted to the current ballance. */ + 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..5ea168ca7c --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePaymentPsuData200Response.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 UpdatePaymentPsuData200Response ( + links: LinksSelectPsuAuthenticationMethod, + scaStatus: ScaStatus, + /* Text to be displayed to the PSU */ + psuMessage: Option[String] = 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 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 +) 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..840394f5be --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePaymentPsuDataRequest.scala @@ -0,0 +1,23 @@ +/** + * 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 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 +) 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..f28a0dadbf --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuAuthentication.scala @@ -0,0 +1,19 @@ +/** + * 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 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..58eba43a97 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuAuthenticationResponse.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 UpdatePsuAuthenticationResponse ( + 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 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, + links: Option[LinksUpdatePsuAuthentication] = None, + scaStatus: ScaStatus, + /* Text to be displayed to the PSU */ + psuMessage: 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/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 From bc89e1c78034d2102a39c61b32740848b49dc194 Mon Sep 17 00:00:00 2001 From: hongwei Date: Tue, 6 Feb 2024 17:39:04 +0100 Subject: [PATCH 05/28] feature/BG1.3.12 seperate startPaymentAuthorisation endpoints to three --- .../berlin/group/v1_3/CommonServicesApi.scala | 8 +- .../v1_3/PaymentInitiationServicePISApi.scala | 160 ++++++++++++++++-- .../main/scala/code/snippet/PaymentOTP.scala | 4 +- .../PaymentInitiationServicePISApiTest.scala | 2 +- 4 files changed, 155 insertions(+), 19 deletions(-) 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..8edee1adf0 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,7 +30,9 @@ object APIMethods_CommonServicesApi extends RestHelper { APIMethods_PaymentInitiationServicePISApi.getPaymentCancellationScaStatus :: APIMethods_PaymentInitiationServicePISApi.getPaymentInitiationAuthorisation :: APIMethods_PaymentInitiationServicePISApi.getPaymentInitiationScaStatus :: - APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisation :: + APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationUpdatePsuAuthentication :: + APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationTransactionAuthorisation :: + APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationSelectPsuAuthenticationMethod :: APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisation :: APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuData :: APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuData :: @@ -49,7 +51,9 @@ 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.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.startPaymentInitiationCancellationAuthorisation).head resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuData).head resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuData).head 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 4af1f0b279..a3dc4ea9b8 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 @@ -8,6 +8,7 @@ import code.api.util.ApiTag._ import code.api.util.ErrorMessages._ import code.api.util.NewStyle.HttpCode 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._ @@ -23,6 +24,7 @@ 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 @@ -55,7 +57,9 @@ object APIMethods_PaymentInitiationServicePISApi extends RestHelper { initiatePayments :: initiateBulkPayments :: initiatePeriodicPayments :: - startPaymentAuthorisation :: + startPaymentAuthorisationUpdatePsuAuthentication :: + startPaymentAuthorisationTransactionAuthorisation :: + startPaymentAuthorisationSelectPsuAuthenticationMethod :: startPaymentInitiationCancellationAuthorisation :: updatePaymentCancellationPsuData :: updatePaymentPsuData :: @@ -736,15 +740,8 @@ Check the transaction status of a payment initiation.""", initiatePaymentImplementation("bulk-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)} + + val generalStartPaymentAuthorisationSummary = s"""${mockedDataText(false)} Create an authorisation sub-resource and start the authorisation process. The message might in addition transmit authentication and authorisation related data. @@ -777,8 +774,17 @@ 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, + UpdatePsuAuthentication(PsuData("password")), json.parse("""{ "challengeData": { "scaStatus": "received", @@ -793,8 +799,73 @@ 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 -> _ => { + def checkUpdatePsuAuthentication(JsonPost: JValue) = tryo { + JsonPost.extract[UpdatePsuAuthentication] + }.isDefined + + lazy val startPaymentAuthorisationUpdatePsuAuthentication : OBPEndpoint = { + case paymentService :: paymentProduct :: paymentId :: "authorisations" :: Nil JsonPost json -> _ if checkUpdatePsuAuthentication(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) + } + } + } + + resourceDocs += ResourceDoc( + startPaymentAuthorisationSelectPsuAuthenticationMethod, + apiVersion, + nameOf(startPaymentAuthorisationSelectPsuAuthenticationMethod), + "POST", + "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations", + "Start the authorisation process for a payment initiation (selectPsuAuthenticationMethod)", + generalStartPaymentAuthorisationSummary, + SelectPsuAuthenticationMethod("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 + ) + + def checkSelectPsuAuthenticationMethod(JsonPost: JValue) = tryo { + JsonPost.extract[SelectPsuAuthenticationMethod] + }.isDefined + + lazy val startPaymentAuthorisationSelectPsuAuthenticationMethod : OBPEndpoint = { + case paymentService :: paymentProduct :: paymentId :: "authorisations" :: Nil JsonPost json -> _ if checkSelectPsuAuthenticationMethod(json) => { cc => for { (Full(u), callContext) <- authenticatedAccess(cc) @@ -827,6 +898,67 @@ This applies in the following scenarios: } } + resourceDocs += ResourceDoc( + startPaymentAuthorisationTransactionAuthorisation, + apiVersion, + nameOf(startPaymentAuthorisationTransactionAuthorisation), + "POST", + "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations", + "Start the authorisation process for a payment initiation (transactionAuthorisation)", + generalStartPaymentAuthorisationSummary, + TransactionAuthorisation("scaAuthenticationData"), + 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 + ) + + def checkTransactionAuthorisation(JsonPost: JValue) = tryo { + JsonPost.extract[TransactionAuthorisation] + }.isDefined + + 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), callContext) + } + } + } + resourceDocs += ResourceDoc( startPaymentInitiationCancellationAuthorisation, apiVersion, diff --git a/obp-api/src/main/scala/code/snippet/PaymentOTP.scala b/obp-api/src/main/scala/code/snippet/PaymentOTP.scala index 993e20d429..77126b8b9e 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, updatePaymentPsuData} 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 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 1a5eb46670..76ffd1dd1f 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 @@ -28,7 +28,7 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with 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 startPaymentAuthorisation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationUpdatePsuAuthentication)) object getPaymentInitiationAuthorisation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.getPaymentInitiationAuthorisation)) object getPaymentInitiationScaStatus extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.getPaymentInitiationScaStatus)) object updatePaymentPsuData extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuData)) From ca6d69924bfb6bbdf265379397bfae3f0b3f00d3 Mon Sep 17 00:00:00 2001 From: hongwei Date: Wed, 7 Feb 2024 23:24:23 +0100 Subject: [PATCH 06/28] feature/BG1.3.12 seperate updatePaymentCancellationPsuData endpoints to 4 endpoints --- .../berlin/group/v1_3/CommonServicesApi.scala | 10 +- .../v1_3/JSONFactory_BERLIN_GROUP_1_3.scala | 16 +- .../v1_3/PaymentInitiationServicePISApi.scala | 208 ++++++++++++++---- .../model/AuthorisationConfirmation.scala | 18 ++ .../AuthorisationConfirmationResponse.scala | 19 ++ .../berlin/group/v1_3/model/HrefType.scala | 18 ++ .../LinksAuthorisationConfirmation.scala | 17 ++ .../model/LinksUpdatePsuAuthentication.scala | 2 + .../api/berlin/group/v1_3/model/PsuData.scala | 9 +- .../UpdatePsuAuthenticationResponse.scala | 26 ++- .../PaymentInitiationServicePISApiTest.scala | 4 +- 11 files changed, 297 insertions(+), 50 deletions(-) create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthorisationConfirmation.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthorisationConfirmationResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/HrefType.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAuthorisationConfirmation.scala 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 8edee1adf0..b96d7f5460 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 @@ -34,7 +34,10 @@ object APIMethods_CommonServicesApi extends RestHelper { APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationTransactionAuthorisation :: APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationSelectPsuAuthenticationMethod :: APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisation :: - APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuData :: + APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataUpdatePsuAuthentication :: + APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataTransactionAuthorisation :: + APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod :: + APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataAuthorisationConfirmation :: APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuData :: APIMethods_AccountInformationServiceAISApi.startConsentAuthorisation :: APIMethods_AccountInformationServiceAISApi.updateConsentsPsuData :: @@ -55,7 +58,10 @@ object APIMethods_CommonServicesApi extends RestHelper { 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.startPaymentInitiationCancellationAuthorisation).head - resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuData).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.updatePaymentPsuData).head resourceDocs += APIMethods_AccountInformationServiceAISApi.resourceDocs.filter(_.partialFunction == APIMethods_AccountInformationServiceAISApi.startConsentAuthorisation ).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 0b6a3e9a9a..93b99bcc44 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 @@ -13,7 +14,6 @@ import com.openbankproject.commons.model.{BankAccount, TransactionRequest, User, 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) @@ -634,4 +634,18 @@ object JSONFactory_BERLIN_GROUP_1_3 extends CustomJsonFormats { _links = ScaStatusJsonV13(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(Some(s"/v1.3/${paymentService}/${paymentProduct}/${paymentId}/cancellation-authorisations/${challenge.challengeId}"))) + ) + } } 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 a3dc4ea9b8..3a5e791744 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 @@ -61,7 +61,10 @@ object APIMethods_PaymentInitiationServicePISApi extends RestHelper { startPaymentAuthorisationTransactionAuthorisation :: startPaymentAuthorisationSelectPsuAuthenticationMethod :: startPaymentInitiationCancellationAuthorisation :: - updatePaymentCancellationPsuData :: + updatePaymentCancellationPsuDataUpdatePsuAuthentication :: + updatePaymentCancellationPsuDataTransactionAuthorisation :: + updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod :: + updatePaymentCancellationPsuDataAuthorisationConfirmation :: updatePaymentPsuData :: Nil @@ -1044,7 +1047,7 @@ This applies in the following scenarios: challenges.head } } yield { - (JSONFactory_BERLIN_GROUP_1_3.createStartPaymentCancellationAuthorisationJson( + (JSONFactory_BERLIN_GROUP_1_3.createStartPaymentInitiationCancellationAuthorisation( challenge, paymentService, paymentProduct, @@ -1053,15 +1056,9 @@ This applies in the following scenarios: } } } - - resourceDocs += ResourceDoc( - updatePaymentCancellationPsuData, - apiVersion, - nameOf(updatePaymentCancellationPsuData), - "PUT", - "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations/CANCELLATIONID", - "Update PSU Data for payment initiation cancellation", - s"""${mockedDataText(false)} + + 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. @@ -1074,17 +1071,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: @@ -1092,17 +1089,26 @@ 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", @@ -1115,16 +1121,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) { @@ -1146,8 +1152,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 ) @@ -1173,7 +1179,131 @@ There are the following request types on this access path: ), callContext) } } - } + } + + resourceDocs += ResourceDoc( + updatePaymentCancellationPsuDataUpdatePsuAuthentication, + apiVersion, + nameOf(updatePaymentCancellationPsuDataUpdatePsuAuthentication), + "PUT", + "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations/AUTHORISATION_ID", + "Update PSU Data for payment initiation cancellation (updatePsuAuthentication)", + generalUpdatePaymentCancellationPsuDataSummary(true), + UpdatePsuAuthentication(PsuData("password")), + json.parse("""{ + "scaStatus": "psuAuthenticated", + _links: { + "authoriseTransaction": {"href": "/psd2/v1/payments/1234-wertiq-983/authorisations/123auth456"} + } + }""").extract[UpdatePsuAuthenticationResponse], + 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/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), + SelectPsuAuthenticationMethod("authenticationMethodId"), + 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"} + } + }""").extract[SelectPsuAuthenticationMethodResponse], + 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/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), + AuthorisationConfirmation("authenticationMethodId"), + json.parse("""{ + "scaStatus": "finalised", + "_links":{ + "status": {"href":"/v1/payments/sepa-credit-transfers/qwer3456tzui7890/status"} + } + }""").extract[AuthorisationConfirmationResponse], + List(UserNotLoggedIn, UnknownError), + ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil + ) + + def checkAuthorisationConfirmation(JsonPost: JValue) = tryo { + JsonPost.extract[AuthorisationConfirmation] + }.isDefined + + 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/payments/sepa-credit-transfers/qwer3456tzui7890/status"} + } + }"""), callContext) + } + } + } resourceDocs += ResourceDoc( updatePaymentPsuData, 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..33058052e8 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthorisationConfirmation.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 AuthorisationConfirmation ( + /* An identification provided by the ASPSP for the later identification of the authentication method selection. */ + 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..41951a5f37 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AuthorisationConfirmationResponse.scala @@ -0,0 +1,19 @@ +/** + * 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 AuthorisationConfirmationResponse ( + _links: LinksAuthorisationConfirmation, + scaStatus: String, + /* Text to be displayed to the PSU */ + psuMessage: Option[String] = None +) 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..2d2e3469ed --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/HrefType.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 HrefType ( + /* Link to a resource */ + href: String +) 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..8d3e839220 --- /dev/null +++ b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksAuthorisationConfirmation.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 + +case class LinksAuthorisationConfirmation ( + scaStatus: Option[HrefType] = None +) 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 index f418a3b1b0..80289fac11 100644 --- 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 @@ -15,6 +15,8 @@ package code.api.berlin.group.v1_3.model case class LinksUpdatePsuAuthentication ( /* Link to a resource */ + updateAdditionalPsuAuthentication: Option[String] = None, + updateAdditionalEncryptedPsuAuthentication: Option[String] = None, selectAuthenticationMethod: Option[String] = None, /* Link to a resource */ authoriseTransaction: Option[String] = None, 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 index e467b10b41..2b33612ea1 100644 --- 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 @@ -15,6 +15,13 @@ package code.api.berlin.group.v1_3.model case class PsuData ( /* Password */ - password: String + 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/UpdatePsuAuthenticationResponse.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuAuthenticationResponse.scala index 58eba43a97..140b901157 100644 --- 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 @@ -11,19 +11,35 @@ */ package code.api.berlin.group.v1_3.model +import com.openbankproject.commons.util.{EnumValue, OBPEnumeration} 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 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, - links: Option[LinksUpdatePsuAuthentication] = None, - scaStatus: ScaStatus, + _links: Option[LinksUpdatePsuAuthentication] = None, + scaStatus: String, /* Text to be displayed to the PSU */ - psuMessage: Option[String] = None + psuMessage: Option[String] = None, + authorisationId: Option[String] = None ) extends ApiModel -object UpdatePsuAuthenticationResponseEnums { -} +sealed trait AccountAttributeType extends EnumValue +object AccountAttributeType extends OBPEnumeration[AccountAttributeType]{ + object RECEIVED extends Value + object PSUIDENTIFIED extends Value + object PSUAUTHENTICATED extends Value + object SCAMETHODSELECTED extends Value + object STARTED extends Value + object UNCONFIRMED extends Value + object FINALISED extends Value + object FAILED extends Value + object EXEMPTED extends Value +} \ 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 76ffd1dd1f..5a5ea4f27c 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 @@ -38,7 +38,7 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with object startPaymentInitiationCancellationAuthorisation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisation)) 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 updatePaymentCancellationPsuData extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataUpdatePsuAuthentication)) feature(s"test the BG v1.3 -${initiatePayment.name}") { scenario("Failed Case - Wrong Json format Body", BerlinGroupV1_3, PIS, initiatePayment) { @@ -476,7 +476,7 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with Then(s"We can test the ${updatePaymentCancellationPsuData.name}") val updatePaymentCancellationPsuDataJsonBody = APIMethods_PaymentInitiationServicePISApi .resourceDocs - .filter( _.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuData) + .filter( _.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataUpdatePsuAuthentication) .head.exampleRequestBody.asInstanceOf[JvalueCaseClass] //All the Json String convert to JvalueCaseClass implicitly .jvalueToCaseclass From 1a8b8dc5f38dc2604bd563a72136579d31e92b94 Mon Sep 17 00:00:00 2001 From: hongwei Date: Thu, 8 Feb 2024 07:55:55 +0100 Subject: [PATCH 07/28] feature/BG1.3.12 update the models --- .../v1_3/JSONFactory_BERLIN_GROUP_1_3.scala | 4 +- .../v1_3/PaymentInitiationServicePISApi.scala | 18 ++-- .../group/v1_3/model/AccountAccess.scala | 32 +++++-- .../group/v1_3/model/AccountDetails.scala | 30 +++--- .../berlin/group/v1_3/model/AccountList.scala | 6 +- .../group/v1_3/model/AccountOwner.scala | 22 +++++ .../group/v1_3/model/AccountReference.scala | 19 ++-- .../group/v1_3/model/AccountReport.scala | 16 ++-- .../group/v1_3/model/AccountStatus.scala | 6 +- .../model/AdditionalInformationAccess.scala | 22 +++++ .../AdditionalInformationStructured.scala | 19 ++++ .../api/berlin/group/v1_3/model/Address.scala | 14 +-- .../api/berlin/group/v1_3/model/Amount.scala | 8 +- .../v1_3/model/AuthenticationObject.scala | 6 +- .../group/v1_3/model/AuthenticationType.scala | 6 +- .../model/AuthorisationConfirmation.scala | 10 +- .../AuthorisationConfirmationResponse.scala | 18 ++-- .../group/v1_3/model/Authorisations.scala | 8 +- .../api/berlin/group/v1_3/model/Balance.scala | 12 ++- .../berlin/group/v1_3/model/BalanceType.scala | 6 +- .../model/BulkPaymentInitiationJson.scala | 27 ++++++ ...kPaymentInitiationWithStatusResponse.scala | 34 +++++++ .../group/v1_3/model/CardAccountDetails.scala | 28 +++--- .../group/v1_3/model/CardAccountList.scala | 6 +- .../group/v1_3/model/CardAccountReport.scala | 12 +-- .../CardAccountsTransactionsResponse200.scala | 12 ++- .../group/v1_3/model/CardTransaction.scala | 28 ++++-- .../CardTransactionGrandTotalAmount.scala | 22 +++++ .../group/v1_3/model/ChallengeData.scala | 11 ++- .../group/v1_3/model/ChargeBearer.scala | 18 ++++ .../CheckAvailabilityOfFunds200Response.scala | 7 +- .../v1_3/model/ConfirmationOfFunds.scala | 8 +- .../ConsentInformationResponse200Json.scala | 13 +-- .../group/v1_3/model/ConsentStatus.scala | 6 +- .../v1_3/model/ConsentStatusResponse200.scala | 10 +- .../berlin/group/v1_3/model/Consents.scala | 10 +- .../v1_3/model/ConsentsResponse201.scala | 14 +-- .../group/v1_3/model/DayOfExecution.scala | 6 +- .../v1_3/model/EntryDetailsElement.scala | 54 +++++++++++ .../berlin/group/v1_3/model/Error400AIS.scala | 8 +- .../Error400AISAdditionalErrorsInner.scala | 6 +- .../group/v1_3/model/Error400NGAIS.scala | 8 +- .../group/v1_3/model/Error400NGPIIS.scala | 8 +- .../group/v1_3/model/Error400NGPIS.scala | 8 +- .../group/v1_3/model/Error400NGSB.scala | 2 +- .../group/v1_3/model/Error400NGSBS.scala | 20 ++++ .../group/v1_3/model/Error400PIIS.scala | 8 +- .../Error400PIISAdditionalErrorsInner.scala | 6 +- .../berlin/group/v1_3/model/Error400PIS.scala | 8 +- .../Error400PISAdditionalErrorsInner.scala | 6 +- .../berlin/group/v1_3/model/Error400SB.scala | 2 +- .../berlin/group/v1_3/model/Error400SBS.scala | 32 +++++++ .../Error400SBSAdditionalErrorsInner.scala | 26 +++++ .../berlin/group/v1_3/model/Error401AIS.scala | 8 +- .../Error401AISAdditionalErrorsInner.scala | 6 +- .../group/v1_3/model/Error401NGAIS.scala | 8 +- .../group/v1_3/model/Error401NGPIIS.scala | 8 +- .../group/v1_3/model/Error401NGPIS.scala | 8 +- .../group/v1_3/model/Error401NGSB.scala | 2 +- .../group/v1_3/model/Error401NGSBS.scala | 20 ++++ .../group/v1_3/model/Error401PIIS.scala | 8 +- .../Error401PIISAdditionalErrorsInner.scala | 6 +- .../berlin/group/v1_3/model/Error401PIS.scala | 8 +- .../Error401PISAdditionalErrorsInner.scala | 6 +- .../berlin/group/v1_3/model/Error401SB.scala | 2 +- .../berlin/group/v1_3/model/Error401SBS.scala | 32 +++++++ .../Error401SBSAdditionalErrorsInner.scala | 26 +++++ .../berlin/group/v1_3/model/Error403AIS.scala | 8 +- .../Error403AISAdditionalErrorsInner.scala | 6 +- .../group/v1_3/model/Error403NGAIS.scala | 8 +- .../group/v1_3/model/Error403NGPIIS.scala | 8 +- .../group/v1_3/model/Error403NGPIS.scala | 8 +- .../group/v1_3/model/Error403NGSB.scala | 2 +- .../group/v1_3/model/Error403NGSBS.scala | 20 ++++ .../group/v1_3/model/Error403PIIS.scala | 8 +- .../Error403PIISAdditionalErrorsInner.scala | 6 +- .../berlin/group/v1_3/model/Error403PIS.scala | 8 +- .../Error403PISAdditionalErrorsInner.scala | 6 +- .../berlin/group/v1_3/model/Error403SB.scala | 2 +- .../berlin/group/v1_3/model/Error403SBS.scala | 32 +++++++ .../Error403SBSAdditionalErrorsInner.scala | 26 +++++ .../berlin/group/v1_3/model/Error404AIS.scala | 8 +- .../Error404AISAdditionalErrorsInner.scala | 6 +- .../group/v1_3/model/Error404NGAIS.scala | 8 +- .../group/v1_3/model/Error404NGPIIS.scala | 8 +- .../group/v1_3/model/Error404NGPIS.scala | 8 +- .../group/v1_3/model/Error404NGSB.scala | 2 +- .../group/v1_3/model/Error404NGSBS.scala | 20 ++++ .../group/v1_3/model/Error404PIIS.scala | 8 +- .../Error404PIISAdditionalErrorsInner.scala | 6 +- .../berlin/group/v1_3/model/Error404PIS.scala | 8 +- .../Error404PISAdditionalErrorsInner.scala | 6 +- .../berlin/group/v1_3/model/Error404SB.scala | 2 +- .../berlin/group/v1_3/model/Error404SBS.scala | 32 +++++++ .../Error404SBSAdditionalErrorsInner.scala | 26 +++++ .../berlin/group/v1_3/model/Error405AIS.scala | 8 +- .../Error405AISAdditionalErrorsInner.scala | 6 +- .../group/v1_3/model/Error405NGAIS.scala | 8 +- .../group/v1_3/model/Error405NGPIIS.scala | 8 +- .../group/v1_3/model/Error405NGPIS.scala | 8 +- .../group/v1_3/model/Error405NGPISCANC.scala | 8 +- .../group/v1_3/model/Error405NGSB.scala | 2 +- .../group/v1_3/model/Error405NGSBS.scala | 20 ++++ .../group/v1_3/model/Error405PIIS.scala | 8 +- .../Error405PIISAdditionalErrorsInner.scala | 6 +- .../berlin/group/v1_3/model/Error405PIS.scala | 8 +- .../Error405PISAdditionalErrorsInner.scala | 6 +- .../group/v1_3/model/Error405PISCANC.scala | 8 +- ...Error405PISCANCAdditionalErrorsInner.scala | 6 +- .../berlin/group/v1_3/model/Error405SB.scala | 2 +- .../berlin/group/v1_3/model/Error405SBS.scala | 32 +++++++ .../Error405SBSAdditionalErrorsInner.scala | 26 +++++ .../berlin/group/v1_3/model/Error406AIS.scala | 8 +- .../Error406AISAdditionalErrorsInner.scala | 6 +- .../group/v1_3/model/Error406NGAIS.scala | 8 +- .../berlin/group/v1_3/model/Error409AIS.scala | 8 +- .../Error409AISAdditionalErrorsInner.scala | 6 +- .../group/v1_3/model/Error409NGAIS.scala | 8 +- .../group/v1_3/model/Error409NGPIIS.scala | 8 +- .../group/v1_3/model/Error409NGPIS.scala | 8 +- .../group/v1_3/model/Error409NGSB.scala | 2 +- .../group/v1_3/model/Error409NGSBS.scala | 20 ++++ .../group/v1_3/model/Error409PIIS.scala | 8 +- .../Error409PIISAdditionalErrorsInner.scala | 6 +- .../berlin/group/v1_3/model/Error409PIS.scala | 8 +- .../Error409PISAdditionalErrorsInner.scala | 6 +- .../berlin/group/v1_3/model/Error409SB.scala | 2 +- .../berlin/group/v1_3/model/Error409SBS.scala | 32 +++++++ .../Error409SBSAdditionalErrorsInner.scala | 26 +++++ .../berlin/group/v1_3/model/Error429AIS.scala | 8 +- .../Error429AISAdditionalErrorsInner.scala | 6 +- .../group/v1_3/model/Error429NGAIS.scala | 8 +- .../group/v1_3/model/ExecutionRule.scala | 6 +- .../group/v1_3/model/FrequencyCode.scala | 6 +- .../GetPaymentInformation200Response.scala | 20 ++-- .../GetTransactionDetails200Response.scala | 19 ++++ .../model/GetTransactionList200Response.scala | 6 +- .../GetTransactionList200Response1.scala | 6 +- .../berlin/group/v1_3/model/HrefType.scala | 12 ++- .../v1_3/model/InitiatePaymentRequest.scala | 21 ++-- .../v1_3/model/InitiatePaymentRequest1.scala | 6 +- .../v1_3/model/LinksAccountDetails.scala | 12 +-- .../group/v1_3/model/LinksAccountReport.scala | 21 ++-- .../berlin/group/v1_3/model/LinksAll.scala | 96 +++++++------------ .../LinksAuthorisationConfirmation.scala | 8 +- .../v1_3/model/LinksCardAccountReport.scala | 22 ++--- .../group/v1_3/model/LinksConsents.scala | 40 +++----- .../group/v1_3/model/LinksDownload.scala | 9 +- .../group/v1_3/model/LinksGetConsent.scala | 20 ++++ .../v1_3/model/LinksPaymentInitiation.scala | 40 +++----- .../model/LinksPaymentInitiationCancel.scala | 21 ++-- .../LinksSelectPsuAuthenticationMethod.scala | 27 +++--- .../group/v1_3/model/LinksSigningBasket.scala | 39 +++----- .../v1_3/model/LinksStartScaProcess.scala | 31 +++--- .../v1_3/model/LinksTransactionDetails.scala | 9 +- .../model/LinksUpdatePsuAuthentication.scala | 19 ++-- .../model/LinksUpdatePsuIdentification.scala | 10 +- .../MessageCode200InitiationStatus.scala | 18 ++++ .../MessageCode201PaymentInitiation.scala | 18 ++++ .../group/v1_3/model/MessageCode2XX.scala | 6 +- .../group/v1_3/model/MessageCode400AIS.scala | 6 +- .../group/v1_3/model/MessageCode400PIIS.scala | 6 +- .../group/v1_3/model/MessageCode400PIS.scala | 6 +- .../group/v1_3/model/MessageCode400SBS.scala | 18 ++++ .../group/v1_3/model/MessageCode401AIS.scala | 6 +- .../group/v1_3/model/MessageCode401PIIS.scala | 6 +- .../group/v1_3/model/MessageCode401PIS.scala | 6 +- .../group/v1_3/model/MessageCode401SBS.scala | 18 ++++ .../group/v1_3/model/MessageCode403AIS.scala | 6 +- .../group/v1_3/model/MessageCode403PIIS.scala | 6 +- .../group/v1_3/model/MessageCode403PIS.scala | 6 +- .../group/v1_3/model/MessageCode403SBS.scala | 18 ++++ .../group/v1_3/model/MessageCode404AIS.scala | 6 +- .../group/v1_3/model/MessageCode404PIIS.scala | 6 +- .../group/v1_3/model/MessageCode404PIS.scala | 6 +- .../group/v1_3/model/MessageCode404SBS.scala | 18 ++++ .../group/v1_3/model/MessageCode405AIS.scala | 6 +- .../group/v1_3/model/MessageCode405PIIS.scala | 6 +- .../group/v1_3/model/MessageCode405PIS.scala | 6 +- .../v1_3/model/MessageCode405PISCANC.scala | 6 +- .../group/v1_3/model/MessageCode405SBS.scala | 18 ++++ .../group/v1_3/model/MessageCode406AIS.scala | 6 +- .../group/v1_3/model/MessageCode409AIS.scala | 6 +- .../group/v1_3/model/MessageCode409PIIS.scala | 6 +- .../group/v1_3/model/MessageCode409PIS.scala | 6 +- .../group/v1_3/model/MessageCode409SBS.scala | 18 ++++ .../group/v1_3/model/MessageCode429AIS.scala | 6 +- .../berlin/group/v1_3/model/OtherType.scala | 26 +++++ .../v1_3/model/PaymentExchangeRate.scala | 33 +++++++ .../PaymentInitiationBulkElementJson.scala | 30 ++++++ .../PaymentInitiationCancelResponse202.scala | 27 ++++++ ...aymentInitiationCancelResponse204202.scala | 2 +- .../v1_3/model/PaymentInitiationJson.scala | 31 ++++++ .../PaymentInitiationRequestResponse201.scala | 38 ++++++++ ...ymentInitiationStatusResponse200Json.scala | 20 +++- .../PaymentInitiationWithStatusResponse.scala | 35 +++++++ .../model/PeriodicPaymentInitiationJson.scala | 42 ++++++++ ...cPaymentInitiationWithStatusResponse.scala | 43 +++++++++ ...tiationXmlPart2StandingorderTypeJson.scala | 12 ++- .../api/berlin/group/v1_3/model/PsuData.scala | 21 ++-- .../berlin/group/v1_3/model/PurposeCode.scala | 6 +- .../model/ReadAccountBalanceResponse200.scala | 8 +- .../model/ReadAccountDetails200Response.scala | 19 ++++ .../ReadCardAccountBalanceResponse200.scala | 10 +- .../ReadCardAccountDetails200Response.scala | 19 ++++ .../RemittanceInformationStructured.scala | 6 +- .../group/v1_3/model/ReportExchangeRate.scala | 28 ++++++ .../berlin/group/v1_3/model/ScaStatus.scala | 6 +- .../ScaStatusAuthorisationConfirmation.scala | 18 ++++ .../group/v1_3/model/ScaStatusResponse.scala | 17 +++- .../model/SelectPsuAuthenticationMethod.scala | 6 +- ...electPsuAuthenticationMethodResponse.scala | 14 ++- .../group/v1_3/model/ServiceLevelCode.scala | 18 ++++ .../group/v1_3/model/SigningBasket.scala | 10 +- .../v1_3/model/SigningBasketResponse200.scala | 13 +-- .../v1_3/model/SigningBasketResponse201.scala | 12 +-- .../SigningBasketStatusResponse200.scala | 8 +- .../v1_3/model/StandingOrderDetails.scala | 37 +++++++ .../StartPaymentAuthorisationRequest.scala | 23 +++++ .../v1_3/model/StartScaprocessResponse.scala | 12 ++- .../TppMessage201PaymentInitiation.scala | 26 +++++ .../group/v1_3/model/TppMessage2XX.scala | 6 +- .../group/v1_3/model/TppMessage400AIS.scala | 6 +- .../group/v1_3/model/TppMessage400PIIS.scala | 6 +- .../group/v1_3/model/TppMessage400PIS.scala | 6 +- .../group/v1_3/model/TppMessage400SBS.scala | 26 +++++ .../group/v1_3/model/TppMessage401AIS.scala | 6 +- .../group/v1_3/model/TppMessage401PIIS.scala | 6 +- .../group/v1_3/model/TppMessage401PIS.scala | 6 +- .../group/v1_3/model/TppMessage401SBS.scala | 26 +++++ .../group/v1_3/model/TppMessage403AIS.scala | 6 +- .../group/v1_3/model/TppMessage403PIIS.scala | 6 +- .../group/v1_3/model/TppMessage403PIS.scala | 6 +- .../group/v1_3/model/TppMessage403SBS.scala | 26 +++++ .../group/v1_3/model/TppMessage404AIS.scala | 6 +- .../group/v1_3/model/TppMessage404PIIS.scala | 6 +- .../group/v1_3/model/TppMessage404PIS.scala | 6 +- .../group/v1_3/model/TppMessage404SBS.scala | 26 +++++ .../group/v1_3/model/TppMessage405AIS.scala | 6 +- .../group/v1_3/model/TppMessage405PIIS.scala | 6 +- .../group/v1_3/model/TppMessage405PIS.scala | 6 +- .../v1_3/model/TppMessage405PISCANC.scala | 6 +- .../group/v1_3/model/TppMessage405SBS.scala | 26 +++++ .../group/v1_3/model/TppMessage406AIS.scala | 6 +- .../group/v1_3/model/TppMessage409AIS.scala | 6 +- .../group/v1_3/model/TppMessage409PIIS.scala | 6 +- .../group/v1_3/model/TppMessage409PIS.scala | 6 +- .../group/v1_3/model/TppMessage409SBS.scala | 26 +++++ .../group/v1_3/model/TppMessage429AIS.scala | 6 +- .../group/v1_3/model/TppMessageCategory.scala | 6 +- .../group/v1_3/model/TppMessageGeneric.scala | 27 ++++++ ...ppMessageInitiationStatusResponse200.scala | 26 +++++ .../v1_3/model/TransactionAuthorisation.scala | 6 +- .../group/v1_3/model/TransactionDetails.scala | 2 +- .../v1_3/model/TransactionDetailsBody.scala | 19 ++++ .../group/v1_3/model/TransactionStatus.scala | 6 +- .../v1_3/model/TransactionStatusSBS.scala | 18 ++++ .../group/v1_3/model/Transactions.scala | 79 +++++++++++++++ .../model/TransactionsResponse200Json.scala | 10 +- .../UpdatePaymentPsuData200Response.scala | 28 ++++-- .../model/UpdatePaymentPsuDataRequest.scala | 10 +- .../v1_3/model/UpdatePsuAuthentication.scala | 6 +- .../UpdatePsuAuthenticationResponse.scala | 26 ++--- .../UpdatePsuIdentificationResponse.scala | 31 ++++++ 264 files changed, 2684 insertions(+), 944 deletions(-) create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AccountOwner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AdditionalInformationAccess.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/AdditionalInformationStructured.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/BulkPaymentInitiationWithStatusResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/CardTransactionGrandTotalAmount.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ChargeBearer.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/EntryDetailsElement.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400NGSBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error400SBSAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401NGSBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error401SBSAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403NGSBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error403SBSAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404NGSBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error404SBSAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405NGSBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error405SBSAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409NGSBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Error409SBSAdditionalErrorsInner.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/GetTransactionDetails200Response.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksGetConsent.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode200InitiationStatus.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode201PaymentInitiation.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode400SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode401SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode403SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode404SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode405SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/MessageCode409SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/OtherType.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentExchangeRate.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationBulkElementJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationCancelResponse202.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationRequestResponse201.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationWithStatusResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationJson.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PeriodicPaymentInitiationWithStatusResponse.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadAccountDetails200Response.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReadCardAccountDetails200Response.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ReportExchangeRate.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ScaStatusAuthorisationConfirmation.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/ServiceLevelCode.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/StandingOrderDetails.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/StartPaymentAuthorisationRequest.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage201PaymentInitiation.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage400SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage401SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage403SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage404SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage405SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessage409SBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessageGeneric.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TppMessageInitiationStatusResponse200.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionDetailsBody.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/TransactionStatusSBS.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/Transactions.scala create mode 100644 obp-api/src/main/scala/code/api/berlin/group/v1_3/model/UpdatePsuIdentificationResponse.scala 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 93b99bcc44..f8eade19b0 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 @@ -645,7 +645,9 @@ object JSONFactory_BERLIN_GROUP_1_3 extends CustomJsonFormats { scaStatus = challenge.scaStatus.map(_.toString).getOrElse(""), authorisationId = Some(challenge.challengeId), psuMessage = Some("Please check your SMS at a mobile device."), - _links = Some(LinksUpdatePsuAuthentication(Some(s"/v1.3/${paymentService}/${paymentProduct}/${paymentId}/cancellation-authorisations/${challenge.challengeId}"))) + _links = Some(LinksUpdatePsuAuthentication( + scaStatus = Some(HrefType(Some(s"/v1.3/${paymentService}/${paymentProduct}/${paymentId}/cancellation-authorisations/${challenge.challengeId}")))) + ) ) } } 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 3a5e791744..77e0f38074 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 @@ -787,7 +787,7 @@ This applies in the following scenarios: "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations", "Start the authorisation process for a payment initiation (updatePsuAuthentication)", generalStartPaymentAuthorisationSummary, - UpdatePsuAuthentication(PsuData("password")), + UpdatePsuAuthentication(PsuData(password = Some("password"))), json.parse("""{ "challengeData": { "scaStatus": "received", @@ -1189,13 +1189,13 @@ There are the following request types on this access path: "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations/AUTHORISATION_ID", "Update PSU Data for payment initiation cancellation (updatePsuAuthentication)", generalUpdatePaymentCancellationPsuDataSummary(true), - UpdatePsuAuthentication(PsuData("password")), + UpdatePsuAuthentication(PsuData(Some("password"))), json.parse("""{ "scaStatus": "psuAuthenticated", - _links: { + "_links": { "authoriseTransaction": {"href": "/psd2/v1/payments/1234-wertiq-983/authorisations/123auth456"} } - }""").extract[UpdatePsuAuthenticationResponse], + }"""), List(UserNotLoggedIn, UnknownError), ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil ) @@ -1209,7 +1209,7 @@ There are the following request types on this access path: (net.liftweb.json.parse( """{ "scaStatus": "psuAuthenticated", - _links: { + "_links": { "authoriseTransaction": {"href": "/psd2/v1/payments/1234-wertiq-983/authorisations/123auth456"} } }"""), callContext) @@ -1232,12 +1232,12 @@ There are the following request types on this access path: "authenticationType": "SMS_OTP", "authenticationMethodId": "myAuthenticationID"}, "challengeData": { - "otpMaxLength": "6", + "otpMaxLength": 6, "otpFormat": "integer"}, "_links": { "authoriseTransaction": {"href": "/psd2/v1/payments/1234-wertiq-983/authorisations/123auth456"} } - }""").extract[SelectPsuAuthenticationMethodResponse], + }"""), List(UserNotLoggedIn, UnknownError), ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil ) @@ -1255,7 +1255,7 @@ There are the following request types on this access path: "authenticationType": "SMS_OTP", "authenticationMethodId": "myAuthenticationID"}, "challengeData": { - "otpMaxLength": "6", + "otpMaxLength": 6, "otpFormat": "integer"}, "_links": { "authoriseTransaction": {"href": "/psd2/v1/payments/1234-wertiq-983/authorisations/123auth456"} @@ -1279,7 +1279,7 @@ There are the following request types on this access path: "_links":{ "status": {"href":"/v1/payments/sepa-credit-transfers/qwer3456tzui7890/status"} } - }""").extract[AuthorisationConfirmationResponse], + }"""), List(UserNotLoggedIn, UnknownError), ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil ) 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 index b7d1f624a9..bde7cd561f 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,29 +14,41 @@ package code.api.berlin.group.v1_3.model case class AccountAccess ( - /* Is asking for detailed account information. If the array is empty, 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 or transactions shall be empty, if used. */ + /* 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, 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 or transactions shall be empty, if used. */ + /* 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, 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 or balances shall be empty, if used. */ + /* 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, - /* Optional if supported by API provider. Only the values \"allAccounts\" or \"allAccountsWithBalances\" is admitted. */ + 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. Only the value \"allAccounts\" is admitted. */ - allPsd2: Option[AccountAccessEnums.AllPsd2] = 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 AllAccountsWithBalances = Value("allAccountsWithBalances") + 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 index b5fc3926e9..0bddb81125 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -16,16 +16,24 @@ 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 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. */ + /* 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 */ + /* ISO 4217 Alpha 3 currency code. */ currency: String, - /* Name of the account given by the bank or the PSU in online-banking. */ + /* 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. */ @@ -35,13 +43,13 @@ case class AccountDetails ( 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 */ + /* 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 */ + /* 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 migght be restricted to the current ballance. */ + /* 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 + _links: Option[LinksAccountDetails] = None ) extends ApiModel object AccountDetailsEnums { 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 index ff64886471..d78328fd0f 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index faaff4de58..6a6cf44202 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,17 +14,20 @@ package code.api.berlin.group.v1_3.model case class AccountReference ( - /* IBAN of an account */ + /* 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. */ + /* 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 */ + /* Masked Primary Account Number. */ maskedPan: Option[String] = None, /* Mobile phone number. */ msisdn: Option[String] = None, - /* ISO 4217 Alpha 3 currency code */ - currency: 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 index 95955c1698..2271b65d82 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,10 +14,12 @@ package code.api.berlin.group.v1_3.model case class AccountReport ( - /* Array of transaction details */ - booked: Option[Seq[TransactionDetails]] = None, - /* Array of transaction details */ - pending: Option[Seq[TransactionDetails]] = None, + /* 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 index 0fc66c3071..776aea5904 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 479684c361..ebd0eba13a 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,11 +14,11 @@ package code.api.berlin.group.v1_3.model case class Address ( - street: Option[String] = None, + streetName: Option[String] = None, buildingNumber: Option[String] = None, - city: Option[String] = None, - postalCode: Option[String] = None, - /* ISO 3166 ALPHA2 country code */ + 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 index db4f0829be..2d3a37d01e 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,7 +14,7 @@ package code.api.berlin.group.v1_3.model case class Amount ( - /* ISO 4217 Alpha 3 currency code */ + /* 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 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 index 3469775a5a..7095c111ac 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index f148a5b4cd..bbf9f85088 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 33058052e8..2adaca6b3f 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -11,8 +11,10 @@ */ package code.api.berlin.group.v1_3.model + + case class AuthorisationConfirmation ( - /* An identification provided by the ASPSP for the later identification of the authentication method selection. */ + /* 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 index 41951a5f37..c6fe65cfa9 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -11,9 +11,15 @@ */ package code.api.berlin.group.v1_3.model + + case class AuthorisationConfirmationResponse ( - _links: LinksAuthorisationConfirmation, - scaStatus: String, - /* Text to be displayed to the PSU */ + 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 index e79dc02bdc..835ba69558 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,7 +14,7 @@ package code.api.berlin.group.v1_3.model case class Authorisations ( - /* An array of all authorisationIds */ + /* 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 index fc2f8061e7..996dfb800a 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -18,11 +18,13 @@ 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, - /* Reference date of the balance */ + /* Indicates the date of the balance. */ referenceDate: Option[LocalDate] = None, - /* \"entryReference\" of the last commited transaction to support the TPP in identifying whether all PSU transactions are already known. */ + /* \"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 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 index 6d491bc590..d5477a6f76 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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/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 index a42d30ba61..8fe6066482 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -16,23 +16,29 @@ 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 */ + /* Masked Primary Account Number. */ maskedPan: String, - /* ISO 4217 Alpha 3 currency code */ + /* ISO 4217 Alpha 3 currency code. */ currency: String, - /* Name of the account given by the bank or the PSU in online-banking. */ + /* 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, - /* Product name of the bank for this account, proprietary definition. */ + /* 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 */ + /* 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 */ + /* 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 migght be restricted to the current ballance. */ + /* 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 + _links: Option[LinksAccountDetails] = None ) extends ApiModel object CardAccountDetailsEnums { 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 index 34cba451f2..fc3f832cf0 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index efdbc63ef2..fe78abe566 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,9 +14,9 @@ package code.api.berlin.group.v1_3.model case class CardAccountReport ( - /* Array of transaction details */ - booked: Seq[CardTransaction], - /* Array of transaction details */ + /* 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 index a1aa32824e..c6823f9898 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,9 +15,11 @@ 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 migght be restricted to the current ballance. */ + /* 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 + _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 index 3e35378851..94a91c3e41 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -12,6 +12,7 @@ package code.api.berlin.group.v1_3.model import java.time.LocalDate +import java.time.OffsetDateTime case class CardTransaction ( @@ -19,21 +20,28 @@ case class CardTransaction ( cardTransactionId: Option[String] = None, /* Identification of the Terminal, where the card has been used. */ terminalId: Option[String] = None, - /* Date of the actual card transaction */ + /* Date of the actual card transaction. */ transactionDate: Option[LocalDate] = None, - /* The Date when an entry is posted to an account on the ASPSPs books. */ + /* 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, - /* Array of exchange rates */ - exchangeRate: Option[Seq[ExchangeRate]] = None, + 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, - /* Card Acceptor Category Code of the Card Acceptor as given in the related card transaction. */ - cardAcceptorCategoryCode: Option[String] = None, - /* Masked Primary Account Number */ + /* 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, 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 index 16e670301c..9121ffe5de 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -12,11 +12,12 @@ 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, - /* String challenge data */ - data: Option[String] = 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. */ 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 index 7ff1631af9..0e522f3981 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,6 +14,7 @@ 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 index 6b27b98ff0..c055853640 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -17,7 +17,7 @@ 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 */ + /* 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 index a034e8bc9a..d76af42b41 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -18,13 +18,14 @@ 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 requesting a valid until 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. */ + /* 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\". */ + /* 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 + 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 index fb37b32802..e1bc72f5eb 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 5ccc3c6a9c..820187815b 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,7 +14,9 @@ package code.api.berlin.group.v1_3.model case class ConsentStatusResponse200 ( - consentStatus: ConsentStatus + 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 index fe0dd33a84..8ab02b790c 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -18,9 +18,9 @@ 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 requesting a valid until 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. */ + /* 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\". */ + /* 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 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 index ab9972637e..ad09853427 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,15 +15,15 @@ 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. */ + /* 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 an hyperlink of type 'startAuthorisationWithAuthenticationMethodSelection' contained in the response body. These methods shall be presented towards the PSU for selection by the TPP. */ + /* 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, e.g. in a Decoupled SCA Approach. */ - message: Option[String] = None + /* 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 index fc974d9fc6..fc28dfb4c9 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 66a6ba8f85..10bac123da 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error400AIS ( 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 + _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 index e07c8ea864..1c2a29fed3 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index d0e5ad0bb6..efe1dc39d5 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error400NGAIS ( tppMessages: Option[Seq[TppMessage400AIS]] = None, - links: Option[LinksAll] = 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 index 39a9ddeb59..8acb87bc52 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error400NGPIIS ( tppMessages: Option[Seq[TppMessage400PIIS]] = None, - links: Option[LinksAll] = 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 index e08cbf34dd..9ceed6273e 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error400NGPIS ( tppMessages: Option[Seq[TppMessage400PIS]] = None, - links: Option[LinksAll] = 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 index 1a474e88c2..551bce142e 100644 --- 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 @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error400NGSB ( tppMessages: Option[Seq[TppMessage400SB]] = None, - links: Option[LinksAll] = 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 index 151e158f93..c593fc1d42 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error400PIIS ( 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 + _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 index 3ae1eb8309..4bc3963782 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index db35bacbca..f27781f05a 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error400PIS ( 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 + _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 index e9660ce83e..524024d158 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 2f8318e1f4..3a0a4055e2 100644 --- 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 @@ -24,7 +24,7 @@ case class Error400SB ( 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 + _links: Option[LinksAll] = None ) extends ApiModel object Error400SBEnums { 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 index 0941fa83f5..d131603a9d 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error401AIS ( 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 + _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 index 593c09c159..45e6441c4c 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index a52003a878..407bbfd0c2 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error401NGAIS ( tppMessages: Option[Seq[TppMessage401AIS]] = None, - links: Option[LinksAll] = 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 index f3f18efa51..c4855e6474 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error401NGPIIS ( tppMessages: Option[Seq[TppMessage401PIIS]] = None, - links: Option[LinksAll] = 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 index e1e77b1593..2124155a3a 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error401NGPIS ( tppMessages: Option[Seq[TppMessage401PIS]] = None, - links: Option[LinksAll] = 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 index ef1daccf2b..33d40bd369 100644 --- 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 @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error401NGSB ( tppMessages: Option[Seq[TppMessage401SB]] = None, - links: Option[LinksAll] = 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 index d13e28e586..a7dd82e3a6 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error401PIIS ( 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 + _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 index a9fd6b7b3d..a5432d7df7 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 2605088111..fd3d8e1870 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error401PIS ( 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 + _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 index 21f930cef5..4b24e7fc83 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 40c23dea38..132e2f5d7b 100644 --- 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 @@ -24,7 +24,7 @@ case class Error401SB ( 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 + _links: Option[LinksAll] = None ) extends ApiModel object Error401SBEnums { 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 index 7743b673cc..6b87a08cf9 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error403AIS ( 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 + _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 index 0a06bce6dd..34333e6678 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 4462c46c83..91d0e2a5ab 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error403NGAIS ( tppMessages: Option[Seq[TppMessage403AIS]] = None, - links: Option[LinksAll] = 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 index 432eb3d235..799ff2414c 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error403NGPIIS ( tppMessages: Option[Seq[TppMessage403PIIS]] = None, - links: Option[LinksAll] = 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 index 90093811ad..9d6ebe709e 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error403NGPIS ( tppMessages: Option[Seq[TppMessage403PIS]] = None, - links: Option[LinksAll] = 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 index 34ce6109e9..cb49ebb94d 100644 --- 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 @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error403NGSB ( tppMessages: Option[Seq[TppMessage403SB]] = None, - links: Option[LinksAll] = 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 index 9a2fdf3cda..d2b7ca0507 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error403PIIS ( 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 + _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 index 80b2611238..7a7b040a11 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 94f6c2ceb6..8de1cc3042 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error403PIS ( 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 + _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 index 560daee361..5f8ed3dfac 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index e2fc2b46bd..33766c57dd 100644 --- 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 @@ -24,7 +24,7 @@ case class Error403SB ( 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 + _links: Option[LinksAll] = None ) extends ApiModel object Error403SBEnums { 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 index f15c0b5c46..5f487c2ca9 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error404AIS ( 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 + _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 index cfd4148ee2..0f8b7b717a 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 1acb3257df..3ccdcee138 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error404NGAIS ( tppMessages: Option[Seq[TppMessage404AIS]] = None, - links: Option[LinksAll] = 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 index 59b69a1712..c9571523a2 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error404NGPIIS ( tppMessages: Option[Seq[TppMessage404PIIS]] = None, - links: Option[LinksAll] = 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 index ec07e5fed4..69bc2ab81a 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error404NGPIS ( tppMessages: Option[Seq[TppMessage404PIS]] = None, - links: Option[LinksAll] = 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 index 424c06d9d9..f5707d8e4c 100644 --- 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 @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error404NGSB ( tppMessages: Option[Seq[TppMessage404SB]] = None, - links: Option[LinksAll] = 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 index 4e34bf60e1..5c05e52e45 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error404PIIS ( 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 + _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 index c0d8f44c6c..5e9c458ac2 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 41e717504f..01cccca0c9 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error404PIS ( 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 + _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 index fef5a16a20..b6feccd2a9 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 875c04f2b5..55d808ddd1 100644 --- 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 @@ -24,7 +24,7 @@ case class Error404SB ( 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 + _links: Option[LinksAll] = None ) extends ApiModel object Error404SBEnums { 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 index 6eee277eab..3e34afa8d1 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error405AIS ( 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 + _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 index b2bfd0bf84..ff5ebb2fe4 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 99c7da5959..9d976362ea 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error405NGAIS ( tppMessages: Option[Seq[TppMessage405AIS]] = None, - links: Option[LinksAll] = 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 index cbc7728682..5d05c87ee5 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error405NGPIIS ( tppMessages: Option[Seq[TppMessage405PIIS]] = None, - links: Option[LinksAll] = 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 index 4d353d7709..30fb777977 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error405NGPIS ( tppMessages: Option[Seq[TppMessage405PIS]] = None, - links: Option[LinksAll] = 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 index 4c8f25a09e..9778bb18eb 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error405NGPISCANC ( tppMessages: Option[Seq[TppMessage405PISCANC]] = None, - links: Option[LinksAll] = 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 index a9ba399ba4..b3840f8b4b 100644 --- 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 @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error405NGSB ( tppMessages: Option[Seq[TppMessage405SB]] = None, - links: Option[LinksAll] = 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 index 18141909c0..e01de17a61 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error405PIIS ( 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 + _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 index f099a5d0de..8d64a92476 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 332f0ec5af..75402fdec3 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error405PIS ( 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 + _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 index abd1bc8a47..fd59954439 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 50ea5cc851..83a80dcf47 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error405PISCANC ( 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 + _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 index 53c702b521..5802a09f57 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 601d37051f..799cc30ebc 100644 --- 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 @@ -24,7 +24,7 @@ case class Error405SB ( 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 + _links: Option[LinksAll] = None ) extends ApiModel object Error405SBEnums { 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 index 6841053975..5a6cdf51e6 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error406AIS ( 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 + _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 index ad2ff43623..4e879b9979 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 1d060b8794..354d7f25a6 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error406NGAIS ( tppMessages: Option[Seq[TppMessage406AIS]] = None, - links: Option[LinksAll] = 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 index 0a785a35b0..a69013717a 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error409AIS ( 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 + _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 index 1e9622987a..1d3d550a83 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 450c40650a..9dca575ba3 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error409NGAIS ( tppMessages: Option[Seq[TppMessage409AIS]] = None, - links: Option[LinksAll] = 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 index 63e0bf4402..2ccee38f24 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error409NGPIIS ( tppMessages: Option[Seq[TppMessage409PIIS]] = None, - links: Option[LinksAll] = 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 index 998af9c069..458c05b70a 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error409NGPIS ( tppMessages: Option[Seq[TppMessage409PIS]] = None, - links: Option[LinksAll] = 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 index b91aeb2567..3227e0178c 100644 --- 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 @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error409NGSB ( tppMessages: Option[Seq[TppMessage409SB]] = None, - links: Option[LinksAll] = 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 index b331f6df68..ae4da986aa 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error409PIIS ( 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 + _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 index 7e63581805..a1d6a39278 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 5d896f58fc..dc6175c331 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error409PIS ( 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 + _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 index b5170c7b85..9a02a9923d 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index be707ac73e..20766aab2a 100644 --- 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 @@ -24,7 +24,7 @@ case class Error409SB ( 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 + _links: Option[LinksAll] = None ) extends ApiModel object Error409SBEnums { 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 index da2d209f09..70f5be1cc6 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -24,7 +24,7 @@ case class Error429AIS ( 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 + _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 index 7147cd0577..8ed8f611f8 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 8a64fefd46..c8f0d8e6d4 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,6 +15,6 @@ package code.api.berlin.group.v1_3.model case class Error429NGAIS ( tppMessages: Option[Seq[TppMessage429AIS]] = None, - links: Option[LinksAll] = None + _links: Option[LinksAll] = 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 index 26271f70bf..9b3395d09e 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index a6ce7f09d0..bc48d94ba3 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index dbe1a15370..7ccc7e59bf 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -12,6 +12,7 @@ package code.api.berlin.group.v1_3.model import java.time.LocalDate +import java.time.OffsetDateTime case class GetPaymentInformation200Response ( @@ -21,14 +22,17 @@ case class GetPaymentInformation200Response ( creditorAccount: AccountReference, /* BICFI */ creditorAgent: Option[String] = None, - /* Creditor Name */ + /* 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. */ + /* 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, @@ -36,8 +40,10 @@ case class GetPaymentInformation200Response ( /* 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, - /* A list of JSON bodies for cross-border payments. */ - payments: Seq[PaymentInitiationCrossBorderJson] + 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 index 6c01fa790a..ab4053e644 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index e694e2242c..02ee211214 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 2d2e3469ed..297156f114 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -11,8 +11,10 @@ */ package code.api.berlin.group.v1_3.model + + case class HrefType ( - /* Link to a resource */ - href: String + /* 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/InitiatePaymentRequest.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/InitiatePaymentRequest.scala index 6a1755c2b6..5f96c1e086 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -12,6 +12,7 @@ package code.api.berlin.group.v1_3.model import java.time.LocalDate +import java.time.OffsetDateTime case class InitiatePaymentRequest ( @@ -21,22 +22,28 @@ case class InitiatePaymentRequest ( creditorAccount: AccountReference, /* BICFI */ creditorAgent: Option[String] = None, - /* Creditor Name */ + /* 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. */ + /* 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, - /* A List of JSON bodies for cross-border payments. */ - payments: Seq[PaymentInitiationCrossBorderBulkElementJson] + 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 index ca3700a8f2..52c1d1b2f8 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 5ea0da175c..f25fa3651c 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,9 +14,7 @@ package code.api.berlin.group.v1_3.model case class LinksAccountDetails ( - /* Link to a resource */ - balances: Option[String] = None, - /* Link to a resource */ - transactions: Option[String] = None + 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 index 9917ea6242..0c3bf1f3ce 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,15 +14,10 @@ package code.api.berlin.group.v1_3.model case class LinksAccountReport ( - /* Link to a resource */ - account: String, - /* Link to a resource */ - first: Option[String] = None, - /* Link to a resource */ - next: Option[String] = None, - /* Link to a resource */ - previous: Option[String] = None, - /* Link to a resource */ - last: Option[String] = None + 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 index 31af0a0f24..0cd24750b9 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,63 +14,37 @@ package code.api.berlin.group.v1_3.model case class LinksAll ( - /* Link to a resource */ - scaRedirect: Option[String] = None, - /* Link to a resource */ - scaOAuth: Option[String] = None, - /* Link to a resource */ - startAuthorisation: Option[String] = None, - /* Link to a resource */ - startAuthorisationWithPsuIdentification: Option[String] = None, - /* Link to a resource */ - updatePsuIdentification: Option[String] = None, - /* Link to a resource */ - startAuthorisationWithProprietaryData: Option[String] = None, - /* Link to a resource */ - updateProprietaryData: Option[String] = None, - /* Link to a resource */ - startAuthorisationWithPsuAuthentication: Option[String] = None, - /* Link to a resource */ - updatePsuAuthentication: Option[String] = None, - /* Link to a resource */ - startAuthorisationWithEncryptedPsuAuthentication: Option[String] = None, - /* Link to a resource */ - updateEncryptedPsuAuthentication: Option[String] = None, - /* Link to a resource */ - startAuthorisationWithAuthenticationMethodSelection: Option[String] = None, - /* Link to a resource */ - selectAuthenticationMethod: Option[String] = None, - /* Link to a resource */ - startAuthorisationWithTransactionAuthorisation: Option[String] = None, - /* Link to a resource */ - authoriseTransaction: Option[String] = None, - /* Link to a resource */ - self: Option[String] = None, - /* Link to a resource */ - status: Option[String] = None, - /* Link to a resource */ - scaStatus: Option[String] = None, - /* Link to a resource */ - account: Option[String] = None, - /* Link to a resource */ - balances: Option[String] = None, - /* Link to a resource */ - transactions: Option[String] = None, - /* Link to a resource */ - transactionDetails: Option[String] = None, - /* Link to a resource */ - cardAccount: Option[String] = None, - /* Link to a resource */ - cardTransactions: Option[String] = None, - /* Link to a resource */ - first: Option[String] = None, - /* Link to a resource */ - next: Option[String] = None, - /* Link to a resource */ - previous: Option[String] = None, - /* Link to a resource */ - last: Option[String] = None, - /* Link to a resource */ - download: Option[String] = None + 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 index 8d3e839220..7d55256fd5 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -11,6 +11,8 @@ */ 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 index 96481269e9..efd1b4e325 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,15 +14,11 @@ package code.api.berlin.group.v1_3.model case class LinksCardAccountReport ( - /* Link to a resource */ - cardAccount: String, - /* Link to a resource */ - first: Option[String] = None, - /* Link to a resource */ - next: Option[String] = None, - /* Link to a resource */ - previous: Option[String] = None, - /* Link to a resource */ - last: Option[String] = None + 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 index 61b1198abe..cf18a7a16f 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,27 +14,17 @@ package code.api.berlin.group.v1_3.model case class LinksConsents ( - /* Link to a resource */ - scaRedirect: Option[String] = None, - /* Link to a resource */ - scaOAuth: Option[String] = None, - /* 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 */ - startAuthorisationWithEncryptedPsuAuthentication: Option[String] = None, - /* Link to a resource */ - startAuthorisationWithAuthenticationMethodSelection: Option[String] = None, - /* Link to a resource */ - startAuthorisationWithTransactionAuthorisation: Option[String] = None, - /* Link to a resource */ - self: Option[String] = None, - /* Link to a resource */ - status: Option[String] = None, - /* Link to a resource */ - scaStatus: Option[String] = None + 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 index 1a2cbcd67a..e342f0fcb7 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,7 +14,6 @@ package code.api.berlin.group.v1_3.model case class LinksDownload ( - /* Link to a resource */ - download: String + 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 index 42dd8d927f..c07287943b 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,27 +14,17 @@ package code.api.berlin.group.v1_3.model case class LinksPaymentInitiation ( - /* Link to a resource */ - scaRedirect: Option[String] = None, - /* Link to a resource */ - scaOAuth: Option[String] = None, - /* 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 */ - startAuthorisationWithEncryptedPsuAuthentication: Option[String] = None, - /* Link to a resource */ - startAuthorisationWithAuthenticationMethodSelection: Option[String] = None, - /* Link to a resource */ - startAuthorisationWithTransactionAuthorisation: Option[String] = None, - /* Link to a resource */ - self: Option[String] = None, - /* Link to a resource */ - status: Option[String] = None, - /* Link to a resource */ - scaStatus: Option[String] = None + 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 index e13a73b805..55762151ea 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,15 +14,10 @@ package code.api.berlin.group.v1_3.model case class LinksPaymentInitiationCancel ( - /* 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 */ - startAuthorisationWithEncryptedPsuAuthentication: Option[String] = None, - /* Link to a resource */ - startAuthorisationWithAuthenticationMethodSelection: Option[String] = None + 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/LinksSelectPsuAuthenticationMethod.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/LinksSelectPsuAuthenticationMethod.scala index f73a623822..5e2608d84c 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,17 +14,14 @@ package code.api.berlin.group.v1_3.model case class LinksSelectPsuAuthenticationMethod ( - /* Link to a resource */ - scaRedirect: Option[String] = None, - /* Link to a resource */ - scaOAuth: Option[String] = None, - /* Link to a resource */ - updatePsuIdentification: Option[String] = None, - /* Link to a resource */ - updatePsuAuthentication: Option[String] = None, - /* Link to a resource */ - authoriseTransaction: Option[String] = None, - /* Link to a resource */ - scaStatus: Option[String] = None + 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 index 1ab1c28049..872c1abde8 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,27 +14,16 @@ package code.api.berlin.group.v1_3.model case class LinksSigningBasket ( - /* Link to a resource */ - scaRedirect: Option[String] = None, - /* Link to a resource */ - scaOAuth: Option[String] = None, - /* 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 */ - startAuthorisationWithEncryptedPsuAuthentication: Option[String] = None, - /* Link to a resource */ - startAuthorisationWithAuthenticationMethodSelection: Option[String] = None, - /* Link to a resource */ - startAuthorisationWithTransactionAuthorisation: Option[String] = None, - /* Link to a resource */ - self: Option[String] = None, - /* Link to a resource */ - status: Option[String] = None, - /* Link to a resource */ - scaStatus: Option[String] = None + 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 index dad1700e68..54ada32ce3 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,21 +14,14 @@ package code.api.berlin.group.v1_3.model case class LinksStartScaProcess ( - /* Link to a resource */ - scaRedirect: Option[String] = None, - /* Link to a resource */ - scaOAuth: Option[String] = None, - /* Link to a resource */ - updatePsuIdentification: Option[String] = None, - /* Link to a resource */ - startAuthorisationWithPsuAuthentication: Option[String] = None, - /* Link to a resource */ - startAuthorisationWithEncryptedPsuAuthentication: Option[String] = None, - /* Link to a resource */ - selectAuthenticationMethod: Option[String] = None, - /* Link to a resource */ - authoriseTransaction: Option[String] = None, - /* Link to a resource */ - scaStatus: Option[String] = None + 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 index b6586129a5..4930ddd227 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,7 +14,6 @@ package code.api.berlin.group.v1_3.model case class LinksTransactionDetails ( - /* Link to a resource */ - transactionDetails: String + 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 index 80289fac11..d07984785e 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,13 +14,10 @@ package code.api.berlin.group.v1_3.model case class LinksUpdatePsuAuthentication ( - /* Link to a resource */ - updateAdditionalPsuAuthentication: Option[String] = None, - updateAdditionalEncryptedPsuAuthentication: Option[String] = None, - selectAuthenticationMethod: Option[String] = None, - /* Link to a resource */ - authoriseTransaction: Option[String] = None, - /* Link to a resource */ - scaStatus: Option[String] = None + 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 index e1911c13e1..7098d007fd 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,7 +14,7 @@ package code.api.berlin.group.v1_3.model case class LinksUpdatePsuIdentification ( - /* Link to a resource */ - scaStatus: Option[String] = None + 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 index e3827a096b..76bf720abb 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 400ff62e86..7f4cb42943 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index eda2b5724a..78e37123b6 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index ec65ef6d9d..be2f041d6d 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index c56f56e3fb..7411c8844c 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index f398f987d0..4a2f998e74 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index a779d4595e..5266963c17 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index e1fc5cfff1..358c8bf280 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index cb19fa569a..eaaa87f24b 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 898ec6f754..24f157e16f 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 93827dc3fd..076de9ffe1 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 590e1f3f25..9ad5edcebe 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 4ca78a5d18..44ebe4b0d5 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index fa837a8a8f..0960578189 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 7a45bf6982..a37df32f2a 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 49538662ed..9cee5f94ed 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 10f3bd6a3c..85eec67aa7 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index e8c4442319..477168a589 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index fa3ccbbbac..edd4130967 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index c48e5a2ced..9120292a6f 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index f1f2354ceb..7d22e1bc26 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 92e258267d..85c316c993 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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/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 index 140859673d..218c8578f6 100644 --- 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 @@ -19,7 +19,7 @@ case class PaymentInitiationCancelResponse204202 ( scaMethods: Option[Seq[AuthenticationObject]] = None, chosenScaMethod: Option[AuthenticationObject] = None, challengeData: Option[ChallengeData] = None, - links: Option[LinksPaymentInitiationCancel] = None + _links: Option[LinksPaymentInitiationCancel] = None ) extends ApiModel object PaymentInitiationCancelResponse204202Enums { 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/PaymentInitiationStatusResponse200Json.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/model/PaymentInitiationStatusResponse200Json.scala index 51d5f29393..ac2ed44ea5 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,7 +14,19 @@ package code.api.berlin.group.v1_3.model case class PaymentInitiationStatusResponse200Json ( - transactionStatus: TransactionStatus + 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/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/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/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 index 17d99844f5..c5031acad6 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -17,11 +17,13 @@ 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. */ + /* 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 + 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 index 2b33612ea1..631664743e 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,14 +14,13 @@ package code.api.berlin.group.v1_3.model case class PsuData ( - /* Password */ - password: String, -// Encrypted password. + /* Password. */ + password: Option[String] = None, + /* Encrypted password. */ encryptedPassword: Option[String] = None, -// Additional password in plaintext. - additionalPassword: Option[String]= None, -// Additional encrypted password. - additionalEncryptedPassword: 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 index be458cff27..0be7f2782c 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 1dc9e7fad5..915785dbe3 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,7 +15,7 @@ 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 migght be restricted to the current ballance. */ + /* 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 index 4e21fd49d6..5445cb45bb 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,7 +15,9 @@ package code.api.berlin.group.v1_3.model case class ReadCardAccountBalanceResponse200 ( cardAccount: Option[AccountReference] = None, - /* A list of balances regarding this account, e.g. the current balance, the last booked balance. The list migght be restricted to the current ballance. */ + /* 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 index d55a404502..0d84d89b2d 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index ccee8122ab..b1e8a0e6ad 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index cf5ee9f3e3..d65196819a 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,7 +14,16 @@ package code.api.berlin.group.v1_3.model case class ScaStatusResponse ( - scaStatus: Option[ScaStatus] = None + scaStatus: ScaStatus, + /* 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 index 25a29e8949..ce5a9e9f76 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index d1283bba93..12b444ee5c 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,11 +14,15 @@ 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, + _links: Option[LinksSelectPsuAuthenticationMethod] = None, scaStatus: ScaStatus, - /* Text to be displayed to the PSU */ + /* Text to be displayed to the PSU. */ psuMessage: Option[String] = None ) extends ApiModel 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 index 6a8bc077b1..90ff73edd8 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,9 +14,9 @@ package code.api.berlin.group.v1_3.model case class SigningBasket ( - /* A list of paymentIds */ + /* A list of paymentIds. */ paymentIds: Option[Seq[String]] = None, - /* A list of consentIds */ + /* 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 index f9e02164a5..aa2947e7a3 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,11 +14,12 @@ package code.api.berlin.group.v1_3.model case class SigningBasketResponse200 ( - /* A list of paymentIds */ + /* A list of paymentIds. */ payments: Option[Seq[String]] = None, - /* A list of consentIds */ + /* A list of consentIds. */ consents: Option[Seq[String]] = None, - transactionStatus: TransactionStatus + 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 index 7aec66d4ba..2805b317b8 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,15 +14,15 @@ package code.api.berlin.group.v1_3.model case class SigningBasketResponse201 ( - transactionStatus: TransactionStatus, + 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 an hyperlink of type 'startAuthorisationWithAuthenticationMethodSelection' contained in the response body. These methods shall be presented towards the PSU for selection by the TPP. */ + /* 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 */ + /* Text to be displayed to the PSU. */ psuMessage: Option[String] = None, tppMessages: Option[Seq[TppMessage2XX]] = None ) extends ApiModel 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 index ae559b2544..c10bd8fd3f 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,7 +14,7 @@ package code.api.berlin.group.v1_3.model case class SigningBasketStatusResponse200 ( - transactionStatus: TransactionStatusSB + 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 index e58206d138..e4418d30a1 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -15,12 +15,14 @@ package code.api.berlin.group.v1_3.model case class StartScaprocessResponse ( scaStatus: ScaStatus, - /* 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. */ + /* 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 */ + /* Text to be displayed to the PSU. */ psuMessage: Option[String] = None ) extends ApiModel 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 index b8ab040a10..4c170705db 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 0c25d4447f..358b1289c7 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 191834b10f..caafa99de6 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 6bf2813b54..8cc6612852 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index e6c3e432fa..4bc43551c3 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 38d47c5e05..3389d0aacd 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index cb42f6bd51..aa0c3a6c34 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 42e8e3691b..67efc51249 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 7f74f09f85..e0dd761035 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index f1f8c36906..c10ed97bc5 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 4c558f68ce..2b32d9e817 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 497888fe4e..8ec506a49a 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 08c0bbb460..254378bad1 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 50b6e6b38d..ceef329a84 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index c176024c91..8d23b84c11 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 9dc8309cfb..a21acf4d63 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 5e2b876698..395920326f 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index d370148d11..01e7a65977 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index e0f9501a88..87d9115a04 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 2c52e14ac3..fd1bba3273 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 6eaa725066..b323f9132f 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 873668d684..11f22521a6 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 76d479d2a4..3f7f93328c 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index a520cf6260..c03886214c 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 83ef147cf5..a3afc1793b 100644 --- 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 @@ -52,7 +52,7 @@ case class TransactionDetails ( 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 + _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 index a43b945d0f..2b5291b68c 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index b90b995309..108fc0e97c 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -16,8 +16,8 @@ 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 migght be restricted to the current ballance. */ + /* 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 + _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 index 5ea168ca7c..2103010738 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -14,14 +14,26 @@ package code.api.berlin.group.v1_3.model case class UpdatePaymentPsuData200Response ( - links: LinksSelectPsuAuthenticationMethod, - scaStatus: ScaStatus, - /* Text to be displayed to the PSU */ + 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, - /* 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 + /* 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 index 840394f5be..00fdf15447 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -18,6 +18,8 @@ case class UpdatePaymentPsuDataRequest ( /* 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 + 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 index f28a0dadbf..f83f3db269 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). 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 index 140b901157..9a20748ce7 100644 --- 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 @@ -1,8 +1,8 @@ /** - * 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 + * 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 Dec 20th 2018 + * 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). @@ -11,7 +11,6 @@ */ package code.api.berlin.group.v1_3.model -import com.openbankproject.commons.util.{EnumValue, OBPEnumeration} case class UpdatePsuAuthenticationResponse ( @@ -21,25 +20,16 @@ case class UpdatePsuAuthenticationResponse ( 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 an hyperlink of type 'startAuthorisationWithAuthenticationMethodSelection' contained in the response body. These methods shall be presented towards the PSU for selection by the TPP. */ + /* 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 */ + /* 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 { -sealed trait AccountAttributeType extends EnumValue -object AccountAttributeType extends OBPEnumeration[AccountAttributeType]{ - object RECEIVED extends Value - object PSUIDENTIFIED extends Value - object PSUAUTHENTICATED extends Value - object SCAMETHODSELECTED extends Value - object STARTED extends Value - object UNCONFIRMED extends Value - object FINALISED extends Value - object FAILED extends Value - object EXEMPTED extends Value -} \ No newline at end of file +} 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 { + +} From e701adafbb2a539c5219f54ca4a970b666f8fc28 Mon Sep 17 00:00:00 2001 From: hongwei Date: Thu, 8 Feb 2024 08:07:47 +0100 Subject: [PATCH 08/28] feature/BG1.3.12 seperate startPaymentAuthorisation to 3 endpoints, tweaked the isMocked summary --- .../v1_3/PaymentInitiationServicePISApi.scala | 80 +++++++------------ 1 file changed, 27 insertions(+), 53 deletions(-) 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 77e0f38074..3e69a4fddf 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 @@ -744,7 +744,7 @@ Check the transaction status of a payment initiation.""", } } - val generalStartPaymentAuthorisationSummary = s"""${mockedDataText(false)} + 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. @@ -786,8 +786,8 @@ This applies in the following scenarios: "POST", "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations", "Start the authorisation process for a payment initiation (updatePsuAuthentication)", - generalStartPaymentAuthorisationSummary, - UpdatePsuAuthentication(PsuData(password = Some("password"))), + generalStartPaymentAuthorisationSummary(false), + UpdatePsuAuthentication(PsuData(password = Some(""))), json.parse("""{ "challengeData": { "scaStatus": "received", @@ -847,7 +847,7 @@ This applies in the following scenarios: "POST", "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations", "Start the authorisation process for a payment initiation (selectPsuAuthenticationMethod)", - generalStartPaymentAuthorisationSummary, + generalStartPaymentAuthorisationSummary(true), SelectPsuAuthenticationMethod("authenticationMethodId"), json.parse("""{ "challengeData": { @@ -872,31 +872,18 @@ This applies in the following scenarios: 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" + } + } + }"""), callContext) } } } @@ -908,7 +895,7 @@ This applies in the following scenarios: "POST", "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations", "Start the authorisation process for a payment initiation (transactionAuthorisation)", - generalStartPaymentAuthorisationSummary, + generalStartPaymentAuthorisationSummary(true), TransactionAuthorisation("scaAuthenticationData"), json.parse("""{ "challengeData": { @@ -933,31 +920,18 @@ This applies in the following scenarios: 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" + } + } + }"""), callContext) } } } From 379de54d0e4ae2c41087f079942f424effa54fd1 Mon Sep 17 00:00:00 2001 From: hongwei Date: Thu, 8 Feb 2024 08:51:40 +0100 Subject: [PATCH 09/28] feature/BGv1.3 tweaked updatePaymentPsuData to updatePaymentPsuDataTransactionAuthorisation --- .../berlin/group/v1_3/CommonServicesApi.scala | 4 +- .../v1_3/JSONFactory_BERLIN_GROUP_1_3.scala | 20 +++-- .../v1_3/PaymentInitiationServicePISApi.scala | 88 ++++++++++--------- .../group/v1_3/model/ScaStatusResponse.scala | 2 +- .../main/scala/code/snippet/PaymentOTP.scala | 4 +- .../PaymentInitiationServicePISApiTest.scala | 4 +- 6 files changed, 63 insertions(+), 59 deletions(-) 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 b96d7f5460..7fedfe32bf 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 @@ -38,7 +38,7 @@ object APIMethods_CommonServicesApi extends RestHelper { APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataTransactionAuthorisation :: APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod :: APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataAuthorisationConfirmation :: - APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuData :: + APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataTransactionAuthorisation :: APIMethods_AccountInformationServiceAISApi.startConsentAuthorisation :: APIMethods_AccountInformationServiceAISApi.updateConsentsPsuData :: APIMethods_AccountInformationServiceAISApi.getConsentScaStatus :: Nil @@ -62,7 +62,7 @@ object APIMethods_CommonServicesApi extends RestHelper { 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.updatePaymentPsuData).head + resourceDocs += APIMethods_PaymentInitiationServicePISApi.resourceDocs.filter(_.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataTransactionAuthorisation).head resourceDocs += APIMethods_AccountInformationServiceAISApi.resourceDocs.filter(_.partialFunction == APIMethods_AccountInformationServiceAISApi.startConsentAuthorisation ).head resourceDocs += APIMethods_AccountInformationServiceAISApi.resourceDocs.filter(_.partialFunction == APIMethods_AccountInformationServiceAISApi.updateConsentsPsuData ).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 f8eade19b0..da0f6b3dfe 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 @@ -616,23 +616,25 @@ 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( 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 3e69a4fddf..0861882ed8 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 @@ -65,7 +65,7 @@ object APIMethods_PaymentInitiationServicePISApi extends RestHelper { updatePaymentCancellationPsuDataTransactionAuthorisation :: updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod :: updatePaymentCancellationPsuDataAuthorisationConfirmation :: - updatePaymentPsuData :: + updatePaymentPsuDataTransactionAuthorisation :: Nil @@ -1086,7 +1086,6 @@ There are the following request types on this access path: 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" @@ -1278,15 +1277,10 @@ There are the following request types on this access path: } } } - - resourceDocs += ResourceDoc( - updatePaymentPsuData, - apiVersion, - nameOf(updatePaymentPsuData), - "PUT", - "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations/AUTHORISATION_ID", - "Update PSU data for payment initiation", - s"""${mockedDataText(false)} + + + 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. @@ -1297,17 +1291,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: @@ -1315,25 +1309,33 @@ 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" @@ -1343,17 +1345,17 @@ There are the following request types on this access path: 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("-","_")) } @@ -1371,7 +1373,7 @@ There are the following request types on this access path: Some(paymentId), None, authorisationid, - updatePaymentPsuDataJson.scaAuthenticationData, + transactionAuthorisationJson.scaAuthenticationData, callContext ) @@ -1392,7 +1394,7 @@ 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) } } } 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 index d65196819a..db13a76d36 100644 --- 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 @@ -14,7 +14,7 @@ package code.api.berlin.group.v1_3.model case class ScaStatusResponse ( - scaStatus: ScaStatus, + 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. */ diff --git a/obp-api/src/main/scala/code/snippet/PaymentOTP.scala b/obp-api/src/main/scala/code/snippet/PaymentOTP.scala index 77126b8b9e..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.{startPaymentAuthorisationUpdatePsuAuthentication, 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} @@ -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/PaymentInitiationServicePISApiTest.scala b/obp-api/src/test/scala/code/api/berlin/group/v1_3/PaymentInitiationServicePISApiTest.scala index 5a5ea4f27c..634d4844fe 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 @@ -31,7 +31,7 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with object startPaymentAuthorisation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationUpdatePsuAuthentication)) 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 updatePaymentPsuData extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataTransactionAuthorisation)) object cancelPayment extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.cancelPayment)) @@ -370,7 +370,7 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with Then(s"We can test the ${updatePaymentPsuData.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 From c7f707ca3611dc3e56b16af2eaca38ec0745b13d Mon Sep 17 00:00:00 2001 From: hongwei Date: Thu, 8 Feb 2024 09:22:10 +0100 Subject: [PATCH 10/28] feature/BG1.3.12 separate updatePaymentPsuData to 4 endpoints --- .../berlin/group/v1_3/CommonServicesApi.scala | 6 + .../v1_3/PaymentInitiationServicePISApi.scala | 130 +++++++++++++++++- 2 files changed, 135 insertions(+), 1 deletion(-) 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 7fedfe32bf..0631302b26 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 @@ -39,6 +39,9 @@ object APIMethods_CommonServicesApi extends RestHelper { APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod :: APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataAuthorisationConfirmation :: APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataTransactionAuthorisation :: + APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataAuthorisationConfirmation :: + APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataSelectPsuAuthenticationMethod :: + APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataAuthorisationConfirmation :: APIMethods_AccountInformationServiceAISApi.startConsentAuthorisation :: APIMethods_AccountInformationServiceAISApi.updateConsentsPsuData :: APIMethods_AccountInformationServiceAISApi.getConsentScaStatus :: Nil @@ -63,6 +66,9 @@ object APIMethods_CommonServicesApi extends RestHelper { 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 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 0861882ed8..b00bf092ef 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 @@ -66,6 +66,9 @@ object APIMethods_PaymentInitiationServicePISApi extends RestHelper { updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod :: updatePaymentCancellationPsuDataAuthorisationConfirmation :: updatePaymentPsuDataTransactionAuthorisation :: + updatePaymentPsuDataAuthorisationConfirmation :: + updatePaymentPsuDataSelectPsuAuthenticationMethod :: + updatePaymentPsuDataAuthorisationConfirmation :: Nil @@ -1338,7 +1341,7 @@ There are the following request types on this access path: "scaStatus": "finalised", "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), @@ -1398,6 +1401,131 @@ There are the following request types on this access path: } } } + + 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), + SelectPsuAuthenticationMethod("authenticationMethodId"), + 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"} + } + }"""), + 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/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), + AuthorisationConfirmation("authenticationMethodId"), + json.parse( + """{ + "scaStatus": "finalised", + "_links":{ + "status": {"href":"/v1/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/payments/sepa-credit-transfers/qwer3456tzui7890/status"} + } + }"""), callContext) + } + } + } } From 6b1de79af8a4d6961a1cea48d8c21858bea86013 Mon Sep 17 00:00:00 2001 From: hongwei Date: Thu, 8 Feb 2024 10:34:49 +0100 Subject: [PATCH 11/28] feature/BG1.3.12 separate startPaymentInitiationCancellationAuthorisation to 3 endpoints --- .../berlin/group/v1_3/CommonServicesApi.scala | 8 +- .../v1_3/PaymentInitiationServicePISApi.scala | 187 +++++++++++++----- .../PaymentInitiationServicePISApiTest.scala | 2 +- 3 files changed, 148 insertions(+), 49 deletions(-) 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 0631302b26..c841992832 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 @@ -33,7 +33,9 @@ object APIMethods_CommonServicesApi extends RestHelper { APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationUpdatePsuAuthentication :: APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationTransactionAuthorisation :: APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationSelectPsuAuthenticationMethod :: - APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisation :: + APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisationTransactionAuthorisation :: + APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisationUpdatePsuAuthentication :: + APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisationSelectPsuAuthenticationMethod :: APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataUpdatePsuAuthentication :: APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataTransactionAuthorisation :: APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod :: @@ -60,7 +62,9 @@ object APIMethods_CommonServicesApi extends RestHelper { 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.startPaymentInitiationCancellationAuthorisation).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 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 b00bf092ef..a94cb4964d 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 @@ -60,7 +60,9 @@ object APIMethods_PaymentInitiationServicePISApi extends RestHelper { startPaymentAuthorisationUpdatePsuAuthentication :: startPaymentAuthorisationTransactionAuthorisation :: startPaymentAuthorisationSelectPsuAuthenticationMethod :: - startPaymentInitiationCancellationAuthorisation :: + startPaymentInitiationCancellationAuthorisationTransactionAuthorisation :: + startPaymentInitiationCancellationAuthorisationUpdatePsuAuthentication :: + startPaymentInitiationCancellationAuthorisationSelectPsuAuthenticationMethod :: updatePaymentCancellationPsuDataUpdatePsuAuthentication :: updatePaymentCancellationPsuDataTransactionAuthorisation :: updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod :: @@ -938,15 +940,9 @@ This applies in the following scenarios: } } } - - 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)} + + 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. @@ -964,37 +960,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) @@ -1033,6 +1040,94 @@ This applies in the following scenarios: } } } + + resourceDocs += ResourceDoc( + startPaymentInitiationCancellationAuthorisationUpdatePsuAuthentication, + apiVersion, + 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), + UpdatePsuAuthentication(PsuData(Some("password"))), + 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" + } + } + }"""), 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), + SelectPsuAuthenticationMethod("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" + } + } + }"""), callContext) + } + } + } def generalUpdatePaymentCancellationPsuDataSummary (isMockedData: Boolean)= s"""${mockedDataText(isMockedData)} @@ -1169,7 +1264,7 @@ There are the following request types on this access path: json.parse("""{ "scaStatus": "psuAuthenticated", "_links": { - "authoriseTransaction": {"href": "/psd2/v1/payments/1234-wertiq-983/authorisations/123auth456"} + "authoriseTransaction": {"href": "/psd2/v1.3/payments/1234-wertiq-983/authorisations/123auth456"} } }"""), List(UserNotLoggedIn, UnknownError), @@ -1186,7 +1281,7 @@ There are the following request types on this access path: """{ "scaStatus": "psuAuthenticated", "_links": { - "authoriseTransaction": {"href": "/psd2/v1/payments/1234-wertiq-983/authorisations/123auth456"} + "authoriseTransaction": {"href": "/psd2/v1.3/payments/1234-wertiq-983/authorisations/123auth456"} } }"""), callContext) } @@ -1211,7 +1306,7 @@ There are the following request types on this access path: "otpMaxLength": 6, "otpFormat": "integer"}, "_links": { - "authoriseTransaction": {"href": "/psd2/v1/payments/1234-wertiq-983/authorisations/123auth456"} + "authoriseTransaction": {"href": "/psd2/v1.3/payments/1234-wertiq-983/authorisations/123auth456"} } }"""), List(UserNotLoggedIn, UnknownError), @@ -1234,7 +1329,7 @@ There are the following request types on this access path: "otpMaxLength": 6, "otpFormat": "integer"}, "_links": { - "authoriseTransaction": {"href": "/psd2/v1/payments/1234-wertiq-983/authorisations/123auth456"} + "authoriseTransaction": {"href": "/psd2/v1.3/payments/1234-wertiq-983/authorisations/123auth456"} } }"""), callContext) } @@ -1253,7 +1348,7 @@ There are the following request types on this access path: json.parse("""{ "scaStatus": "finalised", "_links":{ - "status": {"href":"/v1/payments/sepa-credit-transfers/qwer3456tzui7890/status"} + "status": {"href":"/v1.3/payments/sepa-credit-transfers/qwer3456tzui7890/status"} } }"""), List(UserNotLoggedIn, UnknownError), @@ -1274,7 +1369,7 @@ There are the following request types on this access path: """{ "scaStatus": "finalised", "_links":{ - "status": {"href":"/v1/payments/sepa-credit-transfers/qwer3456tzui7890/status"} + "status": {"href":"/v1.3/payments/sepa-credit-transfers/qwer3456tzui7890/status"} } }"""), callContext) } @@ -1458,7 +1553,7 @@ There are the following request types on this access path: "otpMaxLength": 6, "otpFormat": "integer"}, "_links": { - "authoriseTransaction": {"href": "/psd2/v1/payments/1234-wertiq-983/authorisations/123auth456"} + "authoriseTransaction": {"href": "/psd2/v1.3/payments/1234-wertiq-983/authorisations/123auth456"} } }"""), List(UserNotLoggedIn, UnknownError), @@ -1482,7 +1577,7 @@ There are the following request types on this access path: "otpMaxLength": 6, "otpFormat": "integer"}, "_links": { - "authoriseTransaction": {"href": "/psd2/v1/payments/1234-wertiq-983/authorisations/123auth456"} + "authoriseTransaction": {"href": "/psd2/v1.3/payments/1234-wertiq-983/authorisations/123auth456"} } }"""), callContext) } @@ -1502,7 +1597,7 @@ There are the following request types on this access path: """{ "scaStatus": "finalised", "_links":{ - "status": {"href":"/v1/payments/sepa-credit-transfers/qwer3456tzui7890/status"} + "status": {"href":"/v1.3/payments/sepa-credit-transfers/qwer3456tzui7890/status"} } }"""), List(UserNotLoggedIn, UnknownError), @@ -1520,7 +1615,7 @@ There are the following request types on this access path: """{ "scaStatus": "finalised", "_links":{ - "status": {"href":"/v1/payments/sepa-credit-transfers/qwer3456tzui7890/status"} + "status": {"href":"/v1.3/payments/sepa-credit-transfers/qwer3456tzui7890/status"} } }"""), callContext) } 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 634d4844fe..2dae6a569a 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 @@ -35,7 +35,7 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with object cancelPayment extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.cancelPayment)) - object startPaymentInitiationCancellationAuthorisation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisation)) + object startPaymentInitiationCancellationAuthorisation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisationTransactionAuthorisation)) object getPaymentInitiationCancellationAuthorisationInformation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.getPaymentInitiationCancellationAuthorisationInformation)) object getPaymentCancellationScaStatus extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.getPaymentCancellationScaStatus)) object updatePaymentCancellationPsuData extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataUpdatePsuAuthentication)) From 88223119f668c67c5855863ef36e2e3a9ffab43f Mon Sep 17 00:00:00 2001 From: hongwei Date: Thu, 8 Feb 2024 10:56:38 +0100 Subject: [PATCH 12/28] feature/BG1.3.12 tweaked PsuData password field to String --- .../v1_3/PaymentInitiationServicePISApi.scala | 14 +++++++------- .../code/api/berlin/group/v1_3/model/PsuData.scala | 2 +- 2 files changed, 8 insertions(+), 8 deletions(-) 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 a94cb4964d..694338d98a 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 @@ -792,7 +792,7 @@ This applies in the following scenarios: "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations", "Start the authorisation process for a payment initiation (updatePsuAuthentication)", generalStartPaymentAuthorisationSummary(false), - UpdatePsuAuthentication(PsuData(password = Some(""))), + UpdatePsuAuthentication(PsuData(password = (""))), json.parse("""{ "challengeData": { "scaStatus": "received", @@ -812,7 +812,7 @@ This applies in the following scenarios: }.isDefined lazy val startPaymentAuthorisationUpdatePsuAuthentication : OBPEndpoint = { - case paymentService :: paymentProduct :: paymentId :: "authorisations" :: Nil JsonPost json -> _ if checkUpdatePsuAuthentication(json) => { + case paymentService :: paymentProduct :: paymentId :: "authorisations" :: Nil JsonPost json -> _ if checkUpdatePsuAuthentication(json) => { cc => for { (Full(u), callContext) <- authenticatedAccess(cc) @@ -843,7 +843,7 @@ This applies in the following scenarios: (JSONFactory_BERLIN_GROUP_1_3.createStartPaymentAuthorisationJson(challenge), callContext) } } - } + } resourceDocs += ResourceDoc( startPaymentAuthorisationSelectPsuAuthenticationMethod, @@ -873,7 +873,7 @@ This applies in the following scenarios: }.isDefined lazy val startPaymentAuthorisationSelectPsuAuthenticationMethod : OBPEndpoint = { - case paymentService :: paymentProduct :: paymentId :: "authorisations" :: Nil JsonPost json -> _ if checkSelectPsuAuthenticationMethod(json) => { + case paymentService :: paymentProduct :: paymentId :: "authorisations" :: Nil JsonPost json -> _ if checkSelectPsuAuthenticationMethod(json) => { cc => for { (Full(u), callContext) <- authenticatedAccess(cc) @@ -891,7 +891,7 @@ This applies in the following scenarios: }"""), callContext) } } - } + } resourceDocs += ResourceDoc( startPaymentAuthorisationTransactionAuthorisation, @@ -1049,7 +1049,7 @@ This applies in the following scenarios: "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations", "Start the authorisation process for the cancellation of the addressed payment (updatePsuAuthentication)", generalStartPaymentInitiationCancellationAuthorisationSummary(true), - UpdatePsuAuthentication(PsuData(Some("password"))), + UpdatePsuAuthentication(PsuData("password")), json.parse("""{ "scaStatus": "received", "authorisationId": "123auth456", @@ -1260,7 +1260,7 @@ There are the following request types on this access path: "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations/AUTHORISATION_ID", "Update PSU Data for payment initiation cancellation (updatePsuAuthentication)", generalUpdatePaymentCancellationPsuDataSummary(true), - UpdatePsuAuthentication(PsuData(Some("password"))), + UpdatePsuAuthentication(PsuData("password")), json.parse("""{ "scaStatus": "psuAuthenticated", "_links": { 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 index 631664743e..018763be81 100644 --- 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 @@ -15,7 +15,7 @@ package code.api.berlin.group.v1_3.model case class PsuData ( /* Password. */ - password: Option[String] = None, + password: String, /* Encrypted password. */ encryptedPassword: Option[String] = None, /* Additional password in plaintext. */ From be76577363cfc7ca9f709cbf4b1384a7b6ab19c7 Mon Sep 17 00:00:00 2001 From: hongwei Date: Thu, 8 Feb 2024 14:23:17 +0100 Subject: [PATCH 13/28] feature/BG1.3.12 fixed the failed tests --- .../PaymentInitiationServicePISApiTest.scala | 23 ++++++++++++------- 1 file changed, 15 insertions(+), 8 deletions(-) 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 2dae6a569a..e6f20ffb01 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 @@ -293,7 +294,11 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with scenario(s"${startPaymentAuthorisation.name} Failed Case - Wrong PaymentId", BerlinGroupV1_3, PIS, startPaymentAuthorisation) { 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, """{ + | "psuData": { + | "password": "start12" + | } + |}""".stripMargin) Then("We should get a 400 ") response.code should equal(400) response.body.extract[ErrorMessage].message should startWith (InvalidTransactionRequestId) @@ -342,7 +347,11 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with Then(s"we test the ${startPaymentAuthorisation.name}") val requestPost = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / paymentId / "authorisations").POST <@ (user1) - val response: APIResponse = makePostRequest(requestPost, """""") + val response: APIResponse = makePostRequest(requestPost, """{ + | "psuData": { + | "password": "start12" + | } + |}""".stripMargin) Then("We should get a 200 ") response.code should equal(200) val startPaymentAuthorisationResponse = response.body.extract[StartPaymentAuthorisationJson] @@ -377,8 +386,7 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with 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 @@ -404,7 +412,7 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with scenario(s"${startPaymentInitiationCancellationAuthorisation.name} Failed Case - Wrong PaymentId", BerlinGroupV1_3, PIS, startPaymentInitiationCancellationAuthorisation) { 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) @@ -449,14 +457,13 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with Then(s"we test the ${startPaymentInitiationCancellationAuthorisation.name}") val requestPost = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / paymentId / "cancellation-authorisations").POST <@ (user1) - val response: APIResponse = makePostRequest(requestPost, "") + val response: APIResponse = makePostRequest(requestPost, """{"scaAuthenticationData":""}""") Then("We should get a 200 ") response.code should equal(200) - val startPaymentAuthorisationResponse = response.body.extract[StartPaymentAuthorisationJson] + 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.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) From d8e66a0cbee43ccf63ce5854b2f126960f763e24 Mon Sep 17 00:00:00 2001 From: hongwei Date: Thu, 8 Feb 2024 14:23:36 +0100 Subject: [PATCH 14/28] feature/BG1.3.12 moved helper methods to JSONFactory_BERLIN_GROUP_1_3.scala --- .../v1_3/JSONFactory_BERLIN_GROUP_1_3.scala | 17 ++++++++++++++ .../v1_3/PaymentInitiationServicePISApi.scala | 22 +++++-------------- 2 files changed, 22 insertions(+), 17 deletions(-) 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 da0f6b3dfe..77d2aacaa4 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 @@ -11,6 +11,7 @@ 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} @@ -652,4 +653,20 @@ object JSONFactory_BERLIN_GROUP_1_3 extends CustomJsonFormats { ) ) } + + 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 694338d98a..813f4762d8 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,7 +1,9 @@ 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._ @@ -807,10 +809,7 @@ This applies in the following scenarios: ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil ) - def checkUpdatePsuAuthentication(JsonPost: JValue) = tryo { - JsonPost.extract[UpdatePsuAuthentication] - }.isDefined - + lazy val startPaymentAuthorisationUpdatePsuAuthentication : OBPEndpoint = { case paymentService :: paymentProduct :: paymentId :: "authorisations" :: Nil JsonPost json -> _ if checkUpdatePsuAuthentication(json) => { cc => @@ -868,10 +867,6 @@ This applies in the following scenarios: ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil ) - def checkSelectPsuAuthenticationMethod(JsonPost: JValue) = tryo { - JsonPost.extract[SelectPsuAuthenticationMethod] - }.isDefined - lazy val startPaymentAuthorisationSelectPsuAuthenticationMethod : OBPEndpoint = { case paymentService :: paymentProduct :: paymentId :: "authorisations" :: Nil JsonPost json -> _ if checkSelectPsuAuthenticationMethod(json) => { cc => @@ -916,10 +911,7 @@ This applies in the following scenarios: ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil ) - def checkTransactionAuthorisation(JsonPost: JValue) = tryo { - JsonPost.extract[TransactionAuthorisation] - }.isDefined - + lazy val startPaymentAuthorisationTransactionAuthorisation : OBPEndpoint = { case paymentService :: paymentProduct :: paymentId :: "authorisations" :: Nil JsonPost json -> _ if checkTransactionAuthorisation(json) => { cc => @@ -1355,10 +1347,6 @@ There are the following request types on this access path: ApiTag("Payment Initiation Service (PIS)") :: apiTagBerlinGroupM :: Nil ) - def checkAuthorisationConfirmation(JsonPost: JValue) = tryo { - JsonPost.extract[AuthorisationConfirmation] - }.isDefined - lazy val updatePaymentCancellationPsuDataAuthorisationConfirmation : OBPEndpoint = { case paymentService :: paymentProduct :: paymentId:: "cancellation-authorisations" :: authorisationId :: Nil JsonPut json -> _ if checkAuthorisationConfirmation(json)=> { cc => From 7d97fb48f2abbc1322717ade08d60c8d9ee379f0 Mon Sep 17 00:00:00 2001 From: hongwei Date: Thu, 8 Feb 2024 15:01:43 +0100 Subject: [PATCH 15/28] feature/BG1.3.12 fixed the tests --- .../v1_3/PaymentInitiationServicePISApiTest.scala | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) 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 e6f20ffb01..3e04f6cad6 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 @@ -462,7 +462,7 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with response.code should equal(200) 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) Then(s"We can test the ${getPaymentInitiationCancellationAuthorisationInformation.name}") @@ -481,17 +481,11 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with cancellationScaStatus should be (ScaStatus.received.toString) Then(s"We can test the ${updatePaymentCancellationPsuData.name}") - val updatePaymentCancellationPsuDataJsonBody = APIMethods_PaymentInitiationServicePISApi - .resourceDocs - .filter( _.partialFunction == APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataUpdatePsuAuthentication) - .head.exampleRequestBody.asInstanceOf[JvalueCaseClass] //All the Json String convert to JvalueCaseClass implicitly - .jvalueToCaseclass 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") } } From 62a94a7825e740635c23e3cd0023230c1a92ed3e Mon Sep 17 00:00:00 2001 From: hongwei Date: Thu, 8 Feb 2024 15:27:07 +0100 Subject: [PATCH 16/28] feature/BG1.3.12 separate startConsentAuthorisation to 3 endpoints --- .../AccountInformationServiceAISApi.scala | 158 ++++++++++++++---- .../berlin/group/v1_3/CommonServicesApi.scala | 8 +- .../v1_3/PaymentInitiationServicePISApi.scala | 8 +- .../AccountInformationServiceAISApiTest.scala | 2 +- 4 files changed, 139 insertions(+), 37 deletions(-) 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 0ea139f88e..a007a8b8e6 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 @@ -26,6 +26,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,7 +56,9 @@ object APIMethods_AccountInformationServiceAISApi extends RestHelper { getTransactionList :: readAccountDetails :: readCardAccount :: - startConsentAuthorisation :: + startConsentAuthorisationTransactionAuthorisation :: + startConsentAuthorisationUpdatePsuAuthentication :: + startConsentAuthorisationSelectPsuAuthenticationMethod :: updateConsentsPsuData :: Nil lazy val newStyleEndpoints: List[(String, String)] = resourceDocs.map { @@ -1019,42 +1022,45 @@ respectively the OAuth2 access token. } } - resourceDocs += ResourceDoc( - startConsentAuthorisation, - apiVersion, - nameOf(startConsentAuthorisation), - "POST", - "/consents/CONSENTID/authorisations", - "Start the authorisation process for a consent", + def generalStartConsentAuthorisationSumarry(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,//TODO in the `psd2-api v1.3.12-2022-07-06.yaml` it is a oneOf field, if OBP need it we can add it back. +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)", + generalStartConsentAuthorisationSumarry(false), + json.parse("""{"scaAuthenticationData":""}"""), json.parse("""{ "scaStatus": "received", "psuMessage": "Please use your BankApp for transaction Authorisation.", @@ -1068,8 +1074,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 JsonPut json -> _ if checkTransactionAuthorisation(json)=> { cc => for { (Full(u), callContext) <- authenticatedAccess(cc) @@ -1096,6 +1102,94 @@ The ASPSP might make the usage of this access method unnecessary, since the rela } } } + + resourceDocs += ResourceDoc( + startConsentAuthorisationUpdatePsuAuthentication, + apiVersion, + nameOf(startConsentAuthorisationUpdatePsuAuthentication), + "POST", + "/consents/CONSENTID/authorisations", + "Start the authorisation process for a consent(updatePsuAuthentication)", + generalStartConsentAuthorisationSumarry(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 JsonPut 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)", + generalStartConsentAuthorisationSumarry(true), + SelectPsuAuthenticationMethod("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 JsonPut 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)) + } + } + } resourceDocs += ResourceDoc( updateConsentsPsuData, 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 c841992832..e23c36dca2 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 @@ -44,7 +44,9 @@ object APIMethods_CommonServicesApi extends RestHelper { APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataAuthorisationConfirmation :: APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataSelectPsuAuthenticationMethod :: APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataAuthorisationConfirmation :: - APIMethods_AccountInformationServiceAISApi.startConsentAuthorisation :: + APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationTransactionAuthorisation :: + APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationUpdatePsuAuthentication :: + APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationSelectPsuAuthenticationMethod :: APIMethods_AccountInformationServiceAISApi.updateConsentsPsuData :: APIMethods_AccountInformationServiceAISApi.getConsentScaStatus :: Nil @@ -74,7 +76,9 @@ object APIMethods_CommonServicesApi extends RestHelper { 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.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.updateConsentsPsuData ).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/PaymentInitiationServicePISApi.scala b/obp-api/src/main/scala/code/api/berlin/group/v1_3/PaymentInitiationServicePISApi.scala index 813f4762d8..d969c70de6 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 @@ -793,7 +793,7 @@ This applies in the following scenarios: "POST", "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations", "Start the authorisation process for a payment initiation (updatePsuAuthentication)", - generalStartPaymentAuthorisationSummary(false), + generalStartPaymentAuthorisationSummary(true), UpdatePsuAuthentication(PsuData(password = (""))), json.parse("""{ "challengeData": { @@ -1041,7 +1041,11 @@ This applies in the following scenarios: "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations", "Start the authorisation process for the cancellation of the addressed payment (updatePsuAuthentication)", generalStartPaymentInitiationCancellationAuthorisationSummary(true), - UpdatePsuAuthentication(PsuData("password")), + json.parse("""{ + "psuData": { + "password": "start12" + } + }"""), json.parse("""{ "scaStatus": "received", "authorisationId": "123auth456", 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..17df55f9c3 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,7 +38,7 @@ class AccountInformationServiceAISApiTest extends BerlinGroupServerSetupV1_3 wit object getConsentStatus extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.getConsentStatus)) - object startConsentAuthorisation extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.startConsentAuthorisation)) + object startConsentAuthorisation extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationTransactionAuthorisation)) object getConsentAuthorisation extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.getConsentAuthorisation)) From 8fa9537f6f057ff4dece6b226e6e2d1a88bc40b6 Mon Sep 17 00:00:00 2001 From: hongwei Date: Thu, 8 Feb 2024 15:30:29 +0100 Subject: [PATCH 17/28] feature/BG1.3.12 tweaked the SelectPsuAuthenticationMethod json body --- .../group/v1_3/AccountInformationServiceAISApi.scala | 2 +- .../group/v1_3/PaymentInitiationServicePISApi.scala | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) 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 a007a8b8e6..2a76525f48 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 @@ -1157,7 +1157,7 @@ using the extended forms as indicated above. "/consents/CONSENTID/authorisations", "Start the authorisation process for a consent(selectPsuAuthenticationMethod)", generalStartConsentAuthorisationSumarry(true), - SelectPsuAuthenticationMethod("authenticationMethodId"), + json.parse("""{"authenticationMethodId":""}"""), json.parse("""{ "scaStatus": "received", "psuMessage": "Please use your BankApp for transaction Authorisation.", 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 d969c70de6..03ba01ad00 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 @@ -852,7 +852,7 @@ This applies in the following scenarios: "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations", "Start the authorisation process for a payment initiation (selectPsuAuthenticationMethod)", generalStartPaymentAuthorisationSummary(true), - SelectPsuAuthenticationMethod("authenticationMethodId"), + json.parse("""{"authenticationMethodId":""}"""), json.parse("""{ "challengeData": { "scaStatus": "received", @@ -1089,7 +1089,7 @@ This applies in the following scenarios: "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations", "Start the authorisation process for the cancellation of the addressed payment (selectPsuAuthenticationMethod)", generalStartPaymentInitiationCancellationAuthorisationSummary(true), - SelectPsuAuthenticationMethod("authenticationMethodId"), + json.parse("""{"authenticationMethodId":""}"""), json.parse("""{ "scaStatus": "received", "authorisationId": "123auth456", @@ -1292,7 +1292,7 @@ There are the following request types on this access path: "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations/AUTHORISATION_ID", "Update PSU Data for payment initiation cancellation (selectPsuAuthenticationMethod)", generalUpdatePaymentCancellationPsuDataSummary(true), - SelectPsuAuthenticationMethod("authenticationMethodId"), + json.parse("""{"authenticationMethodId":""}"""), json.parse("""{ "scaStatus": "scaMethodSelected", "chosenScaMethod": { @@ -1534,7 +1534,7 @@ There are the following request types on this access path: "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations/AUTHORISATION_ID", "Update PSU data for payment initiation (selectPsuAuthenticationMethod)", generalUpdatePaymentPsuDataSumarry(true), - SelectPsuAuthenticationMethod("authenticationMethodId"), + json.parse("""{"authenticationMethodId":""}"""), json.parse( """{ "scaStatus": "scaMethodSelected", From f842938601dc7e3fcd2d2eda8faaf6a7e0ff5599 Mon Sep 17 00:00:00 2001 From: hongwei Date: Thu, 8 Feb 2024 15:31:43 +0100 Subject: [PATCH 18/28] feature/BG1.3.12 fixed the tests --- .../group/v1_3/AccountInformationServiceAISApiTest.scala | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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 17df55f9c3..4b8f9085a0 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 @@ -380,7 +380,7 @@ class AccountInformationServiceAISApiTest extends BerlinGroupServerSetupV1_3 wit Then(s"We test the $startConsentAuthorisation") 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") } @@ -422,7 +422,7 @@ class AccountInformationServiceAISApiTest extends BerlinGroupServerSetupV1_3 wit Then(s"We test the $startConsentAuthorisation") 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") From 443cd9e0cc20b2540266ff7d14af2c6fb3219db9 Mon Sep 17 00:00:00 2001 From: hongwei Date: Thu, 8 Feb 2024 17:36:47 +0100 Subject: [PATCH 19/28] feature/BG1.3.12 separate updateConsentsPsuData to 4 endpoints --- .../AccountInformationServiceAISApi.scala | 173 ++++++++++++++++-- .../berlin/group/v1_3/CommonServicesApi.scala | 10 +- .../v1_3/JSONFactory_BERLIN_GROUP_1_3.scala | 6 +- .../AccountInformationServiceAISApiTest.scala | 2 +- 4 files changed, 166 insertions(+), 25 deletions(-) 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 2a76525f48..34fb768d7e 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._ @@ -59,7 +61,10 @@ object APIMethods_AccountInformationServiceAISApi extends RestHelper { startConsentAuthorisationTransactionAuthorisation :: startConsentAuthorisationUpdatePsuAuthentication :: startConsentAuthorisationSelectPsuAuthenticationMethod :: - updateConsentsPsuData :: + updateConsentsPsuDataTransactionAuthorisation :: + updateConsentsPsuDataUpdatePsuAuthentication :: + updateConsentsPsuDataUpdateAuthorisationConfirmation :: + updateConsentsPsuDataUpdateSelectPsuAuthenticationMethod :: Nil lazy val newStyleEndpoints: List[(String, String)] = resourceDocs.map { rd => (rd.partialFunctionName, rd.implementedInApiVersion.toString()) @@ -1075,7 +1080,7 @@ using the extended forms as indicated above. ) lazy val startConsentAuthorisationTransactionAuthorisation : OBPEndpoint = { - case "consents" :: consentId :: "authorisations" :: Nil JsonPut json -> _ if checkTransactionAuthorisation(json)=> { + case "consents" :: consentId :: "authorisations" :: Nil JsonPost json -> _ if checkTransactionAuthorisation(json)=> { cc => for { (Full(u), callContext) <- authenticatedAccess(cc) @@ -1130,7 +1135,7 @@ using the extended forms as indicated above. ) lazy val startConsentAuthorisationUpdatePsuAuthentication : OBPEndpoint = { - case "consents" :: consentId :: "authorisations" :: Nil JsonPut json -> _ if checkUpdatePsuAuthentication(json)=> { + case "consents" :: consentId :: "authorisations" :: Nil JsonPost json -> _ if checkUpdatePsuAuthentication(json)=> { cc => for { (Full(u), callContext) <- authenticatedAccess(cc) @@ -1172,7 +1177,7 @@ using the extended forms as indicated above. ) lazy val startConsentAuthorisationSelectPsuAuthenticationMethod : OBPEndpoint = { - case "consents" :: consentId :: "authorisations" :: Nil JsonPut json -> _ if checkSelectPsuAuthenticationMethod(json)=> { + case "consents" :: consentId :: "authorisations" :: Nil JsonPost json -> _ if checkSelectPsuAuthenticationMethod(json)=> { cc => for { (Full(u), callContext) <- authenticatedAccess(cc) @@ -1190,14 +1195,8 @@ using the extended forms as indicated above. } } } - - resourceDocs += ResourceDoc( - updateConsentsPsuData, - apiVersion, - nameOf(updateConsentsPsuData), - "PUT", - "/consents/CONSENTID/authorisations/AUTHORISATIONID", - "Update PSU Data for consents", + + 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 @@ -1224,18 +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"}"""), - PutConsentResponseJson( + ScaStatusResponse( scaStatus = "received", - _links = ConsentLinksV13("/v1.3/consents/1234-wertiq-983/authorisations") + _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) @@ -1243,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) { @@ -1285,6 +1293,133 @@ Maybe in a later version the access path will change. } } } + + 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("""{ + | "authenticationMethodId": "myAuthenticationID" + |}""".stripMargin), + 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 e23c36dca2..e05d065872 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 @@ -47,7 +47,10 @@ object APIMethods_CommonServicesApi extends RestHelper { APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationTransactionAuthorisation :: APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationUpdatePsuAuthentication :: APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationSelectPsuAuthenticationMethod :: - APIMethods_AccountInformationServiceAISApi.updateConsentsPsuData :: + APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataTransactionAuthorisation :: + APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataUpdatePsuAuthentication :: + APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataUpdateAuthorisationConfirmation :: + APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataUpdateSelectPsuAuthenticationMethod :: APIMethods_AccountInformationServiceAISApi.getConsentScaStatus :: Nil @@ -79,7 +82,10 @@ object APIMethods_CommonServicesApi extends RestHelper { 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.updateConsentsPsuData ).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 77d2aacaa4..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 @@ -509,10 +509,10 @@ object JSONFactory_BERLIN_GROUP_1_3 extends CustomJsonFormats { _links= ConsentLinksV13(s"/v1.3/consents/${consent.consentId}/authorisations") ) } - def createPutConsentResponseJson(consent: ConsentTrait) : PutConsentResponseJson = { - PutConsentResponseJson( + def createPutConsentResponseJson(consent: ConsentTrait) : ScaStatusResponse = { + ScaStatusResponse( scaStatus = consent.status.toLowerCase(), - _links= ConsentLinksV13(s"/v1.3/consents/${consent.consentId}/authorisations") + _links = Some(LinksAll(scaStatus = Some(HrefType(Some(s"/v1.3/consents/${consent.consentId}/authorisations"))))) ) } 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 4b8f9085a0..f66401936f 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 @@ -44,7 +44,7 @@ class AccountInformationServiceAISApiTest extends BerlinGroupServerSetupV1_3 wit object getConsentScaStatus extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.getConsentScaStatus)) - object updateConsentsPsuData extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.updateConsentsPsuData)) + object updateConsentsPsuData extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataTransactionAuthorisation)) feature(s"BG v1.3 - $getAccountList") { From 076354d5bd656dfc74bfd94913b505b6d43f4033 Mon Sep 17 00:00:00 2001 From: hongwei Date: Thu, 8 Feb 2024 17:48:48 +0100 Subject: [PATCH 20/28] feature/BG1.3.12 tweaked the startPaymentAuthorisationTransactionAuthorisation to use real data --- .../v1_3/PaymentInitiationServicePISApi.scala | 89 +++++++++---------- .../PaymentInitiationServicePISApiTest.scala | 12 +-- 2 files changed, 46 insertions(+), 55 deletions(-) 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 03ba01ad00..b601e8bdfc 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 @@ -814,34 +814,20 @@ This applies in the following scenarios: case paymentService :: paymentProduct :: paymentId :: "authorisations" :: Nil JsonPost json -> _ if checkUpdatePsuAuthentication(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 - } + (_, callContext) <- authenticatedAccess(cc) } 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" + } + } + }"""), callContext) } - } + } } resourceDocs += ResourceDoc( @@ -895,8 +881,8 @@ This applies in the following scenarios: "POST", "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations", "Start the authorisation process for a payment initiation (transactionAuthorisation)", - generalStartPaymentAuthorisationSummary(true), - TransactionAuthorisation("scaAuthenticationData"), + generalStartPaymentAuthorisationSummary(false), + json.parse("""{"scaAuthenticationData":"123"}"""), json.parse("""{ "challengeData": { "scaStatus": "received", @@ -914,23 +900,36 @@ This applies in the following scenarios: lazy val startPaymentAuthorisationTransactionAuthorisation : OBPEndpoint = { case paymentService :: paymentProduct :: paymentId :: "authorisations" :: Nil JsonPost json -> _ if checkTransactionAuthorisation(json) => { - cc => - for { - (Full(u), 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" - } - } - }"""), callContext) - } - } + 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) + } + } } def generalStartPaymentInitiationCancellationAuthorisationSummary (isMockedDate:Boolean) = 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 3e04f6cad6..664f914531 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 @@ -294,11 +294,7 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with scenario(s"${startPaymentAuthorisation.name} Failed Case - Wrong PaymentId", BerlinGroupV1_3, PIS, startPaymentAuthorisation) { 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) + 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) @@ -347,11 +343,7 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with Then(s"we test the ${startPaymentAuthorisation.name}") val requestPost = (V1_3_BG / PaymentServiceTypes.payments.toString / TransactionRequestTypes.SEPA_CREDIT_TRANSFERS.toString / paymentId / "authorisations").POST <@ (user1) - val response: APIResponse = makePostRequest(requestPost, """{ - | "psuData": { - | "password": "start12" - | } - |}""".stripMargin) + val response: APIResponse = makePostRequest(requestPost, """{"scaAuthenticationData":"123"}""".stripMargin) Then("We should get a 200 ") response.code should equal(200) val startPaymentAuthorisationResponse = response.body.extract[StartPaymentAuthorisationJson] From 09a2f003ff62921e1f381e106bdbb11d1e794b32 Mon Sep 17 00:00:00 2001 From: hongwei Date: Fri, 9 Feb 2024 10:04:24 +0100 Subject: [PATCH 21/28] feature/BG1.3.12 added tests for startConsentAuthorisation endpoints --- .../AccountInformationServiceAISApiTest.scala | 32 +++++++++++++++---- 1 file changed, 25 insertions(+), 7 deletions(-) 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 f66401936f..bc634ece6e 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,7 +38,9 @@ class AccountInformationServiceAISApiTest extends BerlinGroupServerSetupV1_3 wit object getConsentStatus extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.getConsentStatus)) - object startConsentAuthorisation extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationTransactionAuthorisation)) + 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)) @@ -345,8 +347,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 +380,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, """{"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 ${updateConsentsPsuData.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,7 +438,7 @@ 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, """{"scaAuthenticationData":""}""") responseStartConsentAuthorisation.code should be (201) From 41812064c2980b15773078ba4f6b11a14288202c Mon Sep 17 00:00:00 2001 From: hongwei Date: Fri, 9 Feb 2024 10:13:13 +0100 Subject: [PATCH 22/28] feature/BG1.3.12 tweaked the response body --- .../berlin/group/v1_3/AccountInformationServiceAISApi.scala | 4 +--- .../berlin/group/v1_3/PaymentInitiationServicePISApi.scala | 4 ++-- 2 files changed, 3 insertions(+), 5 deletions(-) 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 34fb768d7e..f40d429e98 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 @@ -1390,9 +1390,7 @@ Maybe in a later version the access path will change. "/consents/CONSENTID/authorisations/AUTHORISATIONID", "Update PSU Data for consents (authorisationConfirmation)", generalUpdateConsentsPsuDataSummary(true), - json.parse("""{ - | "authenticationMethodId": "myAuthenticationID" - |}""".stripMargin), + json.parse("""{"confirmationCode":"confirmationCode"}"""), json.parse("""{ | "scaStatus": "finalised", | "_links":{ 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 b601e8bdfc..1699cb16c4 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 @@ -1339,7 +1339,7 @@ There are the following request types on this access path: "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations/AUTHORISATION_ID", "Update PSU Data for payment initiation cancellation (authorisationConfirmation)", generalUpdatePaymentCancellationPsuDataSummary(true), - AuthorisationConfirmation("authenticationMethodId"), + json.parse("""{"confirmationCode":"confirmationCode"}"""), json.parse("""{ "scaStatus": "finalised", "_links":{ @@ -1583,7 +1583,7 @@ There are the following request types on this access path: "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations/AUTHORISATION_ID", "Update PSU data for payment initiation (authorisationConfirmation)", generalUpdatePaymentPsuDataSumarry(true), - AuthorisationConfirmation("authenticationMethodId"), + json.parse("""{"confirmationCode":"confirmationCode"}"""), json.parse( """{ "scaStatus": "finalised", From 87e4573abc0b59840e9d33351059f9ddc5cc9fe7 Mon Sep 17 00:00:00 2001 From: hongwei Date: Fri, 9 Feb 2024 10:47:15 +0100 Subject: [PATCH 23/28] feature/BG1.3.12 added tests for updateConsentsPsuData endpoints --- .../AccountInformationServiceAISApi.scala | 24 +++++++------- .../AccountInformationServiceAISApiTest.scala | 32 +++++++++++++++++-- 2 files changed, 42 insertions(+), 14 deletions(-) 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 f40d429e98..2ff6f7ec3b 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 @@ -1326,7 +1326,7 @@ Maybe in a later version the access path will change. | "_links": { | "authoriseTransaction": {"href": "/psd2/v1/payments/1234-wertiq-983/authorisations/123auth456"} | } - |""".stripMargin), HttpCode.`200`(callContext)) + |}""".stripMargin), HttpCode.`200`(callContext)) } } } @@ -1366,18 +1366,18 @@ Maybe in a later version the access path will change. } yield { (liftweb.json.parse( - """{ - | "scaStatus": "scaMethodSelected", - | "chosenScaMethod": { - | "authenticationType": "SMS_OTP", - | "authenticationMethodId": "myAuthenticationID"}, - | "challengeData": { - | "otpMaxLength": 6, - | "otpFormat": "integer"}, - | "_links": { + """{ + | "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)) + | } + |}""".stripMargin), HttpCode.`200`(callContext)) } } } 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 bc634ece6e..540358fec5 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 @@ -46,7 +46,10 @@ class AccountInformationServiceAISApiTest extends BerlinGroupServerSetupV1_3 wit object getConsentScaStatus extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.getConsentScaStatus)) - object updateConsentsPsuData extends Tag(nameOf(APIMethods_AccountInformationServiceAISApi.updateConsentsPsuDataTransactionAuthorisation)) + 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") { @@ -405,7 +408,7 @@ class AccountInformationServiceAISApiTest extends BerlinGroupServerSetupV1_3 wit } - feature(s"BG v1.3 - ${startConsentAuthorisationTransactionAuthorisation.name} and ${getConsentAuthorisation.name} and ${getConsentScaStatus.name} and ${updateConsentsPsuData.name}") { + 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 @@ -459,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", 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", 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", 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 From bad75f443e31ea39296cacac804f130b87691fec Mon Sep 17 00:00:00 2001 From: hongwei Date: Fri, 9 Feb 2024 11:12:43 +0100 Subject: [PATCH 24/28] feature/BG1.3.12 added tests for startPaymentAuthorisation endpoints --- .../v1_3/PaymentInitiationServicePISApi.scala | 14 +++++--- .../PaymentInitiationServicePISApiTest.scala | 35 +++++++++++++++---- 2 files changed, 38 insertions(+), 11 deletions(-) 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 1699cb16c4..6daeba7f56 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 @@ -794,7 +794,13 @@ This applies in the following scenarios: "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/authorisations", "Start the authorisation process for a payment initiation (updatePsuAuthentication)", generalStartPaymentAuthorisationSummary(true), - UpdatePsuAuthentication(PsuData(password = (""))), + json.parse( + """{ + | "scaStatus": "finalised", + | "_links":{ + | "status": {"href":"/v1/payments/sepa-credit-transfers/qwer3456tzui7890/status"} + | } + | }""".stripMargin), json.parse("""{ "challengeData": { "scaStatus": "received", @@ -825,7 +831,7 @@ This applies in the following scenarios: "scaStatus": "/v1.3/payments/sepa-credit-transfers/88695566-6642-46d5-9985-0d824624f507" } } - }"""), callContext) + }"""), HttpCode.`201`(callContext)) } } } @@ -869,7 +875,7 @@ This applies in the following scenarios: "scaStatus": "/v1.3/payments/sepa-credit-transfers/88695566-6642-46d5-9985-0d824624f507" } } - }"""), callContext) + }"""), HttpCode.`201`(callContext)) } } } @@ -927,7 +933,7 @@ This applies in the following scenarios: challenges.head } } yield { - (JSONFactory_BERLIN_GROUP_1_3.createStartPaymentAuthorisationJson(challenge), callContext) + (JSONFactory_BERLIN_GROUP_1_3.createStartPaymentAuthorisationJson(challenge), HttpCode.`201`(callContext)) } } } 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 664f914531..6a0355cc93 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 @@ -29,7 +29,9 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with object getPaymentInformation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.getPaymentInformation)) object getPaymentInitiationStatus extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.getPaymentInitiationStatus)) - object startPaymentAuthorisation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.startPaymentAuthorisationUpdatePsuAuthentication)) + 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.updatePaymentPsuDataTransactionAuthorisation)) @@ -290,8 +292,8 @@ 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 ${updatePaymentPsuData.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, """{"scaAuthenticationData":"123"}""".stripMargin) @@ -299,7 +301,7 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with 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 @@ -341,11 +343,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, """{"scaAuthenticationData":"123"}""".stripMargin) - Then("We should get a 200 ") - response.code should equal(200) + 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.") @@ -397,6 +399,25 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with } } + 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 ${startPaymentInitiationCancellationAuthorisation.name} " + s"and ${getPaymentInitiationCancellationAuthorisationInformation.name} " + s"and ${getPaymentCancellationScaStatus.name}" + From f7816618a452b4f8e2eea4d0499c8228ca1e6375 Mon Sep 17 00:00:00 2001 From: hongwei Date: Fri, 9 Feb 2024 11:37:04 +0100 Subject: [PATCH 25/28] feature/BG1.3.12 added tests for startPaymentInitiationCancellationAuthorisation endpoints --- .../v1_3/PaymentInitiationServicePISApi.scala | 6 ++-- .../PaymentInitiationServicePISApiTest.scala | 32 +++++++++++++++---- 2 files changed, 29 insertions(+), 9 deletions(-) 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 6daeba7f56..07d15ff983 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 @@ -1033,7 +1033,7 @@ This applies in the following scenarios: paymentService, paymentProduct, paymentId - ), callContext) + ), HttpCode.`201`(callContext)) } } } @@ -1081,7 +1081,7 @@ This applies in the following scenarios: "href": "/v1.3/payments/qwer3456tzui7890/authorisations/123auth456" } } - }"""), callContext) + }"""), HttpCode.`201`(callContext)) } } } @@ -1125,7 +1125,7 @@ This applies in the following scenarios: "href": "/v1.3/payments/qwer3456tzui7890/authorisations/123auth456" } } - }"""), callContext) + }"""), HttpCode.`201`(callContext)) } } } 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 6a0355cc93..f981001907 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 @@ -38,7 +38,9 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with object cancelPayment extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.cancelPayment)) - object startPaymentInitiationCancellationAuthorisation extends Tag(nameOf(APIMethods_PaymentInitiationServicePISApi.startPaymentInitiationCancellationAuthorisationTransactionAuthorisation)) + 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.updatePaymentCancellationPsuDataUpdatePsuAuthentication)) @@ -418,11 +420,11 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with } } - feature(s"test the BG v1.3 ${startPaymentInitiationCancellationAuthorisation.name} " + + 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) { + 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, """{"scaAuthenticationData":""}""") @@ -468,11 +470,11 @@ 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, """{"scaAuthenticationData":""}""") - Then("We should get a 200 ") - response.code should equal(200) + 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 (Some("Please check your SMS at a mobile device.")) @@ -503,6 +505,24 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with } } + 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) + } + } + feature("test the BG v1.3 getPaymentCancellationScaStatus") { scenario("Successful call endpoint getPaymentCancellationScaStatus", BerlinGroupV1_3, PIS, getPaymentCancellationScaStatus) { When("Post empty to call initiatePayment") From dee7321deb023f085319be68bc20f1ede85bd320 Mon Sep 17 00:00:00 2001 From: hongwei Date: Fri, 9 Feb 2024 13:42:26 +0100 Subject: [PATCH 26/28] feature/BG1.3.12 added tests for updatePaymentCancellationPsuData endpoints --- .../berlin/group/v1_3/CommonServicesApi.scala | 2 +- .../v1_3/PaymentInitiationServicePISApi.scala | 2 +- .../PaymentInitiationServicePISApiTest.scala | 37 +++++++++++++++++-- 3 files changed, 36 insertions(+), 5 deletions(-) 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 e05d065872..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 @@ -41,7 +41,7 @@ object APIMethods_CommonServicesApi extends RestHelper { APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataSelectPsuAuthenticationMethod :: APIMethods_PaymentInitiationServicePISApi.updatePaymentCancellationPsuDataAuthorisationConfirmation :: APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataTransactionAuthorisation :: - APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataAuthorisationConfirmation :: + APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataUpdatePsuAuthentication :: APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataSelectPsuAuthenticationMethod :: APIMethods_PaymentInitiationServicePISApi.updatePaymentPsuDataAuthorisationConfirmation :: APIMethods_AccountInformationServiceAISApi.startConsentAuthorisationTransactionAuthorisation :: 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 07d15ff983..899d7a168e 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 @@ -1261,7 +1261,7 @@ There are the following request types on this access path: "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations/AUTHORISATION_ID", "Update PSU Data for payment initiation cancellation (updatePsuAuthentication)", generalUpdatePaymentCancellationPsuDataSummary(true), - UpdatePsuAuthentication(PsuData("password")), + json.parse("""{"scaAuthenticationData":"123"}"""), json.parse("""{ "scaStatus": "psuAuthenticated", "_links": { 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 f981001907..f6dc1a6daa 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 @@ -43,7 +43,10 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with 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.updatePaymentCancellationPsuDataUpdatePsuAuthentication)) + 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) { @@ -423,7 +426,7 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with feature(s"test the BG v1.3 ${startPaymentInitiationCancellationAuthorisationTransactionAuthorisation.name} " + s"and ${getPaymentInitiationCancellationAuthorisationInformation.name} " + s"and ${getPaymentCancellationScaStatus.name}" + - s"and ${updatePaymentCancellationPsuData.name}") { + 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) @@ -495,7 +498,7 @@ 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}") + 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, """{"scaAuthenticationData":"123"}""") @@ -505,6 +508,34 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with } } + 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").PUT <@ (user1) + val response: APIResponse = makePutRequest(requestPost, """{"scaAuthenticationData":"123"}""") + 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").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").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) From ea858ed898b79950e2a2fde184a28aee818a690c Mon Sep 17 00:00:00 2001 From: hongwei Date: Fri, 9 Feb 2024 14:21:37 +0100 Subject: [PATCH 27/28] feature/BG1.3.12 added tests for updatePaymentPsuData endpoints --- .../v1_3/PaymentInitiationServicePISApi.scala | 2 +- .../AccountInformationServiceAISApiTest.scala | 6 +-- .../PaymentInitiationServicePISApiTest.scala | 48 ++++++++++++++++--- 3 files changed, 45 insertions(+), 11 deletions(-) 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 899d7a168e..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 @@ -1261,7 +1261,7 @@ There are the following request types on this access path: "/PAYMENT_SERVICE/PAYMENT_PRODUCT/PAYMENT_ID/cancellation-authorisations/AUTHORISATION_ID", "Update PSU Data for payment initiation cancellation (updatePsuAuthentication)", generalUpdatePaymentCancellationPsuDataSummary(true), - json.parse("""{"scaAuthenticationData":"123"}"""), + json.parse("""{ "psuData":{"password":"start12" }}"""), json.parse("""{ "scaStatus": "psuAuthenticated", "_links": { 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 540358fec5..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 @@ -470,17 +470,17 @@ class AccountInformationServiceAISApiTest extends BerlinGroupServerSetupV1_3 wit } - scenario("Authentication User, only mocked data, just test succeed", BerlinGroupV1_3, updateConsentsPsuDataUpdatePsuAuthentication) { + 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", BerlinGroupV1_3, updateConsentsPsuDataUpdateSelectPsuAuthenticationMethod) { + 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", BerlinGroupV1_3, updateConsentsPsuDataUpdateAuthorisationConfirmation) { + 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) 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 f6dc1a6daa..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 @@ -34,7 +34,10 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with 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.updatePaymentPsuDataTransactionAuthorisation)) + 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)) @@ -297,7 +300,7 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with (responseGet.body \ "fundsAvailable").extract[Boolean] should be (true) } } - feature(s"test the BG v1.3 ${startPaymentAuthorisationTransactionAuthorisation.name} and ${getPaymentInitiationAuthorisation.name} and ${getPaymentInitiationScaStatus.name} and ${updatePaymentPsuData.name}") { + 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) @@ -375,7 +378,7 @@ 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.updatePaymentPsuDataTransactionAuthorisation) @@ -404,6 +407,37 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with } } + + 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) { @@ -511,8 +545,8 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with 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").PUT <@ (user1) - val response: APIResponse = makePutRequest(requestPost, """{"scaAuthenticationData":"123"}""") + 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) } @@ -520,7 +554,7 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with 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").PUT <@ (user1) + 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) @@ -529,7 +563,7 @@ class PaymentInitiationServicePISApiTest extends BerlinGroupServerSetupV1_3 with 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").PUT <@ (user1) + 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) From d99bc4e4d51e23d9c3bd308e9c2c0b720bd70d18 Mon Sep 17 00:00:00 2001 From: hongwei Date: Tue, 13 Feb 2024 11:56:48 +0100 Subject: [PATCH 28/28] feature/BG1.3.12 typo --- .../group/v1_3/AccountInformationServiceAISApi.scala | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) 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 2ff6f7ec3b..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 @@ -1027,7 +1027,7 @@ respectively the OAuth2 access token. } } - def generalStartConsentAuthorisationSumarry(isMockedData:Boolean) = + 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. @@ -1064,7 +1064,7 @@ using the extended forms as indicated above. "POST", "/consents/CONSENTID/authorisations", "Start the authorisation process for a consent(transactionAuthorisation)", - generalStartConsentAuthorisationSumarry(false), + generalStartConsentAuthorisationSummary(false), json.parse("""{"scaAuthenticationData":""}"""), json.parse("""{ "scaStatus": "received", @@ -1115,7 +1115,7 @@ using the extended forms as indicated above. "POST", "/consents/CONSENTID/authorisations", "Start the authorisation process for a consent(updatePsuAuthentication)", - generalStartConsentAuthorisationSumarry(true), + generalStartConsentAuthorisationSummary(true), json.parse("""{ "psuData": { "password": "start12" @@ -1161,7 +1161,7 @@ using the extended forms as indicated above. "POST", "/consents/CONSENTID/authorisations", "Start the authorisation process for a consent(selectPsuAuthenticationMethod)", - generalStartConsentAuthorisationSumarry(true), + generalStartConsentAuthorisationSummary(true), json.parse("""{"authenticationMethodId":""}"""), json.parse("""{ "scaStatus": "received",