Monitor and Log

public class TransactionLogger {
    public static void logRejection(Id accountId, String reason) {
        System.debug(LoggingLevel.WARN, 'Transaction rejected for account ' + accountId + ': ' + reason);
        // in a real system: insert a Rejected_Transaction_Log__c record here
    }
}

Calling this from TransactionValidation's addError() branch (Lesson 6) doesn't change the rejection's behavior at all — it simply records why rejections are happening over time, so a spike in overdraft attempts, say, would be visible in aggregate rather than only ever seen one addError() message at a time.

public void execute(QueueableContext qc) {
    for (Transaction__c t : [SELECT Id, Amount__c, Type__c FROM Transaction__c WHERE Id IN :transactionIds]) {
        try {
            // ... build and send the HttpRequest from Lesson 4
        } catch (CalloutException e) {
            System.debug(LoggingLevel.ERROR, 'Ledger callout failed for transaction ' + t.Id + ': ' + e.getMessage());
            // in a real system: enqueue a retry, following Module 39's exact retry pattern
        }
    }
}

This directly reuses Module 39's payment-gateway error-handling shape — a caught, logged failure that doesn't lose the underlying record, with a retry strategy as the natural next step rather than a silent failure.

A single overdraft rejection is normal, expected system behavior — worth a debug log entry, nothing more. A sustained spike in rejections, or a ledger-callout failure rate crossing some threshold, is what should actually reach a human via Module 41's incident-response process. Distinguishing routine logging from genuine alerting keeps the signal-to-noise ratio usable — logging everything as if it's urgent trains people to ignore the alerts entirely.