Digital Euro Wiki

transaction-management-flows

17 min read

Transaction Management — detailed flows

Step-by-step detail for the Transaction Management (TM) domain: P2P, e-commerce, m-commerce, SoftPOS payments, refunds, balance enquiry and transaction history, plus the shared sTM-* sub-flows they all call into. Same treatment as access-management-flows and liquidity-management-flows — full coverage of source §3 “Transaction management” in src-end-to-end-process-flows (the largest of the three domains, pages 87–148), step IDs kept traceable to source.

Scope: all 10 main flows (§3.1–§3.5) and all 12 “Transaction management sub-flows” (§3.6) are covered. As with the other two domains, some referenced subprocess IDs are never themselves detailed anywhere in this document — only called by ID:

  • sTM-55 “Settlement” — the single most-referenced subprocess in this entire domain (called from every online payment flow below) — is never given its own diagram/step table. Same gap pattern as access-management-flows’s sAM-21/etc. and liquidity-management-flows’s sTM-56–.59.
  • sAM-20 “Alias resolution” and sAM-27 “Looks-up pilot PSP ID” — called from the alias/DEAN payment flows, never detailed. Plausibly DESP-hosted, near spec-alias’s getAlias/getIntermediary — not confirmed.
  • sAM-19 “Decoding of a surrogate value” — called from sTM-50 (NFC cryptogram handling), never detailed. Companion to sAM-14/sAM-18 (coding) already flagged as gaps in access-management-flows — likely also spec-sepi territory.

Two more source inconsistencies found and flagged as such (not resolved) while writing this page:

  1. The UX doc’s TM 8.A journey references end-to-end flow IDs TM-9.1, TM-9.2.2, TM-9.3, but the process-flows doc defines the identically-titled flows as TM-8.1, TM-8.2.2, TM-8.3. Treated as the same flows below (titles match exactly); the numbering drift is between document versions, not something to guess-resolve.
  2. sTM-32.10 (“Post-settlement holding limit check”) calls a subprocess named “Settlement defunding online” tagged [sLM-31] — but every other “Settlement defunding online” reference in liquidity-management-flows (LM-1.9, LM-2.1) is tagged [sTM-57]. Either a second, distinct subprocess with a coincidentally identical name, or a source typo — reported as observed, not guessed.

No wireframes extracted for sTM-* sub-flows (same as access-management-flows’s §1.4 and liquidity-management-flows’s §2.3) — only the 8 UX journeys below have one. The 8 linked pages are duplicated into wiki/assets/img/user-journey-ux-requirements/ (2026-07-22, same treatment as access-management-flows) so they sync with the publish mirror.

Quick reference

UX journeyUnderlying flow(s)Wireframe
TM 1.A – P2B SoftPOS payment via NFC (online, mobile)TM-1.6tm-page-48
TM 2.A – M-commerce SEAR seamless authentication (online, mobile)TM-2.4tm-page-51
TM 2.B – M-commerce app-to-app (online, mobile)TM-2.4 (same flow, redirect variant)tm-page-54
TM 2.C – E-commerce via alias or DEAN (online, mobile)TM-2.2tm-page-57
TM 3.B – P2P payment via NFC (offline, mobile)TM-3.4tm-page-60
TM 3.C – P2P payment via alias or DEAN (online, mobile)TM-3.5 (alias), TM-3.10 (DEAN)tm-page-63
TM 7.A – Refund on e/m-commerce (online, mobile)TM-7.2tm-page-66
TM 8.A – Information display on balance and transactionsTM-8.1, TM-8.2.2, TM-8.3tm-page-69

Verified visually (not just from text) on TM 1.A: wireframe shows separate Payer/Payee phone mockups per stage (Payer: unlock+tap; Payee: SoftPOS numeric keypad entering the amount; both: green checkmark + amount at Confirmation) — matches the text description closely, confirms text extraction wasn’t missing UI-only information for this journey.

The common online-payment backbone

