fix: signing baskets follow NextGenPSD2 1.3.16, belong to their TPP and book what they authorise (minimal)

[hongwei1]

fix: signing baskets follow NextGenPSD2 1.3.16, belong to their TPP and book what they authorise (minimal)

Base: origin/develop (78406d7f7). 1 commit, about 400 changed lines of main code.

A deliberately small version of the Berlin Group signing basket for the mapped connector, enough to run the main flow (create a basket, start its authorisation, answer with the OTP, book the payments one by one, ACTC) without the defects found in the current implementation. A fuller version (execution ledger, resumption scheduler, consents, PSU binding, results endpoint) is in #2934; this PR is the subset worth reviewing first.

What changes

Response shape and validation

• transactionStatus is upper case (RCVD, not rcvd).
• _links.scaStatus is a { "href": ... } object, and the PUT answer links to /signing-baskets/{basketId}/authorisations/{id} instead of a payment URL.
• An empty id list, or the same id twice, is 400 FORMAT_ERROR.
• Authorisation bodies that are not implemented (updatePsuAuthentication, selectPsuAuthenticationMethod, authorisationConfirmation) are refused with 400 SERVICE_INVALID instead of being discarded.
• A wrong or expired OTP is 401 PSU_CREDENTIALS_INVALID; an authorisation id the basket does not have is 404; unknown basket or one the caller may not address is 403 RESOURCE_UNKNOWN; status conflicts are 409 STATUS_INVALID.

Ownership. A basket records the consumer that created it (nullable consumerid column on signingbasket, added by Schemifier). Every operation is limited to that consumer. An unknown basket, another TPP's basket and a basket created before ownership was recorded all answer the same way. A payment may only be put in a basket by the TPP that lodged it, and only while it awaits SCA.

State. Delete (RCVD -> CANC) and the claim of an answered authorisation (RCVD -> AUTHORISING) are conditional updates, so an answer and a delete racing each other have one winner. A basket that is no longer RCVD cannot be deleted or given a new authorisation.

Answering the authorisation (PUT .../authorisations/{id}), in this order: instance setting, ownership, the authorisation belongs to the basket, body variant, basket and challenge state, every payment still waiting for SCA; then the answer; then the claim; then the payments are booked one after another, each awaited, so the money has moved when the response is sent. Only a challenge the connector records as finalised authorises anything. The basket becomes ACTC only if every payment was booked. Before this change a successful PUT stored the payments as COMPLETED and the basket as ACTC while no account moved.

Switched off by default. signing_basket_authorisation_enabled (default false): the PUT answers 403 SERVICE_BLOCKED until it is set. Creating, reading, starting an authorisation on and deleting baskets are not affected.

Consents are refused (400 SERVICE_INVALID) until their authorisation exists. Before this change a consent named in a basket was recorded and never authorised.

Behaviour changes visible to TPPs

Call	Before	After
any basket response	transactionStatus: "rcvd"	"RCVD"
unknown basket / another TPP's basket	400 OBP-50200, or success for any holder of the id	403 RESOURCE_UNKNOWN
DELETE after the authorisation was answered	204, basket became CANC	409 STATUS_INVALID
POST authorisation on a cancelled or authorised basket	201	409 STATUS_INVALID
POST basket with [], duplicates, invented or already booked ids	201	400 / 409
POST basket naming a consent	201, never authorised	400 SERVICE_INVALID
POST authorisation with PSU credentials in the body	201, body discarded	400 SERVICE_INVALID
PUT authorisation	authorised the basket, did not reliably book	403 unless the property is true; then books the payments before answering
PUT with a payment that is no longer waiting for SCA	accepted	409, nothing booked

Known limits (it is a proof of concept)

• Several payments are not one transaction. If one cannot be booked the earlier ones stay booked, the basket stays AUTHORISING (reported RCVD) and the response says not every payment was booked; each payment's own status shows which. Nothing resumes it.
• Nothing prevents the same payment from being put in two baskets, or from being authorised on its own while a basket holds it; the check that a payment still awaits SCA is the only guard.
• The challenge is minted for the authenticated user, so the flow assumes the PSU's own token. A client-credentials TPP relaying an OTP is not handled.
• Only the mapped connector is considered; other connectors are untested.
• Not in this change: Location and ASPSP-SCA-Approach headers, per-member results, consents, PSU binding.

Verification

• SigningBasketServiceSBSApiTest (45 scenarios, including payments booked and balances moved, ownership across two TPPs and a legacy basket, answer replay against another basket, a wrong answer, the instance setting, PUT racing DELETE, and a stand-in connector that returns a failed or unfinished challenge) and MappedSigningBasketProviderTest (4) pass.
• BG PIS, AIS, consent access and JSON factory suites pass (130).
• scripts/check_lift_http4s_resource_doc_parity.py and the test-isolation lint are clean; no ResourceDoc was changed.

[sonarqubecloud]

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.2% Duplication on New Code

See analysis details on SonarQube Cloud