Checkout service DFMEA

Version: 1
Branch: DFMEA
Scope: Design-side analysis of the checkout service, its public interface, its order store, its session authentication component, and its two service dependencies, as described in checkout-inputs.md.
In boundary: checkout and the interfaces it owns; the checkout side of the payment gateway dependency; the checkout side of the pricing dependency
Out of boundary: the storefront application; the payment gateway's internals; the pricing service's internals
Security boundary: Session authentication is in scope as an ordinary element; any failure whose agent is an adversary is recorded as a handoff row to threat modeling rather than rated as a reliability failure alone.
Scales version: 1
Priority table: priority-fmea-software-v1
Created: 2026-09-01
Updated: 2026-09-03

Rows by priorityH4M4L08 failure chains Ratings not yet reviewed8 of 27provisional, in 3 rows Automated checks1 blocker10 warnings Actions8 open of 9next due 2026-10-09 Quality score88 of 100share of rows with no blocker

Needs attention

1 row fails an automated check
blocker

ch-7 D — Detection is 1 with no existing detection control carrying evidence A blocker is an automated check that must pass before the row, or the analysis as a whole, can be relied on. Fix it, then validate again.

8 ratings not yet reviewed
provisional

ch-2 S, O, D · ch-4 O, D · ch-8 S, O, D A provisional rating was suggested during the analysis and no named reviewer has re-scored it yet. The priority of these rows is not final until one does.

1 row passed to threat modelling
handoff

ch-5 A session token that this component did not issue for the current session is accepted A handoff row has an attacker as a cause. It is recorded here and handed to threat modelling, which owns the countermeasure.

Next actions due

2026-10-09 ch-4 act-1, Platform team · 2026-10-15 ch-1 act-1, Payments team · 2026-10-16 ch-8 act-1, Payments team The open actions with the earliest target dates, three at most. All actions are listed under Actions.

Contents Ground rules Assumptions Review record Structure Failure chains Actions Automated checks Provenance

Ground rules

The analysis covers the design of the checkout service and the interfaces it owns, not the storefront and not the gateway's internals.
A rating is provisional until a named reviewer re-scores it against the anchors in scales-software.md.

Assumptions

The pricing service's request ceiling is not documented in the supplied inputs; the Occurrence rating for pricing-related rows rests on exposure reasoning rather than on a stated limit. (user, open)
The storefront retries a 5xx submission at most twice with backoff, as stated in the contracts section of checkout-inputs.md. (A. Reviewer, closed)

Review record

2026-09-03 — A. Reviewer, B. Owner — Ratings on the gateway, session, contract-drift and overload rows re-scored against the anchors, and the Severity of the order-store row with them; the retry-amplification and incident-seeded rows, and the Occurrence and Detection of the order-store row, left provisional pending the payments team's input.

Structure

checkout — Checkout service [service]
Orchestrates pricing, payment authorization, and order persistence for a submitted cart.
- checkout.api — Checkout HTTP interface [interface]
  The public HTTP interface the storefront calls to submit and confirm a cart.
- checkout.payment-gateway — Payment gateway [external_dependency] (strong dependency, SLA 99.95% monthly, limits 50 rps per merchant)
  A third-party card authorization gateway reached over HTTPS.
- checkout.order-store — Order store [datastore]
  The relational store holding orders and their state transitions.
- checkout.session-auth — Session authentication [security_component]
  The session token issuer and verifier that authenticates a shopper.
pricing — Pricing service [service] (weak dependency, SLA 99.9% monthly)
Returns a priced cart for a shopper and a locale.

Failure chains

How to read this table

S, O, D: Severity, Occurrence and Detection, each rated 1 to 10 against the scales. Higher is worse: more harm, more likely, caught later or not at all.
H M L: Priority, highest first, looked up from S, O and D in the priority table. Rows are sorted by it.
RPN: S × O × D, kept for comparison with older sheets. It is not used to rank rows.
provisional: At least one rating on the row was suggested during the analysis and has not been re-scored by a named reviewer, so the row's priority is not final.
stale: The design or the scales changed after the row was rated; the row is due to be rated again.
handoff: A cause is an attacker; the row is handed to threat modelling.
blocker: The row, or the analysis as a whole, fails an automated check and cannot be relied on until it is fixed. See Automated checks.
warning: An automated check found something for a reviewer to judge; it may be acceptable as it stands.