Six of the ten main flows below (TM-3.5, TM-3.10, TM-2.2, TM-2.4, TM-1.6, TM-7.2) share one pipeline after their flow-specific entry steps — described once here to avoid repeating it six times:

  1. Pre-settlement (payer initiated) [sTM-34] — DESP-hosted (Eurosystem – Access Gateway Service) orchestration step that in turn calls:
    • Payer pilot PSP processing [sTM-50] — the payer PSP’s own gate: NFC cryptogram validation if applicable (sAM-19 decoding), request validation, local fraud check
      • risk score + accept/reject decision, authentication+consent [sAM-17.2] if required, balance pre-check (payer) [sTM-31], then sends the payment instruction onward.
    • Payee pilot PSP processing [sTM-51] — the payee PSP’s gate: validates the instruction, runs balance pre-check (payee) [sTM-33].
  2. Settlement [sTM-55] — DESP performs it; never itself detailed in this source (see scope note above). On rejection, funds are unlocked/restored on the payer side; on success, confirmation propagates to both sides.
  3. Debits/credits commercial bank money accounts — payer’s debit is conditional (only if reverse waterfall was needed); payee’s credit is mandatory for a business end user payee, optional for an individual end user payee (both gated by business rule LM-050-003/TM-000-006).
  4. Post-settlement holding limit check (waterfall) [sTM-32] — run separately, after settlement, specifically to catch the case where two concurrent incoming payments each individually looked fine against the holding limit but together breach it (documented explicitly in the source with a worked example, reproduced faithfully in each flow’s write-up below since it’s cited independently at each call site).

Where a flow deviates from this backbone (different entry steps, different actors, extra/fewer sub-calls), that’s called out explicitly.

§3.1 — Person-to-Person payment

TM-3.4 — Offline contactless P2P payment, mobile device to mobile device

Actors: Individual end user (Payer), Payer’s app, Payer’s offline secure application, Payee’s offline secure application, Payee’s app, Individual end user (Payee). 25 steps, TM-3.4.01–.25. The only P2P flow that doesn’t use the common backbone above — it’s fully offline, device-to-device.

  1. Payer opens app, authenticates [sAM-17.1], selects “Send Money” in the offline wallet, enters amount (.01–.04).
  2. Payer’s app sends payment data to the payer’s offline secure application, which checks the offline transaction number limit and offline balance (.05–.06, reject path .07–.10).
  3. Both devices tap: payer’s app prompts a tap (.11), payer taps payee’s device (.12–.13), forwarding payment+auth data to the payer’s offline secure application (.14); symmetrically the payee taps back (.15–.16), forwarding auth data to the payer’s offline secure application (.17 — note: routed to the payer’s side, not the payee’s, per the diagram).
  4. Mutual offline secure application authentication [sAM-17.3] (.18, device-to- device, no server) → offline settlement [sTM-42] (.19, note in source: “the order of the Payer and Payee lane has been reversed in the sub-process”).
  5. Both sides receive settlement confirmation and display payment completion independently (.20–.25).

TM-3.5 — P2P payment with alias (payer initiated)

Actors: Individual end user (Payer/Payee), Pilot PSP (Payer/Payee), DESP. 27 steps, TM-3.5.01–.27. Uses the common backbone.

  1. Payer selects “pay with beta digital euro” → method “alias” → enters transaction details → consents (.01–.04); payer’s PSP authenticates [sAM-17.1] (.05), payer sends the payment instruction (.06); PSP validates it (.07–.10, reject path).
  2. PSP requests alias resolution [sAM-20] from DESP (.11–.14, reject path) to get the payee’s DEAN + PSP ID (.15).
  3. Backbone: pre-settlement [sTM-34] → settlement [sTM-55] (.16–.17, reject path .18–.21) → confirmations both sides, payer’s optional commercial-bank debit (.22–.26) → post-settlement holding limit check (waterfall) [sTM-32] on the payee side (.27).

