UC_4.10.3: Scenario A — Sim Reset (In-App)

Document References

1. Overview

2. Trigger

This UC has four independent entry points that all land on the Reset purchase modal (§9.2):

• Entry Point 1 — Dashboard (Hard Breach Popup): Status = 'Failed' after Hard Breach (Net_P&L <= −Absolute_Stop_Loss, Ref: UC_4.10.2 §2 Trigger) → Middleware fires CHALLENGE_FAILED → Flow 2 → POST /fail-challenge → Flow 7B Path A → Frontend renders Hard Breach Popup (§10.1) on every Dashboard visit until purchase → user clicks its CTA button (§5.1).
• Entry Point 2 — Account Actions screen ("Reset" button): User clicks "Reset" on the Account Actions screen → bypasses the Hard Breach Popup entirely, goes straight into pricing calculation and the purchase modal (§5.3).
• Entry Point 3 — Founding mentor case: Same downstream flow as Entry Point 2, triggered from the founding mentor context instead of Account Actions.
• Entry Point 4 — SIM Stagnation Expiration (Flow 19): expiration_date reaches days_remaining < 0 with no Time Extension purchased → Flow 19 triggers the same basic flow as Hard Breach — Status transitions to 'Failed' (Ref: UC_4.10.4 BR_4.10.4.2) → same downstream path as Entry Point 1 (Hard Breach Popup).
• Full Hard Breach flow → see UC_4.10.2

3. Pre-conditions

• User's Status = 'Failed' OR 'Active_SIM' (Ref: [CHR-40])

4. Post-conditions

Reset [CHR-59]:

• Payment successful
• trade history auto-archived → user_account_history
• Virtual balance reset to tier's starting capital (Level 1/2/5)
• Status = 'Active_SIM', expiration = Today + 60 days
• Broker-specific provisioning completes — new sub-account always provisioned, per UC_4.10.2 BR_4.10.2.7.
• User must log in with new credentials (available in Dashboard Settings).
• Success screen "Associate Track Reset Complete" displayed with CTA "Return to Dashboard" — Ref: §10.7
• User clicks "Return to Dashboard" → screen closes → Frosted Glass removed → Dashboard Day 0
• No email, no Interstitial, Auth0 untouched

5. Basic Flow

5.1 Flow "Reset Account Now" — Dashboard entry point

Step 0 — Hard Breach Popup displayed:

• After Hard Breach, Dashboard shows Frosted Glass overlay.
• Hard Breach Popup (§10.1) is rendered on top.
• This popup persists on every Dashboard visit until the trader completes a purchase.
• → Wireframe: Hard breach popup (1).png

Step 1 — User clicks CTA on Hard Breach Popup → system loads pricing:

On CTA click:

1. Compare NOW against failure_timestamp + Discount_Code_Duration_Days (Table C) — determines pricing tier only. Note: archive_date (broker-specific per UC_4.10.2 BR_4.10.2.7) governs data archival and sub-account cleanup, not pricing. The modal shown is always the Reset Modal regardless. Ref: BR_4.10.3.1 for pricing routing. [CHR-59]
2. Check user.is_founder to determine pricing tier (standard vs founder locked price). Ref: BR_4.10.3.1.
3. The Hard Breach Popup transitions to a loading state showing spinner + text "Calculating regional taxes..." → Wireframe: Calculating regional taxes.png. The frontend calls POST /calculate-cart with the full payload.
4. Final_Charge = base_price + tax_amount
5. Once POST /calculate-cart returns HTTP 200: Hard Breach Popup closes → Reset Modal (§10.2) opens with calculated pricing (price differs by archive_date check per BR_4.10.3.1; modal is always the same). [CHR-59] The promo code entry point ("Have a promo code?") is available on this modal — Ref: §6.
6. The base price displayed in the Reset Modal is the amount that will be charged — it does not change between modal open and pay click. Tax is recalculated at the moment the user clicks pay and may differ slightly from the estimate shown in the modal. Ref: §6.

