futuresens/hardlink
6
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: stream in-transaction card removal prompts

Browse Source
This commit is contained in:
yurii 2026-09-08 15:38:21 +01:00
parent 93ff67fbb1
commit afb8bb0e9e
1 changed files with 7 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
CREDITCALL_STREAMING.md
View File

@ -55,11 +55,14 @@ Confirmation continues through the existing, separate XML endpoint.
observational window. A supplied nonempty reference must match. The window opens observational window. A supplied nonempty reference must match. The window opens
immediately before the SDK start call and closes immediately at immediately before the SDK start call and closes immediately at
`TransactionFinished`; finalization never waits for card removal. `TransactionFinished`; finalization never waits for card removal.
- Unidentified `CardRemovalRequested` and `CardRemovalEnforced` updates are omitted - `CardRemovalRequested` and `CardRemovalEnforced` follow the same active-window
because they can arrive after financial completion. They require a matching rule as other progress, including when no reference is supplied. Real Miura
explicit reference. `Removed` remains omitted even with a reference. insertion-recovery sequences can repeat present-card and remove-card prompts
within one transaction; these repeated prompts are not deduplicated. Outside
the active window they are discarded. `Removed` remains omitted even with a
reference, and the existing `Inserted` mapping is unchanged.
- Ownership is best-effort UI observation. SDK 3.17 does not establish that every - Ownership is best-effort UI observation. SDK 3.17 does not establish that every
queued reference-less non-removal callback has drained before another transaction queued reference-less callback, including removal, has drained before another transaction
starts. Such a callback may briefly display stale progress in a later active starts. Such a callback may briefly display stale progress in a later active
window. This accepted limitation must never affect success, decline, cancellation, window. This accepted limitation must never affect success, decline, cancellation,
timeout outcomes, confirmation, retry, receipts, PMS posting, or business state. timeout outcomes, confirmation, retry, receipts, PMS posting, or business state.