TM-3.10 — P2P payment with DEAN (payer initiated), same pilot PSP

Actors: same as TM-3.5. 26 steps, TM-3.10.01–.26. Structurally identical to TM-3.5 with DEAN validation replacing alias resolution:

  1. Payer selects method “DEAN”, enters details (.01–.03); PSP checks DEAN validity directly — no DESP round-trip needed for format/existence (.04–.07, reject/retry path, “the individual end user may then re-enter the DEAN”).
  2. PSP requests pilot PSP ID look-up [sAM-27] from DESP to resolve which PSP hosts that DEAN (.08–.11) — this is the one DESP call this flow needs, versus TM-3.5’s alias resolution.
  3. Payer consents, authentication [sAM-17.1] (.12–.13), sends payment instruction (.14).
  4. Same backbone as TM-3.5 from here: pre-settlement [sTM-34] → settlement [sTM-55] (.15–.16, reject path .17–.20) → confirmations, optional debit (.21–.25) → post-settlement waterfall [sTM-32] (.26).

§3.2 — E-commerce payment

TM-2.2 — E-commerce payment with alias or DEAN

Actors: Individual end user (Payer), Pilot PSP (Payer), DESP, Pilot PSP (Payee), Business end user (Payee). 42 steps, TM-2.2.01–.42 — the longest flow in this domain. Payee-initiated at the protocol level (the business end user’s checkout submits the payment request), unlike the P2P flows above which are payer-initiated throughout.

  1. Payer requests to pay at checkout, provides alias or DEAN (.01); business end user submits the payment request to their PSP (.02), which validates it (.03–.07, reject/retry path back to the payer).
  2. Branches on Alias entered? (.08): alias → alias resolution [sAM-20] (.09–.10); DEAN → pilot PSP ID look-up [sAM-27] (.11–.12); either way, reject path (.13–.15) or payee’s PSP receives the payer’s DEAN+PSP-ID details (.16).
  3. Payee’s PSP sends the payment request to DESP, which forwards it to the payer’s PSP (.17–.18); payer’s PSP validates it (.19–.20, reject path .21–.25).
  4. Payer’s PSP notifies the payer (app push notification or browser/internet-banking redirect — both paths modeled: .26–.29), authentication+consent [sAM-17.2] (.28).
  5. Backbone continues from here: pre-settlement [sTM-34] → settlement [sTM-55] (.31–.32, reject path .33–.36) → confirmations (.37–.38), payer’s optional debit for reverse waterfall (.39) → payee confirmation (.40–.41) → payee’s PSP credits the commercial bank money account directly (.42) — note: unlike the P2P flows, this flow does not route the payee-side crediting through the [sTM-32] post-settlement waterfall subprocess; it’s an inline final step, explicitly marked “mandatory in case of a business end user, optional in case of an individual end user”.

TM-2.4 — M-commerce payment (in-app)

Actors: Individual end user (Payer), Merchant app on payer’s device, Mobile app (payer), Pilot PSP (Payer), DESP, Pilot PSP (Payee), Business end user (Payee). 20 steps, TM-2.4.01–.20. Covers both TM 2.A (seamless overlay auth) and TM 2.B (app-to-app redirect) UX journeys — the underlying process is identical; only the merchant-to-wallet handoff mechanism differs at the UI layer (overlay vs. full redirect), which isn’t distinguished at the process-flow level.

  1. Payer requests to pay at checkout in the merchant app (.01); merchant app retrieves payee details (.02–.03) and redirects the payment request to the payer’s own mobile app (.04).
  2. Mobile app runs authentication+consent [sAM-17.2] (.05), submits the payment instruction — including the coded user details (the NFC-style surrogate value, even though this is an online in-app flow) to the payer’s PSP (.06).
  3. Backbone: pre-settlement [sTM-34] → settlement [sTM-55] (.07–.08, reject path .09–.13) → confirmations, mobile app displays result (.14–.16), payer’s optional debit (.17) → payee confirmation (.18–.19) → payee’s PSP credits the commercial bank money account directly (.20, same inline-not-[sTM-32] pattern as TM-2.2).

