fix(realunit): Verwendungszweck beim Buy-Confirm aus Aktionariat-Referenz liefern#3931
fix(realunit): Verwendungszweck beim Buy-Confirm aus Aktionariat-Referenz liefern#3931TaprootFreak wants to merge 2 commits into
Conversation
…renz liefern Der Quote (PUT /realunit/buy) backte buy.bankUsage als remittanceInfo UND in den QR-Code ein. Der korrekte Verwendungszweck ist aber die Aktionariat-Referenz, die erst beim Confirm (order-spezifisch mit shares+price) erzeugt wird — Kunden trugen dadurch den falschen Verwendungszweck ein, Zahlungen waren nicht zuordenbar. confirmBuy baut jetzt die autoritative Zahlungsanweisung nach Erhalt der Referenz: - remittanceInfo = Aktionariat-Referenz (der Verwendungszweck) - paymentRequest = QR-Code, der dieselbe Referenz kodiert RealUnitBuyConfirmDto um remittanceInfo + paymentRequest erweitert. Test ergänzt.
Review-Findings (Zahlungs-Sicherheit): - QR-Bau läuft nach dem irreversiblen Confirm-Commit → jetzt best-effort (try/catch): eine QR-Panne darf eine bereits bestätigte Order nicht fehlschlagen lassen; remittanceInfo wird immer zurückgegeben. - Leere/fehlende Aktionariat-Referenz wird vor dem Commit abgefangen (ServiceUnavailableException), solange die Order noch re-confirmbar ist. - Test für den Best-Effort-Pfad ergänzt.
|
Review-Subagent-Findings eingearbeitet (Commit 57ac714): QR-Bau best-effort nach dem Confirm-Commit (eine QR-Panne darf keine bereits bestätigte Order fehlschlagen lassen — remittanceInfo wird immer geliefert), Referenz-Guard vor dem Commit, Best-Effort-Test ergänzt. m5me: jest 33/33, prettier + tsc sauber. |
|
Status-Update: Der Kundenbug wird jetzt durch eine reine, abwärtskompatible App-Lösung sofort behoben (RealUnitCH/app#741) — die App nutzt die bereits heute vom Confirm gelieferte Dieser PR bleibt als Follow-up-Verbesserung offen (zurück auf Draft): er designiert |
## Problem Auf der Zahlungsdetails-Seite war der **Verwendungszweck falsch**: er kam (wie der QR) aus dem Quote (`bankUsage`). Der korrekte Verwendungszweck ist die **Aktionariat-Referenz**. ## Reine App-Lösung, abwärtskompatibel Das Confirm-Endpoint liefert **heute schon** `reference` (= die Aktionariat-Referenz = der korrekte Verwendungszweck). Dieser Fix nutzt das **ohne jede API-Änderung**: - **Verwendungszweck** = `remittanceInfo ?? reference` → heute Fallback auf `reference` (korrekt!); sobald die API `remittanceInfo` explizit liefert, wird es bevorzugt (vorwärtskompatibel). - **QR** = nur Confirm-`paymentRequest`, wenn vorhanden → heute **kein** QR (statt des **falschen** Quote-QR mit `bankUsage`!); sobald die API den korrekten QR liefert, erscheint er automatisch. - `RealUnitBuyConfirmDto`: `remittanceInfo` + `paymentRequest` nullable → kein Parse-Fehler gegen die aktuelle API. Damit ist der Kundenbug **sofort** behoben, **ohne Deploy-Kopplung**. Die Bankverbindung (IBAN/BIC/Empfänger/Betrag) kommt weiter aus dem Quote. `buyExecutedReference`-Key entfernt (ungenutzt). ## Tests `flutter analyze` sauber; `flutter test test/screens/buy test/packages/service/dfx` **grün** (564). Backward- **und** Forward-Compat-Pfad getestet (reference-only → Verwendungszweck=reference, kein QR; bzw. remittanceInfo+QR bevorzugt). Golden `buy_payment_details_default` reflektiert den heutigen Ist-Zustand (Verwendungszweck gesetzt, kein QR), regeneriert auf dem Runner. ## Verwandt (Follow-up, NICHT blockierend) DFXswiss/api#3931 designiert `remittanceInfo` explizit + liefert den korrekten QR — sobald gemergt+deployed nutzt die App das automatisch. Bug: DFXswiss/api#3929. --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
|
Rollout-Anforderung: abwärtskompatibel. Diese Änderung muss rein additiv ausgerollt werden:
Die App (RealUnitCH/app#741, bereits gemerged) ist vorwärts-/abwärtskompatibel gebaut: sie nutzt heute Bitte beim Merge/Deploy sicherstellen, dass die Additivität gewahrt bleibt (kein Breaking Change am |
1 participant
Fixt #3929.
Problem
Der Quote (
PUT /realunit/buy) setztremittanceInfo = buy.bankUsageund baut denselbenbankUsagein den QR-Code (paymentRequest) ein. Der korrekte Verwendungszweck für RealUnit-Käufe ist jedoch die Aktionariat-Referenz, die erst beim Confirm (order-spezifisch mitshares+price) erzeugt wird. Kunden trugen dadurch den falschen Verwendungszweck ein → Banküberweisungen nicht zuordenbar.Fix
confirmBuyfinalisiert die Zahlungsanweisung nach Erhalt der Aktionariat-Referenz:remittanceInfo= Aktionariat-Referenz (der Verwendungszweck)paymentRequest= QR-Code, der dieselbe Referenz kodiert (statt bankUsage)RealUnitBuyConfirmDtoumremittanceInfo(required) +paymentRequest(optional) erweitert. Der Quote bleibt unverändert; der Client rendert ab jetzt die Confirm-Felder als Verwendungszweck/QR.Tests
Neuer
confirmBuy-Spec:remittanceInfo === referenceund QR kodiert die Referenz. Lokal auf m5me validiert:realunit.service.spec32/32 grün, projektweitertsc --noEmitsauber.Cross-Consumer
Companion-App-PR (RealUnitCH/app) konsumiert die neuen Felder und rendert sie als Verwendungszweck/QR — wird nach Merge+Deploy dieser API-Änderung scharfgeschaltet (Pair-PR-Disziplin).