mirror of
https://github.com/OpenBankProject/OBP-API.git
synced 2026-02-06 20:27:15 +00:00
feature/BG1.3.12 seperate updatePaymentCancellationPsuData endpoints to 4 endpoints
This commit is contained in:
hongwei
parent
bc89e1c780
commit
ca6d69924b
@ -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
|
||||
|
||||
@ -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}")))
|
||||
)
|
||||
}
|
||||
}
|
||||
|
||||
@ -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,
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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,
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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
|
||||
}
|
||||
@ -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
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user