§3.3 — Point-of-Sale payment

TM-1.6 — Online contactless SoftPOS payment with mobile device, same pilot PSP

Actors: Business end user (Payee), Payee Device (SoftPOS), Individual end user (Payer), Pilot PSP (Payee), DESP, Pilot PSP (Payer). 22 steps, TM-1.6.01–.22.

  1. Payee presents amount + transaction type on the SoftPOS device (.01); payer verifies the amount and taps to pay — consent by NFC tap, no separate confirm step (.02) — note: “the payer does not share user/account details with the payee, only the previously generated surrogate value”, which must carry the payer’s PSP identifier in readable form for routing.
  2. Payee device runs authentication [sAM-17.1] and receives the consent + coded data (.03–.04), sends the payment request to the payee’s PSP (.05), which forwards it via DESP to the payer’s PSP (.06–.08).
  3. Backbone: pre-settlement [sTM-34] → settlement [sTM-55] (.09–.10, reject path .11–.15) → confirmations displayed on the payer’s app and the payee’s SoftPOS device respectively (.16–.21), payer’s optional debit (.18) → payee’s PSP credits the commercial bank money account directly (.22, again inline, same pattern as TM-2.2/TM-2.4 — waterfall crediting for a business-end-user payee is not routed through [sTM-32] in any of the payee-is-a-merchant flows).

§3.4 — Refund by business

TM-7.2 — Refund (e-commerce)

Actors: Individual end user (Payer — the original payer, refund payee), Pilot PSP (Payer), DESP, Pilot PSP (Payee — the original payee, refund payer), Business end user (Payee). 36 steps, TM-7.2.01–.36. Terminology is swapped throughout per the source’s own note: “payer and payee is swapped […] the business end user (payee) aims to pay the individual end user (payer)” — i.e. in this flow “Payer”/“Payee” columns refer to the original transaction’s roles, but the money now flows business→individual. Reverse waterfall is always required for a refund (not conditional like the payment flows above).

  1. [optional] Individual end user submits a refund request, e.g. returning goods (.01); business end user selects the transaction and validates the refund (.02–.05, reject path) — note: a coded-user-details payer may need decoding, assumed handled by the payee’s PSP on receipt.
  2. Business end user requests their PSP to process it (.06, authentication for the business end user “to be discussed in a future version” per the source); PSP validates (.07–.10, reject path) and checks the merchant’s commercial bank money account status/balance (.11–.13, reject path) — then debits or blocks the refund amount on it (.14).
  3. PSP forwards the refund request to DESP flagged for reverse waterfall, including funding details (.15, business rule LM-030-002); DESP validates it (.16–.19, reject path) and forwards to the original payer’s (= refund payee’s) PSP, which runs payer pilot PSP processing refund [sTM-49] (.20–.21) — a distinct, shorter subprocess from [sTM-50], see below.
  4. Reject path releases blocked merchant funds (.22–.25); success: DESP synchronises and sends the settlement instruction — always including the funding amount for reverse waterfall (.26) — settlement [sTM-55] (.27, reject path .28–.30) → confirmations (.31–.32) → post-settlement holding limit check (waterfall) [sTM-32] on the original-payer/refund-payee side (.33, same worked concurrent-transaction example as documented in the backbone section) → confirmations to the business end user (.34–.35) → merchant’s PSP converts the earlier block into a debit posting, or skips if already debited (.36).

§3.5 — Balance enquiry and transaction history

TM-8.1 — Balance enquiry, mobile app, online balance

Actors: Individual end user, App, Pilot PSP. 11 steps, TM-8.1.01–.11. Simple read: unlock+open app, select online balance enquiry, authentication [sAM-17.1] (.01–.03), app requests the balance from the PSP (.04, reject path .05–.08), PSP returns it and the app displays it (.09–.11).