Rows are sorted by the pre-action priority, then by severity; a row keeps its place after actions. A row id links to the row's full section below.

Priority	Row	Element	Failure mode	End effect	S	O	D	RPN	Actions
H	`ch-2` provisional	`checkout`	Retried submissions amplify load and the checkout service cascades the overload into the pricing service	Checkout stays degraded for all shoppers after the original pricing fault has cleared.	10	8	4	320	1 open due 2026-11-02
H	`ch-1`	`checkout.payment-gateway`	The authorization call exceeds its timeout budget and returns no decision	Shoppers cannot complete checkout for as long as the gateway stays degraded.	9	6	3	162	1 open due 2026-10-15
H	`ch-5` handoff	`checkout.session-auth`	A session token that this component did not issue for the current session is accepted	A subset of shoppers has orders placed and payment attempted in their name.	9	3	4	108	none
H	`ch-7` blocker	`checkout`	The service enters a sustained overload that persists after the triggering load has gone	Checkout is unavailable to all shoppers until an operator drains the queue.	9	4	1	36	1 open due 2026-11-20
M	`ch-4` provisional	`checkout.order-store`	A write is acknowledged to the caller and the order is not durably stored	Confirmed order data is lost for the affected shoppers with no path to reconstruct it from the store.	10	2	1	20	1 open due 2026-10-09
M	`ch-8` provisional	`checkout.payment-gateway`	Authorization succeeds at the gateway and the response is lost before checkout records it	A subset of shoppers is charged without receiving goods until support reverses the charge.	7	5	3	105	2 open due 2026-10-16
M	`ch-6`	`checkout.api`	A published response field changes shape and the storefront can no longer read a confirmation	Shoppers on the storefront version that broke cannot see their confirmations.	6	7	5	210	1 open due 2026-10-23
M	`ch-3`	`pricing`	The cart's last quoted price is served after the catalogue price has changed	A subset of shoppers is charged a stale price and finance carries the correction.	4	5	2	40	1 open of 2 due 2026-10-30

`ch-2` Retried submissions amplify load and the checkout service cascades the overload into the pricing service

checkout
S 10 · O 8 · D 4 · RPN 320 · provisional

FunctionTurn a submitted cart into a confirmed order exactly once

Effects

LocalThe checkout service's outbound request rate to pricing rises with every retry wave and its work queue grows.

→

Next levelPricing sheds load, checkout falls back to the last quoted price, and confirmations slow for every shopper.

→

EndCheckout stays degraded for all shoppers after the original pricing fault has cleared.

Causes

A partial pricing outage makes checkout submissions slow enough that the storefront retries them [design] trigger
Retries are issued without a budget, so the retried load is added to the offered load rather than replacing it [code]

Controls

prevention — Idempotency keys on submissions, deduplicating a retried cart (existing, evidence test_result idempotency contract suite)
compensating — Fallback to the last quoted price held in the cart when pricing does not answer (existing, evidence test_result pricing-fallback integration suite)

Ratings

Factor	Value	Rationale	Evidence	Review
S	10	The mode is a retry amplification, so the severity anchor's promotion rule takes loss of access as the worst credible class however partial the degradation looks, and the end effect reaches all shoppers, which is majority radius. The causes name the unbudgeted retry loop that keeps the state alive after the pricing fault has cleared, so there is no recovery path (N).	estimate	provisional
O	8	The sustaining loop keeps the overload alive once the trigger has passed and the service sits close to its advertised capacity during promotions, which the exposure anchor places high.	estimate	provisional
D	4	The earliest layer that reliably catches the mode is production alerting on queue depth, and the alert fires only once the loop is established.	estimate	provisional

Actions

act-1 Decide whether the storefront's retry budget or a server-side admission control is the right place to bound retried load, and record the decision in the interface contract (Checkout team, Decision pending, target 2026-11-02) acme/checkout#13 not yet read

