Download as PDF, PPTX
![Extended Payment Initiation Services– Implementation Guidelines Contents
Published by the Berlin Group under Creative Commons Attribution-NoDerivatives 4.0 International Public License Page 17
(ref. License Notice for full license conditions)
3.3 Secured Payment Initiation Request
Call
POST /v2/secured-payments/{payment-product}
Creates an extended payment resource for secured payments at the ASPSP for the XFPIS
service.
NOTE: This endpoint supports only some minor technical adaptions compared to compliance
related payment initiation as defined in [oFA-ComV2]. Especially, no explicit initiation of the
transfer execution is supported. This is done implicitly like in the Core XS2A interface.
NOTE: This endpoint supports generically secured payment with and without requested
execution dates. The ASPSP might restrict the functionality to one of these functions.
Path Parameters
Attribute Type Description
payment-
product
String The addressed payment product endpoint, e.g. for SEPA Credit
Transfers (SCT). The default list of products supported in this
standard is:
sepa-credit-transfers
micro-sepa-credit-transfers
instant-sepa-credit-transfers
target-2-payments
cross-border-credit-transfers
The ASPSP will publish which of the payment products/endpoints
will be supported.
For definitions of basic non-Euro generic products see
[oFA PFDom].
Further products might be published by the ASPSP within its XS2A
documentation.
NOTE: The micro-sepa-credit-transfers endpoint is a product endpoint where an ASPSP can
offer (secured) SCT payments without SCA under certain rules and obeying to the micro
payment exception rules of [PSD2]. A rule could e.g. be "up to 10 payments per TPP and PSU
under 10 Euro in a row before SCA is required". Since such a product might require a
dedicated risk management and price structure, it is supported on a dedicated endpoint.
Query Parameters
No Query Parameter
11
Berlin Group
• Classic financial services
standards
• Loooooong PDF
• Rules written up in long-
hand
• Aimed at humans](https://image.slidesharecdn.com/20240313-nordicapissummit-chriswood-240402082922-e03298d2/75/Standards-Standards-Everywhere-What-Standards-Really-Mean-In-An-API-World-Chris-Wood-Freelance-Consultant-11-2048.jpg)
Uploaded byNordic APIs
Standards, Standards, Everywhere… What Standards Really Mean In An API World - Chris Wood, Freelance Consultant
The document discusses the importance of standards in API development, emphasizing their role in creating consistency and enabling ecosystems. It highlights the challenges of implementing standards like PSD2 and the need for improved API descriptions and workflows to ease implementation. Additionally, the document suggests that future developments, possibly involving AI, could further enhance the standards landscape.
More Related Content
Similar to Standards, Standards, Everywhere… What Standards Really Mean In An API World - Chris Wood, Freelance Consultant
Standards, Standards, Everywhere… What Standards Really Mean In An API World - Chris Wood, Freelance Consultant
- 1.
- 2. Standards, Standards, Everywhere... WhatStandards (Should) Really Mean In An API World Chris Wood 13th March 2024
- 3. 3 Standards for “open blahblah blah”
- 4. 4 Standards help enable APIecosystems
- 5. 5 Standards are a templatefor APIs
- 6. Consistency for API consumers (whereit’s needed) A level playing field (where it helps) Time for more interesting things (life is boring enough) Standards, Standards, Everywhere... 6 Standards for APIs provide...
- 7. 7 What no-one eversaid: Implementing APIs based on standards is GREAT!
- 8. 8 Standards DX A workedexample
- 9. EU open banking PaymentServices Directive 2 (PSD2) 9
- 10. 10 Multiple new standards Same DXdeal for implementers
- 11. Extended Payment InitiationServices– Implementation Guidelines Contents Published by the Berlin Group under Creative Commons Attribution-NoDerivatives 4.0 International Public License Page 17 (ref. License Notice for full license conditions) 3.3 Secured Payment Initiation Request Call POST /v2/secured-payments/{payment-product} Creates an extended payment resource for secured payments at the ASPSP for the XFPIS service. NOTE: This endpoint supports only some minor technical adaptions compared to compliance related payment initiation as defined in [oFA-ComV2]. Especially, no explicit initiation of the transfer execution is supported. This is done implicitly like in the Core XS2A interface. NOTE: This endpoint supports generically secured payment with and without requested execution dates. The ASPSP might restrict the functionality to one of these functions. Path Parameters Attribute Type Description payment- product String The addressed payment product endpoint, e.g. for SEPA Credit Transfers (SCT). The default list of products supported in this standard is: sepa-credit-transfers micro-sepa-credit-transfers instant-sepa-credit-transfers target-2-payments cross-border-credit-transfers The ASPSP will publish which of the payment products/endpoints will be supported. For definitions of basic non-Euro generic products see [oFA PFDom]. Further products might be published by the ASPSP within its XS2A documentation. NOTE: The micro-sepa-credit-transfers endpoint is a product endpoint where an ASPSP can offer (secured) SCT payments without SCA under certain rules and obeying to the micro payment exception rules of [PSD2]. A rule could e.g. be "up to 10 payments per TPP and PSU under 10 Euro in a row before SCA is required". Since such a product might require a dedicated risk management and price structure, it is supported on a dedicated endpoint. Query Parameters No Query Parameter 11 Berlin Group • Classic financial services standards • Loooooong PDF • Rules written up in long- hand • Aimed at humans
- 12. Standards, Standards, Everywhere... 12 UKOpen Banking • Swaps the PDF for HTML • Better for indexing and search • Still long with lots of detail • Still needs transposing to code...
- 13. • Praise befor API descriptions • Standards bodies provide them • Very helpful, but rarely a 1st class citizen • They are very useful as a template • Based on DAY 1 of the summit, is there a problem with complexity? Standards, Standards, Everywhere... 13 But we did get...
- 14. • Lots ofverbiage • Needs to be transposed to code • Tends to be very inefficient • Involves multiple people – developer, analysts, etc. • Decreases enablement of ecosystems Standards, Standards, Everywhere... 14 Root the problem?
- 15.
- 16. 16 Can we make standards-based APIsany easier to implement?
- 17. • We’ve alreadymentioned them... • API descriptions provide machine- readable representations • There’s plenty of options... • Make them 1st class citizens • Focus on use cases... 17 API descriptions Standards, Standards, Everywhere...
- 18. • Nascent standard •Codify the sequence of APIs calls • Do it within and across APIs • Provides rules for following the sequence of calls 18 OpenAPI Workflows Standards, Standards, Everywhere...
- 19. • Lots saidalready... • Can we make it deterministic? • Chatting does not equal an attestation • Can there be such a thing as the standards (L)LM or GPT? Standards, Standards, Everywhere... 19 What about AI?
- 20. OAI Workflow (or an alternative) Standards,Standards, Everywhere... 20 The Future of Standards DX? (A GPT for standards)
- 21.