Step 2 — User clicks CTA "Reset Account Now ($X)" on Reset Modal:

The system performs three gate checks in order:

Gate 1: Status IN ('Failed', 'Active_SIM') AND user is in SIM evaluation → Continue. If not → Reset Modal closes immediately, then Ref: TE-DASH-01 toast displayed. (Ref: [CHR-40] — Active_SIM added for Early Reset.)

Gate 2: Sanctions — Query billing_country + billing_region from Users table → check Compliance_geo_restrictions → If match → display 403 screen, Ref: FP-02.

Gate 3: Check Users table for customer_vault_id (NMI):

• Present → Path A: 1-Click Purchase
• Not present → Path B: Secure Checkout Fallback

Path A — 1-Click Purchase (vaulted card present): → Wireframe: Reset modal (1).png

1. The base price locks at this click; tax is recalculated at this click, not locked (Ref: §6). If the server-side price/tax re-check detects a change (e.g. tax rate updated since /calculate-cart), Ref: OV-08 renders instead of proceeding — user clicks Refresh now to reload pricing and retries. Otherwise: system charges the vaulted card via NMI. During processing: the Reset modal closes and the Processing Payment popup is displayed → Wireframe: Processing payment modal.png
2. Success:
   • Success screen "Associate Track Reset Complete" displayed → Wireframe: Payment succeed - Reset account.png — Ref: §10.7
   • User clicks CTA "Return to Dashboard" → screen closes → Frosted Glass removed → Dashboard Day 0
   • Broker-specific provisioning completes (new credentials issued per UC_4.10.2 BR_4.10.2.7) [CHR-59]. User must log in with new credentials (available in Dashboard Settings).
3. Failure: NMI returns error code (card expired, declined, insufficient funds)
   • Processing Payment popup closes → Reset modal is re-displayed with an inline banner error message (not a toast) showing the failure reason
   • User remains on the Reset modal and can retry or click "Change Payment Method" to proceed to Path C
   • Auto-fallback to Path B does NOT occur — Path B is only reached if the user clicks "Change Payment Method" (Path C)
   • All payment error handling, retry logic, idempotency, refund, double-charge prevention → see §7 Exceptional Flow — Payment flow, all standard cases.

Path B — Secure Checkout Fallback (no vaulted card): → Wireframe: Popup when users have not saved vaulted card info before.png

1. System detects no customer_vault_id → returns UI Fallback payload.
2. Frontend displays Secure Checkout page. The promo code entry point is also available here (same §6 flow, carried over from the modal that triggered this fallback).
3. User chooses payment method and completes transaction.
4. Full payment flow (form validation, processing, success/failure handling, error recovery) → see §7 Exceptional Flow — Payment flow, all standard cases.
5. On successful payment:
   • Same post-payment actions as Path A Success

Path C — Change Payment Method: → Wireframe: Change payment method.png

1. User clicks "Change Payment Method" on the modal.
2. System opens Secure Checkout page.
3. Same flow as Path B.

5.2 [Removed — CHR-59]

This section previously described a "Start New Track" flow for the expired-window case. Per [CHR-59], SIM has only one flow: the Reset flow described in §5.1. Both within-archive_date and after-archive_date cases use the same Reset modal and success screen — only the price differs, per BR_4.10.3.1. "Start New Track" is a LIVE concept; see UC_4.15.3.

5.3 Flow "Reset" via Account Actions screen (bypasses Hard Breach Popup)

Step 0 — User clicks "Reset" button on Account Actions screen:

• This button is enabled on the Account screen (Account Actions tab) whenever Status IN ('Failed', 'Active_SIM') — the Active_SIM case is the Early Reset entry point (Ref: [CHR-40]): a trader currently on an active track can voluntarily reset without waiting for Hard Breach.
• Unlike the Dashboard entry point, the Hard Breach Popup (§10.1) is not shown on this path — clicking "Reset" here goes straight to pricing calculation. See §2 Trigger for the full entry-point comparison.

Step 1 — System loads pricing:

