Pre-Auth Flow

Fires on the app.validate.order hook, before payment authorization (forterAuthTiming: PRE_AUTH or PRE_AND_POST_AUTH). Checkout can be blocked here before the payment processor is ever called.

sequenceDiagram
    participant Browser
    participant SFCC
    participant PSP
    participant Forter API

    Browser->>SFCC: Submit checkout
    SFCC->>Forter API: POST /v3/.../orders/{preAuthOrderNo}
    Note over SFCC,Forter API: app.validate.order — before payment

    alt Decline
        Forter API-->>SFCC: DECLINED
        SFCC-->>Browser: Block checkout (no auth fee charged)
    else Approve / Not Reviewed
        Forter API-->>SFCC: decision
        SFCC->>SFCC: Decision stored on basket
        SFCC->>PSP: Payment authorization
        PSP-->>SFCC: Auth result
        SFCC->>SFCC: app.post.auth — copy decision to order
        SFCC->>SFCC: ForterOrderUpdateSFRA job syncs status
    end

How it works

SFRA's base validateOrder hook runs first. If it errors, checkout stops before any Forter logic runs.

A pre-generated order number is reserved for the basket and becomes the order's real number once checkout completes. Numbers reserved for abandoned or declined checkouts are never reused, so gaps in order numbering are expected. This works because checkoutHelpers.js overrides SFRA's base createOrder to call OrderMgr.createOrder(basket, orderNo), forcing SFCC to reuse the reserved number rather than minting a new one.

Forter is called with the basket data, using the same order-data mapping as post-auth. Since no order exists yet, fields like order status and payment transaction details are naturally incomplete at this point.

The decision is written to the basket, then mirrored into the session so it survives until the order is created. See Getting the Decision onto the Order.

On a Decline with forterCancelOrderOnDecline enabled, checkout is blocked immediately, with no order to void.