↑ index

`ch-1` The authorization call exceeds its timeout budget and returns no decision

checkout.payment-gateway
S 9 · O 6 · D 3 · RPN 162

FunctionReturn an authorization decision for a card and an amount within the client's timeout budget

Effects

LocalThe checkout request holds an authorization attempt with no decision and abandons it at the timeout.

→

Next levelCheckout returns a retryable error to the storefront and the cart is not confirmed.

→

EndShoppers cannot complete checkout for as long as the gateway stays degraded.

TriggerA promotion drives submissions above the merchant's authorized rate at the gateway

Causes

The gateway's authorization endpoint degrades once promotion traffic passes the per-merchant rate limit [design]
The client timeout is longer than the storefront's own request budget, so the storefront gives up first [code]

Controls

compensating — Circuit breaker on gateway calls, opening after consecutive authorization timeouts (existing, evidence test_result gateway-circuit-breaker integration suite)
detection — Latency and error-rate alerting on gateway calls, paging the on-call engineer (existing, evidence observed_incident INC-2026-0314)

Ratings

Factor	Value	Rationale	Evidence	Review
S	9	The end effect is loss of checkout for all shoppers while the gateway is degraded: the top class, at majority radius, since no condition beyond reaching checkout selects who it hits. The causes name no sustaining loop, so the state ends with its trigger (H), which is the severity anchor's recoverable row at majority radius.	observed_incident `INC-2026-0314`	rescored by A. Reviewer on 2026-09-03
O	6	The trigger is exercised on every promotion and the service sits in the vulnerable state for the length of the promotion window, which the exposure anchor places in the middle band.	observed_incident `INC-2026-0314`	rescored by A. Reviewer on 2026-09-03
D	3	The earliest layer that reliably catches the mode is production alerting on gateway latency, which the detection anchor places near the middle, improved here by the latency and error-rate alerting that paged the on-call engineer during the recorded incident.	observed_incident `INC-2026-0314`	rescored by A. Reviewer on 2026-09-03

Actions

act-1 Align the gateway client timeout with the storefront request budget and publish the resulting retry policy in the interface contract (Payments team, Open, target 2026-10-15) acme/checkout#12 open, seen 2026-09-27

↑ index

`ch-5` A session token that this component did not issue for the current session is accepted

checkout.session-auth
S 9 · O 3 · D 4 · RPN 108 · handoff

Handoffthreat-model — The agent of the failure is an adversary replaying a captured token, so the countermeasure belongs to threat modeling rather than to a reliability action on this row. (adversary cause: attacker replays a captured session token)

FunctionAdmit a request only when it carries a session token this component issued and has not expired

Effects

LocalA request is admitted under another shopper's session identity.

→

Next levelCheckout prices, authorizes, and confirms a cart against the wrong shopper's account.

→

EndA subset of shoppers has orders placed and payment attempted in their name.

Causes

attacker replays a captured session token adversarial
The verifier accepts a token whose expiry claim is absent instead of rejecting it [code]

Controls

prevention — Session token signature verification on every request (existing, evidence test_result session verifier unit suite)
detection — Alert on a session token presented from two distinct client fingerprints within one session (existing, evidence estimate)

Ratings

Factor	Value	Rationale	Evidence	Review
S	9	The end effect is unauthorized ordering in a shopper's name for a subset of shoppers, an outcome the severity anchor places just below the top band because access for the majority is retained.	estimate	rescored by A. Reviewer on 2026-09-03
O	3	The vulnerable state requires a captured token, so the trigger is exercised rarely, which the exposure anchor places low.	estimate	rescored by A. Reviewer on 2026-09-03
D	4	The earliest layer that reliably catches the mode is production alerting on fingerprint divergence, which the detection anchor places in the middle.	estimate	rescored by A. Reviewer on 2026-09-03

Actions

No actions on this row.

↑ index

`ch-7` The service enters a sustained overload that persists after the triggering load has gone

checkout
S 9 · O 4 · D 1 · RPN 36 · blocker