0. Check the trader's input Status:
   • Status = 'Active_SIM' (Early Reset — Ref: [CHR-40]): skip straight to item 2 below — no archive_date check. Pricing always routes to the "Within archive_date" tier (Ref: BR_4.10.3.1). [CHR-59]
   • Status = 'Failed': continue with item 1 below (same logic as §5.1 Step 1).
1. (Failed input only) Compare NOW against failure_timestamp + Discount_Code_Duration_Days (Table C) → determines pricing window. Ref: BR_4.10.3.1 for pricing routing. Note: archive_date (broker-specific, UC_4.10.2 BR_4.10.2.7) governs data archival, not pricing.
2. Check user.is_founder to determine pricing tier (standard vs founder locked price). Ref: BR_4.10.3.1.
3. Account Actions screen shows a loading state (spinner + "Calculating regional taxes..." text) while calling POST /calculate-cart with the full payload.
4. Final_Charge = base_price + tax_amount.

Step 2 — Modal opens directly (no Hard Breach Popup in between):

• Input Status = 'Active_SIM' (Early Reset — Ref: [CHR-40]): Reset Modal (§10.2), priced at the Within-archive_date tier (Ref: BR_4.10.3.1).
• Input Status = 'Failed' (within or after archive_date): Reset Modal (§10.2), priced per BR_4.10.3.1. Both cases use the same modal; only the price differs. [CHR-59]
• The base price displayed in the modal is the amount that will be charged — it does not change between modal open and pay click. Tax is recalculated at the moment the user clicks pay and may differ slightly from the estimate shown in the modal. Ref: §6.

Step 3 onward — Identical to Dashboard entry point:

• Gate 1 (Status check), Gate 2 (Sanctions), Gate 3 (vaulted card check) → same as §5.1 Step 2 / §5.2 Step 2.
• Path A (1-Click), Path B (Secure Checkout Fallback), Path C (Change Payment Method) → same as §5.1 / §5.2.

6. Promo Code Flow

The promo code section is available on all 4 modal variants (Reset 1-Click, Reset Secure Checkout, Start New Track 1-Click, Start New Track Secure Checkout). The full flow mirrors UC_2.7.8 (Apply Promo Code at Step 6 checkout).

Price Lock and Re-validation at Pay Click:

1. The base price (Reset Fee / Full Challenge Price / locked_reset_price / locked_rebuy_price — per the 4-route matrix in §9.2) is locked when the user clicks the CTA to pay — not when the modal opens, and not when a promo code is applied. Tax is never locked — it is always recalculated server-side at the pay-click moment, on top of whichever base price applies.
2. At pay click, the backend re-validates the applied promo code atomically (Ref: BR_2.7.8.6). Price/tax check runs first — if PRICE_CHANGED is returned, Ref: OV-08 renders ("Please refresh to get the latest price") and no promo re-validation occurs for this attempt. User clicks Refresh now → modal reloads pricing → retries.
3. Promo re-validation fails at pay click (code expired or consumed between Apply and Pay by another user):

• Inline banner renders below promo input. Ref: IN-PROMO-04.
• Discount line item removed from price breakdown.
• Input field stays locked and retains the now-invalid code. [Remove] button shown — manual removal required. Input is NOT auto-cleared.
• Promo error takes effect only after price/tax check passes (step 2 above). If price changes on the same click, price error is shown instead and promo error deferred to next attempt.

4. Locked price + promo code: the discounted price via promo code applies to the base fee only. Tax is always recalculated at pay click on the discounted base (never locked). If tax changes between Apply and Pay → Ref: OV-08 triggers (see step 2).

6a. Payment Flow — All Standard Cases

The 1-Click modal flow (Reset, Start New Track, and — per UC_4.10.4 §6 — Time Extension) shares the same backend payment handling as the main checkout flow, and the Secure Checkout page (Path B/C, §7) hits the same backend paths with a different UI shell. This table is the single canonical reference for these cases — covering both UI contexts side by side — so other UCs and sections should point here rather than repeating it.

