Post-Auth Flow

Fires on the app.post.auth hook, after payment authorization. This is the default timing (forterAuthTiming: POST_AUTH).

sequenceDiagram
    participant Browser
    participant SFCC
    participant PSP
    participant Forter API

    Browser->>SFCC: Submit checkout
    SFCC->>PSP: Payment authorization
    PSP-->>SFCC: Auth result, order placed
    SFCC->>Forter API: POST /v3/.../orders/{orderNo}
    Note over SFCC,Forter API: app.post.auth — after payment

    alt Decline
        Forter API-->>SFCC: DECLINED
        SFCC->>SFCC: OrderMgr.failOrder()
        SFCC-->>Browser: Decline message shown
    else Approve
        Forter API-->>SFCC: APPROVED
        SFCC-->>Browser: Order confirmed
    else Not Reviewed
        Forter API-->>SFCC: NOT_REVIEWED
        SFCC-->>Browser: Order confirmed — capture held for review
    end

    SFCC->>SFCC: ForterOrderUpdateSFRA job syncs status

How it works

If the PSP controller passed a raw authorization response, it's captured onto order.custom.forterPspAuthResult. See PSP Integration Guide.

If a Pre-Auth decision exists from earlier in checkout, it's mirrored onto the order. Under PRE_AND_POST_AUTH, this step's fresh decision then replaces it. Only the latest decision is kept, in order.custom.forterDecision. See Getting the Decision onto the Order.

Forter is called with the full order data. See How Order Data Is Built and Mapped.

On a Decline with forterCancelOrderOnDecline enabled, the order is voided via OrderMgr.failOrder(). Then, the cartridge resolves the customer-facing decline message. If that resolution step fails, the order is already cancelled.

If another vendor's cartridge also registers app.post.auth, only one implementation runs. SFCC calls just the first match in the cartridge path. See Hook Contention for the escape hatch.