TM-8.2.2 — Offline balance enquiry via app

Actors: Individual end user, App, Offline secure application. 12 steps, TM-8.2.2.01–.12. No PSP/DESP round-trip at all — fully local: open app, select “offline wallet → balance and transaction history enquiry” (.01–.02), offline authentication [sAM-17.4] (.03, the fully-local variant, not [sAM-17.1]), app requests balance+history from the offline secure application’s secure storage (.04, reject path .05–.08), retrieved and displayed (.09–.12).

TM-8.3 — Transaction history, mobile app

Actors: Individual end user, App, Pilot PSP. 11 steps, TM-8.3.01–.11. Same shape as TM-8.1: unlock+open, select online transaction history + optional filter, authentication [sAM-17.1] (.01–.03), request/reject/return/display (.04–.11).

§3.6 — Transaction management sub-flows

The reusable [sTM-*] subprocesses called from the main flows above.

sTM-14 — Online integrity check and transaction counter reset sub-flow

21 steps, sTM-14.01–.21. Runs periodically for offline devices (connects online via app/ATM/SoftPOS): device blocking checks first (.01–.08, e.g. against a stolen- device list — if failed, the offline device itself is blocked, not just the transaction), then compiles and forwards data through pilot PSP backend → distribution component → DESP Offline Issuance Service for the actual integrity checks (.09–.15, reject path with a “failure handling (placeholder)” step — noted in-source as not yet specified); success resets the offline transaction counter to zero, enabling a new run of consecutive offline payments (.16–.21).

sTM-42 — Offline settlement sub-flow

14 steps, sTM-42.01–.14. Called from TM-3.4’s device-to-device tap. Both sides independently validate against their own limits — payer checks the transaction number limit (.01–.06, reject path), payee checks both the holding limit and transaction number limit (.07–.10, reject path, business rule LM-011-003) — then payee confirms validation back to payer (.11), payer debits its own offline holdings (.12) and sends a credit instruction to the payee’s offline secure application, which credits itself (.13–.14). Entirely device-local — no PSP/DESP involvement, consistent with this being an offline-only sub-flow.

sTM-31 — Balance pre-check payer sub-flow

10 steps, sTM-31.01–.10. Called from sTM-50. Checks online balance and decreases it by the payment amount (or the available amount, if insufficient) (.01–.03); if funds were insufficient, checks whether reverse waterfall is activated — reject if not (.04); for pre-authorisation/reservation requests specifically, checks the pre-authorised amount against the holding limit (.05–.07); [optional, same-PSP-linked- account only] checks the linked commercial bank money account status/balance and blocks the funding amount on it (.08–.10).

sTM-33 — Balance pre-check payee sub-flow

8 steps, sTM-33.01–.08. Called from sTM-51 and sTM-49. Business end user payees skip straight to the commercial-bank check (.01); individual end user payees get a forecast balance check against the holding limit, including a check for other concurrent transactions that individually look fine but would collectively breach the limit (.02–.05, business rules TM-001-001, TM-061-001, LM-010-001, LM-011-001/.002) — if the limit would be breached, checks whether waterfall is activated, rejecting if not (.06); [optional, same-PSP-linked-account only] checks the linked commercial bank money account status (.07–.08).

sTM-34 — Pre-settlement (payer initiated) sub-flow