7. Exceptional Flow

• [Gate 1 fails — Status no longer 'Failed' or 'Active_SIM' at pay click]

  • Reset/Start New Track Modal closes immediately → Ref: TE-DASH-01 toast displayed. (Ref: [CHR-40])

• [Gate 2 fails — Sanctions]

  • Compliance_geo_restrictions match → 403 screen Ref: FP-02 displayed.

• [SIM provisioning failure — Reset, after payment already succeeded] [CHR-59]

  • Applies to §5.1 Step 2 Success (all cases — within or after archive_date), where broker-specific provisioning is called after the charge has already cleared. Handled with the same classify → retry → escalate pattern, Freshdesk ticket, SES-23 email, and Success Screen replacement described in UC_2.8.2 §Step 3 Exception — Ref: OV-07, SES-23, UC_2.8.4 §6 Exceptional Flow.

8. Business Rules

BR_4.10.3.1: Reset Pricing — Routing by Discount_Code_Duration_Days and is_founder

The price displayed on the Reset modal depends on two factors: Discount_Code_Duration_Days window timing (failure_timestamp + Discount_Code_Duration_Days, Table C) and is_founder status. Note: this is distinct from archive_date (broker-specific per UC_4.10.2 BR_4.10.2.7) which governs data archival and sub-account cleanup, not pricing.

Founder users pay locked_reset_price within the failure_timestamp + Discount_Code_Duration_Days window. After the window expires, the locked reset privilege expires and pricing falls back to locked_rebuy_price.

Early Reset override (input Status = 'Active_SIM' — Ref: [CHR-40]): always uses the within failure_timestamp + Discount_Code_Duration_Days pricing tier (no window check performed). is_founder pricing still applies within that tier: Founder → locked_reset_price; Standard → Reset Fee from Table J.

BR_4.10.3.2: Reset Provisioning — Always Provisions a New Sub-Account [CHR-59]

• POST /purchase-challenge-reset always provisions a new sub-account via broker-specific provisioning (Case A — before Failsafe / Case B — after Failsafe).
• Execution order within provisioning is strict: (1) Sync PostgreSQL + S3 Glacier → (2) Provision new sub-account → (3) Delete/unassign old sub-account (broker-specific).
• Full broker-specific detail (Rithmic / MT5 / TraderEvolution provisioning steps for both Case A and Case B) is documented in UC_4.10.2 BR_4.10.2.7 — the Hard Breach UC owns the broker-provisioning mechanics; this UC only triggers it via the pricing/purchase flow above.
• In all cases: wipe failed state from DB, clear trade history, reset virtual balance to tier's starting capital.
• For Early Reset (input Status = 'Active_SIM', Ref: [CHR-40]): no failed state to wipe (no-op); trade history clear and virtual balance reset still apply. Case A always applies (Active_SIM means no Failsafe has fired).

BR_4.10.3.4: Sanctions Re-Check — Real-Time, Not Cached

• Both tiers of sanctions check (POST /calculate-cart and POST /purchase-challenge-reset) query Compliance_geo_restrictions real-time using billing_country + billing_region from Users table.

BR_4.10.3.5: Auth0 Unchanged During Reset/Restart

• Auth0 session is not affected by Reset or Start New Track.
• User does NOT need to log in again.
• JWT token does not need refresh — user_id is unchanged.
• Status in DB changes from 'Failed' → 'Active_SIM' on the post-Hard-Breach path. For Early Reset (input already Status = 'Active_SIM', Ref: [CHR-40]), Status does not change.

BR_4.10.3.6: Trade History Archive at Reset

• On successful Reset purchase, trade history is auto-archived from active dashboard view → user_account_history.
• On Reset after archive_date, trade history was already archived by cron at archive_date (broker-specific per UC_4.10.2 BR_4.10.2.7). [CHR-59]
• After archive, trade history is no longer visible from the frontend (data remains in DB).
• All screens that display trade history data (including the Trade History screen, Dashboard performance widgets, and any related metrics) reset to Day 0 state upon successful Reset completion.