blocker D — Detection is 1 with no existing detection control carrying evidence detection-1-without-evidenced-control

FunctionTurn a submitted cart into a confirmed order exactly once

Effects

LocalThe work queue stays full and every submission is served from behind it.

→

Next levelTimeouts and retries keep the queue full without any new offered load.

→

EndCheckout is unavailable to all shoppers until an operator drains the queue.

TriggerA burst of submissions during a promotion fills the work queue above the depth from which it can drain

Causes

Retries of timed-out submissions sustain the queue once it has filled [design]
The service has no admission control, so it accepts work it cannot finish within the client's budget [design]

Controls

detection — Queue-depth and retry-rate alerting on the checkout work queue (planned, evidence none)
prevention — Admission control that rejects submissions when the queue is above its drain threshold (planned, evidence none)

Ratings

Factor	Value	Rationale	Evidence	Review
S	9	The end effect is loss of checkout for all shoppers until an operator intervenes, which the severity anchor places at the top of the outage band short of data loss.	estimate	rescored by A. Reviewer on 2026-09-03
O	4	The trigger is exercised on promotion bursts only, though the sustaining loop makes the vulnerable state long once entered, which the exposure anchor places below the middle.	estimate	rescored by A. Reviewer on 2026-09-03
D	1	Queue depth would be visible the moment the loop starts, which the detection anchor places at the top; the alerting that would show it is not yet built, which this row records as a planned control.	estimate	rescored by A. Reviewer on 2026-09-03

Actions

act-1 Build the queue-depth and retry-rate alerting, then add admission control keyed to the drain threshold (Checkout team, Open, target 2026-11-20)

↑ index

`ch-4` A write is acknowledged to the caller and the order is not durably stored

checkout.order-store
S 10 · O 2 · D 1 · RPN 20 · provisional

FunctionDurably persist a confirmed order before acknowledging the write

Effects

LocalThe order store returns success for a row that is absent after a failover.

→

Next levelCheckout confirms an order that fulfilment never receives.

→

EndConfirmed order data is lost for the affected shoppers with no path to reconstruct it from the store.

Causes

The write path acknowledges before the replica has the row, so an unclean failover drops it [design]
The failover procedure promotes a replica without checking replication lag [specification]

Controls

detection — Write-ahead audit reconciler on checkout.order-store, comparing acknowledged writes against stored rows nightly (existing, evidence test_result reconciler failover drill)

Ratings

Factor	Value	Rationale	Evidence	Review
S	10	The end effect is loss of confirmed order data with no recovery path from the store, which is the top band of the severity anchor.	test_result `reconciler failover drill`	rescored by A. Reviewer on 2026-09-03
O	2	The vulnerable state exists only during an unclean failover of the store's primary, which the exposure anchor places near the bottom.	estimate	provisional
D	1	The nightly reconciler is an existing detection control with a drill behind it, and it catches every dropped row, which is the top of the detection anchor.	test_result `reconciler failover drill`	provisional

Actions

act-1 Require acknowledged writes to be replicated before checkout confirms the order, and gate failover on replication lag (Platform team, Implementation pending, target 2026-10-09)

↑ index

`ch-8` Authorization succeeds at the gateway and the response is lost before checkout records it

checkout.payment-gateway
S 7 · O 5 · D 3 · RPN 105 · provisional

warning act-2 — action on a chain seeded from INC-2026-0314 carries no source_incident seeded-action-without-incident

FunctionReturn an authorization decision for a card and an amount within the client's timeout budget

Seeded from incidentINC-2026-0314

Effects

LocalCheckout treats an authorized payment as failed and does not confirm the order.

→

Next levelThe shopper is charged for a cart that has no confirmed order behind it.

→

EndA subset of shoppers is charged without receiving goods until support reverses the charge.

TriggerThe gateway answers after the client's timeout has already elapsed

Causes

The gateway response is lost when the client abandons the call at its timeout [design]
No reconciliation reads the gateway's authorization list back against unconfirmed carts [specification]

Controls

detection — Daily comparison of gateway authorizations against confirmed orders (existing, evidence observed_incident INC-2026-0314)