12 steps, sTM-34.01–.12. The backbone’s orchestration step: payer pilot PSP processing [sTM-50] (.01) → DESP validates the payment request (.02–.04, reject path forwards back to the payer, unlocking any blocked funds); [optional, only if the payee's PSP was already involved] forwards a payment-request rejection to the payee too (.05–.09) → forwards the (valid) request to the payee’s PSP → payee pilot PSP processing [sTM-51] (.10–.11) → DESP synchronises and sends the settlement instruction (.12, noting this may be a reservation-based instruction covering only part of a total reserved amount, part of a multi-capture series).

sTM-49 — Payer digital euro pilot PSP processing refund sub-flow

7 steps, sTM-49.01–.07. The refund-specific counterpart to sTM-50 — much shorter, since a refund doesn’t need fraud scoring or NFC/cryptogram handling. Validates the refund request including that the original transaction exists (.01–.02, reject path .03–.05), then — since “the payer of the original transaction is the payee of the refund” — runs balance pre-check (payee) [sTM-33] on itself, not [sTM-31] (.06), and sends the response to DESP (.07).

sTM-51 — Payee pilot PSP processing sub-flow

7 steps, sTM-51.01–.07. The backbone’s payee-side counterpart to sTM-50, much shorter — no fraud scoring, no cryptogram handling (that’s the payer side’s job). Validates the payment instruction (.01–.05, reject path), runs balance pre-check (payee) [sTM-33] (.06), sends the instruction/response to DESP — noting that in a payer-initiated transaction this is a response, not a fresh instruction (.07, including the defunding amount if waterfall is required).

sTM-52 — Payer pilot PSP processing sub-flow

8 steps, sTM-52.01–.08. Note: same title as sTM-50 but different content and domain — this one deals purely with the commercial bank money account (validate request → check account status/balance, reject if invalid or insufficient → block the funds → send confirmation + settlement details to DESP), with no digital euro balance logic at all. Not explicitly cross-referenced from any flow read so far in either the AM, LM, or TM domains — plausibly an internal building block of the still-undetailed sTM-56–.59 settlement-funding/defunding subprocesses (see liquidity-management-flows’s scope note), but that link is not confirmed in the source text.

sTM-53 — Payee pilot PSP processing sub-flow

5 steps, sTM-53.01–.05. Shortest sub-flow in the domain. Same commercial-bank-only pattern as sTM-52, payee side: validate request → check linked account status, reject if invalid → send confirmation + settlement details to DESP. Same unconfirmed-link caveat as sTM-52 above.

sTM-32 — Post-settlement holding limit check (waterfall) sub-flow, same pilot PSP

14 steps, sTM-32.01–.14. See the backbone section above for why this runs separately post-settlement (the two-concurrent-transactions worked example is reproduced there). Checks the payee’s digital euro balance against the holding limit (.01); if within limit, simply increases the balance (.02–.03); if it would be exceeded, increases the balance only up to the holding limit (.04) and checks whether this was part of a concurrent-transaction set (.05–.06) — if not part of a concurrent set, waterfall was already handled during settlement, so just credit the commercial bank account (.07); if concurrent, determines the excess amount to defund (.08), sends a defunding instruction (.09), runs settlement defunding online — tagged [sLM-31] here, see the source-inconsistency note at the top of this page (.10) — confirmation propagates back and the commercial bank account is credited (.11–.14).

sTM-29 — SoftPOS defunding of offline digital euro (sub-process)

11 steps, sTM-29.01–.11. Triggered either by an offline amount received as SoftPOS payments needing periodic defunding, or by a pilot-PSP-initiated offboarding. SoftPOS terminal submits a defunding request to the PSP’s distribution component (.01), which sends the instruction to DESP (.02); DESP runs settlement defunding offline [sTM-59] — one of liquidity-management-flows’s referenced-but-undetailed settlement IDs, called from here too (.03, reject path .04–.06) — success debits the offline holdings, displays confirmation, and credits the business end user’s commercial bank money account (.07–.11).

All journeys on this page also inherit generic-ux-requirements (authentication, error handling, feedback/positioning, accessibility — applies across all domains, not repeated per-journey here).

online-and-offline-payments · offline-payments · funding-and-defunding · liquidity-management-flows · access-management-flows · authentication · alias · dean · pilot-psp · desp · spec-sepi · spec-settlementpsp · spec-settlementdesp · generic-ux-requirements · src-end-to-end-process-flows · src-user-journeys-ux-requirements

Graph View

Backlinks