BR_4.10.3.8: Card Display — Brand-Aware Text Variants

The vaulted card display text on the 1-Click Modal (§10.2 item 4, §10.3 item 4) and the Processing Payment popup subtext (§10.6 item 3) renders differently based on card brand returned by NMI Customer Vault. Card brand mapping is handled on the frontend. See §10.2 item 4 for the full display list per brand.

9. Wireframe / UI

9.1 Overall Flow — Popup Sequence

The full flow when a trader with Status = 'Failed' starts a purchase, from any of the entry points described in §2 Trigger:

[Entry Point 1: Dashboard]                    [Entry Point 2: Account Actions screen]
        |                                              |
        v                                              |
[1. Hard Breach Popup]                                 |
   <- persists on every                                |
      Dashboard visit until purchase                   |
        |                                               |
        | User clicks CTA                               | User clicks "Reset" button
        | ("Reset Associate Track")                     | (Hard Breach Popup bypassed)
        |                                               |
        v                                              v
        `--------------------->  [Loading: "Calculating regional taxes..."]  <---------------------'
                                   POST /calculate-cart -> price calculated
                                                |
                                                v
[2. Reset Modal]  <- branches on vaulted card only
   |- Vaulted card present  -> Reset modal (1-Click)      [§10.2]
   `- No vaulted card       -> Secure Checkout (Reset)    [§10.4]
        |
        | User clicks CTA (Pay) on modal
        v
[3. Processing Payment popup]  <- always shown during charge (1-Click path only)
        |
   |- Success -> [4a. Success screen]                     -> User clicks "Return to Dashboard" -> Dashboard Day 0
   |             - Reset: "Associate Track Reset Complete" (all cases — CHR-59)
   `- Failure -> Back to modal (2) with inline banner error

Note: The Reset Modal is displayed immediately on Hard Breach and remains the same before and after archive_date. If the trader has not reset/rebought by archive_date, data is archived on the backend — but the modal shown on UI does not change. The Discount_Code_Duration_Days window check determines the price shown inside the Reset Modal only.

9.2 Reset Modal — 2-Variant Matrix [CHR-59]

[CHR-59] The "Start New Track" modal variants have been removed. Both within-archive_date and after-archive_date cases use the Reset modal. Price displayed differs per BR_4.10.3.1.

Frosted Glass overlay behaviour on the Dashboard (blur states, permanence, non-Dashboard screen access by sub-account lifecycle) → see UC_4.10.2.

9.3 Other Wireframe References

10. Screen Description and Business Rules

10.1 Hard Breach Popup (Dashboard Entry Point Only)

Wireframe reference: Hard breach popup (1).png

10.2 Reset Modal (1-Click) [CHR-59]

Used for all Reset purchases — both within and after archive_date. Price shown differs per BR_4.10.3.1.

Wireframe reference: Reset modal (1).png

10.3 [Removed — CHR-59]

This section previously described a "Start New Track" modal for the expired-window case. Per [CHR-59], both within-archive_date and after-archive_date cases use the Reset Modal (§10.2). See BR_4.10.3.1 for price routing.

10.4 Secure Checkout Modal (No Vaulted Card)

Wireframe reference: Popup when users have not saved vaulted card info before.png

10.5 Change Payment Method Modal

Wireframe reference: Change payment method.png

10.6 Processing Payment Popup

Wireframe reference: Processing payment modal.png

Displayed after user clicks the CTA button on the Reset Modal (§10.2). Only applies to Path A (1-Click / vaulted card)

10.7 Success Screen — Reset ("Associate Track Reset Complete")

Wireframe reference: Payment succeed - Reset account.png

10.8 [Removed — CHR-59]

This section previously described a "Track Started" success screen used after the expired-window "Start New Track" purchase. Per [CHR-59], all Reset purchases (within or after archive_date) use the "Associate Track Reset Complete" success screen (§10.7).

Changelog