Ratings

Factor	Value	Rationale	Evidence	Review
S	7	The end effect is a charge without goods for a subset of shoppers, reversible by support, which the severity anchor places below an outage for all shoppers.	observed_incident `INC-2026-0314`	provisional
O	5	The vulnerable window is the span between the client's timeout and the gateway's answer, entered on every timed-out authorization, which the exposure anchor places in the middle.	observed_incident `INC-2026-0314`	provisional
D	3	The daily comparison catches every occurrence, but only after the shopper has been charged, which the detection anchor places above the middle rather than at the top.	observed_incident `INC-2026-0314`	provisional

Actions

act-1 Reconcile abandoned authorizations against the gateway within the settlement window and void the ones with no confirmed order (Payments team, Open, target 2026-10-16, incident INC-2026-0314)
act-2 Show the shopper a pending state instead of a failure when an authorization times out (Checkout team, Open, target 2026-11-06)

↑ index

`ch-6` A published response field changes shape and the storefront can no longer read a confirmation

checkout.api
S 6 · O 7 · D 5 · RPN 210

warning O — Occurrence is 7 or more on an estimate with no trigger recorded occurrence-estimate-without-trigger

FunctionAccept a submission from the storefront and return a confirmation or a typed error

Effects

LocalThe interface returns a body the storefront's parser rejects.

→

Next levelThe storefront treats a confirmed order as a failed submission and retries it.

→

EndShoppers on the storefront version that broke cannot see their confirmations.

Causes

A response field is renamed without a new interface version [specification]
The contract tests cover the request shape and not the response shape [code]

Controls

detection — Contract tests on checkout.api, run in the storefront's pipeline (existing, evidence test_result storefront contract pipeline)

Ratings

Factor	Value	Rationale	Evidence	Review
S	6	The end effect blocks confirmations for a subset of shoppers on one storefront version and is recoverable by a rollback.	estimate	rescored by A. Reviewer on 2026-09-03
O	7	The vulnerable state exists on every release that touches the response shape, and no reviewer currently owns the response contract, which the exposure anchor places high.	estimate	rescored by A. Reviewer on 2026-09-03
D	5	The earliest layer that reliably catches the mode is the storefront's integration pipeline, which runs after the change is merged, in the middle of the detection anchor.	test_result `storefront contract pipeline`	rescored by A. Reviewer on 2026-09-03

Actions

act-1 Extend the contract tests to the response shape and fail the checkout build, not the storefront build, when a published field changes (Checkout team, Open, target 2026-10-23)

↑ index

`ch-3` The cart's last quoted price is served after the catalogue price has changed

pricing
S 4 · O 5 · D 2 · RPN 40
after actions: M RPN 24

FunctionReturn a current priced cart for a shopper and a locale

Effects

LocalThe checkout service prices a cart from a quote that is no longer current.

→

Next levelThe order is confirmed at a price the catalogue no longer offers and the difference is reconciled by hand.

→

EndA subset of shoppers is charged a stale price and finance carries the correction.

Causes

The fallback quote has no maximum age, so an old quote stays usable for the length of the session [specification]

Controls

detection — Cache age dashboard for the last quoted price held in the cart (existing, evidence estimate)

Ratings

Factor	Value	Rationale	Evidence	Review
S	4	The end effect is price staleness for a subset of shoppers, fully recoverable by a correction, which the severity anchor places in the lower middle.	estimate	authored by legacy-sheet-2025.csv on 2025-11-30
O	5	The vulnerable state exists whenever a price change lands during an open session, which the exposure anchor places in the middle.	estimate	authored by legacy-sheet-2025.csv on 2025-11-30
D	2	The earliest layer that reliably catches the mode is a dashboard watched during price rollouts, close to the top of the detection anchor.	estimate	authored by legacy-sheet-2025.csv on 2025-11-30

Post-action ratings — priority M, RPN 24

Factor	Value	Rationale	Evidence	Review
S	4	The end effect is unchanged by the completed action, which bounds how often the effect occurs rather than how bad it is.	estimate	rescored by A. Reviewer on 2026-09-03
O	3 (was 5)	The maximum age on the fallback quote shortens the vulnerable window to the age limit, which the exposure anchor places lower.	test_result `quote-age expiry suite`	rescored by A. Reviewer on 2026-09-03
D	2	Detection is unchanged: the dashboard is still the earliest layer that reliably catches the mode.	estimate	rescored by A. Reviewer on 2026-09-03

Actions

act-1 Give the fallback quote a maximum age and refuse to price a cart from a quote older than it (Pricing team, Completed, target 2026-08-14, completed 2026-08-15) acme/checkout#9 done, seen 2026-09-27
act-2 Emit a metric for every checkout priced from the fallback quote and alert when the share rises (Checkout team, Implementation pending, target 2026-10-30)

↑ index

Actions

Open actions first, by target date; closed actions last.

Target	Row	Action	Description	Owner	Status	Completed	Tracker
2026-10-09	`ch-4`	`act-1`	Require acknowledged writes to be replicated before checkout confirms the order, and gate failover on replication lag	Platform team	Implementation pending	—	—
2026-10-15	`ch-1`	`act-1`	Align the gateway client timeout with the storefront request budget and publish the resulting retry policy in the interface contract	Payments team	Open	—	acme/checkout#12 open, seen 2026-09-27
2026-10-16	`ch-8`	`act-1`	Reconcile abandoned authorizations against the gateway within the settlement window and void the ones with no confirmed order	Payments team	Open	—	—
2026-10-23	`ch-6`	`act-1`	Extend the contract tests to the response shape and fail the checkout build, not the storefront build, when a published field changes	Checkout team	Open	—	—
2026-10-30	`ch-3`	`act-2`	Emit a metric for every checkout priced from the fallback quote and alert when the share rises	Checkout team	Implementation pending	—	—
2026-11-02	`ch-2`	`act-1`	Decide whether the storefront's retry budget or a server-side admission control is the right place to bound retried load, and record the decision in the interface contract	Checkout team	Decision pending	—	acme/checkout#13 not yet read
2026-11-06	`ch-8`	`act-2`	Show the shopper a pending state instead of a failure when an authorization times out	Checkout team	Open	—	—
2026-11-20	`ch-7`	`act-1`	Build the queue-depth and retry-rate alerting, then add admission control keyed to the drain threshold	Checkout team	Open	—	—
2026-08-14	`ch-3`	`act-1`	Give the fallback quote a maximum age and refuse to price a cart from a quote older than it	Pricing team	Completed	2026-08-15	acme/checkout#9 done, seen 2026-09-27

Automated checks and quality score

Each time the analysis is saved, a validator script checks it against the skill's rules and records what it finds here. A blocker must be fixed before the row it names, or the analysis as a whole, can be relied on. A warning is for a reviewer to judge and may be acceptable as it stands.

Quality score: 88 of 100 — the share of chain rows with no blocker, or 0 when a blocker concerns the analysis as a whole rather than a row, or the analysis has no rows. The weighting is the skill's own.

Blockers first. Findings with the same rule and message share a line; each row location links to its row.

Severity	Rule	Where	Finding
blocker	`detection-1-without-evidenced-control`	`ch-7` D	Detection is 1 with no existing detection control carrying evidence
warning	`occurrence-estimate-without-trigger`	`ch-6` O	Occurrence is 7 or more on an estimate with no trigger recorded
warning	`rating-provisional` ×8	`ch-2` S, O, D `ch-4` O, D `ch-8` S, O, D	The rating is still provisional and needs re-scoring
warning	`seeded-action-without-incident`	`ch-8` act-2	action on a chain seeded from INC-2026-0314 carries no source_incident

Provenance appendix

Row	Catalog row	Tag	Record
`ch-1`	`cat-external_dependency-01`	`adapted-from:C014`	`C014`
`ch-2`	`cat-service-03`	`cites:C037`	`C037`
`ch-2`	`cat-service-01`	`cites:C036`	`C036`
`ch-5`	`cat-security_component-01`	`skill-authored`	—
`ch-7`	`cat-service-02`	`adapted-from:C031`	`C031`