UnlockOS Developers
← 記事一覧に戻る
🛡️

金融入金処理における堅牢なエラーハンドリング

2026年6月8日2026年6月14日
6
4 commits
深度 7/10
error-handlingtestingtypescriptreliability

金融入金処理における堅牢なエラーハンドリング

はじめに

スマートロック管理のようなセキュリティが重要なシステムにおいて、金融取引の処理には完璧なエラーハンドリングと包括的なテストが必要です。入金処理の最近の改善では、適切なエラー分離と行動テストが、物件アクセスを危険にさらす可能性のある連鎖障害をどのように防ぐかが実証されています。

課題:アクセス制御における入金処理

ゲストが物件にチェックインする際、ロックアクセスを許可する前に入金認証が正常に完了する必要があります。このフローでの単一の障害は、以下のいずれかの結果を招く可能性があります:

  • 正当なアクセスをブロックする(可用性への影響)
  • 不正なアクセスを許可する(セキュリティへの影響)

これにより、入金処理は堅牢なエラーハンドリングが必要な重要なセキュリティ境界となります。

複雑なロジックのテスト可能なヘルパーへの抽出

大きなワークフローに組み込まれた複雑なビジネスロジックは、包括的にテストすることが困難になります。解決策は、焦点を絞った行動テスト済みヘルパーへの抽出です:

interface DepositGatingResult {
  success: boolean;
  errorCode?: string;
  retryable: boolean;
  auditTrail: string[];
}

class DepositGatingService {
  async validateDepositRequirement(
    booking: BookingDetails,
    paymentMethod: PaymentMethod
  ): Promise<DepositGatingResult> {
    const auditTrail: string[] = [];
    
    try {
      // Pre-authorization validation
      const preAuthResult = await this.preAuthorizeDeposit(
        paymentMethod, 
        booking.depositAmount
      );
      
      auditTrail.push(`Pre-auth: ${preAuthResult.status}`);
      
      if (!preAuthResult.success) {
        return {
          success: false,
          errorCode: preAuthResult.errorCode,
          retryable: this.isRetryableError(preAuthResult.errorCode),
          auditTrail
        };
      }
      
      return {
        success: true,
        retryable: false,
        auditTrail
      };
    } catch (error) {
      auditTrail.push(`Exception: ${error.message}`);
      
      return {
        success: false,
        errorCode: 'INTERNAL_ERROR',
        retryable: true,
        auditTrail
      };
    }
  }
  
  private isRetryableError(errorCode: string): boolean {
    const retryableCodes = [
      'NETWORK_TIMEOUT',
      'SERVICE_UNAVAILABLE',
      'RATE_LIMIT_EXCEEDED'
    ];
    return retryableCodes.includes(errorCode);
  }
}

包括的な行動テスト

行動テストは実装の詳細ではなく結果に焦点を当てるため、リファクタリングに対してより耐性のあるテストを作成できます:

describe('DepositGatingService', () => {
  let service: DepositGatingService;
  let mockPaymentProvider: jest.Mocked<PaymentProvider>;
  
  beforeEach(() => {
    mockPaymentProvider = createMockPaymentProvider();
    service = new DepositGatingService(mockPaymentProvider);
  });
  
  describe('when payment provider is unavailable', () => {
    it('should return retryable failure with audit trail', async () => {
      mockPaymentProvider.preAuthorize.mockRejectedValue(
        new Error('Service unavailable')
      );
      
      const result = await service.validateDepositRequirement(
        mockBooking,
        mockPaymentMethod
      );
      
      expect(result).toMatchObject({
        success: false,
        errorCode: 'INTERNAL_ERROR',
        retryable: true
      });
      
      expect(result.auditTrail).toContain(
        'Exception: Service unavailable'
      );
    });
  });
  
  describe('when insufficient funds', () => {
    it('should return non-retryable failure', async () => {
      mockPaymentProvider.preAuthorize.mockResolvedValue({
        success: false,
        errorCode: 'INSUFFICIENT_FUNDS'
      });
      
      const result = await service.validateDepositRequirement(
        mockBooking,
        mockPaymentMethod
      );
      
      expect(result.retryable).toBe(false);
    });
  });
});

デバッグのための戦略的エラーログ

適切なエラーログは、運用チームが機密データを公開することなく問題を迅速に特定し解決するのに役立ちます:

class CheckinOrchestrator {
  async processCheckin(booking: BookingDetails): Promise<CheckinResult> {
    try {
      const depositResult = await this.depositService.validateDepositRequirement(
        booking,
        booking.paymentMethod
      );
      
      if (!depositResult.success) {
        // Log failure with context but not sensitive data
        this.logger.error('Deposit validation failed during checkin', {
          bookingId: booking.id,
          errorCode: depositResult.errorCode,
          retryable: depositResult.retryable,
          auditTrail: depositResult.auditTrail,
          // Exclude sensitive payment method details
        });
        
        return {
          success: false,
          stage: 'DEPOSIT_VALIDATION',
          userMessage: this.getUserFriendlyMessage(depositResult.errorCode),
          retryable: depositResult.retryable
        };
      }
      
      // Continue with lock access provisioning
      return await this.provisionLockAccess(booking);
      
    } catch (error) {
      this.logger.error('Unexpected error in checkin process', {
        bookingId: booking.id,
        error: error.message,
        stack: error.stack
      });
      
      return {
        success: false,
        stage: 'UNKNOWN',
        userMessage: 'Please contact support',
        retryable: true
      };
    }
  }
}

エラー復旧戦略

異なるエラータイプには、異なる復旧戦略が必要です:

interface ErrorRecoveryStrategy {
  maxRetries: number;
  backoffMs: number;
  fallbackAction?: () => Promise<void>;
}

class ResilientDepositProcessor {
  private recoveryStrategies: Map<string, ErrorRecoveryStrategy> = new Map([
    ['NETWORK_TIMEOUT', { maxRetries: 3, backoffMs: 1000 }],
    ['RATE_LIMIT_EXCEEDED', { maxRetries: 2, backoffMs: 5000 }],
    ['INSUFFICIENT_FUNDS', { 
      maxRetries: 0, 
      backoffMs: 0,
      fallbackAction: () => this.notifyGuestOfPaymentIssue()
    }]
  ]);
  
  async processWithRecovery(
    booking: BookingDetails
  ): Promise<DepositGatingResult> {
    let attempt = 0;
    
    while (attempt < 3) {
      const result = await this.depositService.validateDepositRequirement(
        booking,
        booking.paymentMethod
      );
      
      if (result.success) {
        return result;
      }
      
      const strategy = this.recoveryStrategies.get(result.errorCode!);
      
      if (!strategy || !result.retryable || attempt >= strategy.maxRetries) {
        if (strategy?.fallbackAction) {
          await strategy.fallbackAction();
        }
        return result;
      }
      
      await this.sleep(strategy.backoffMs * Math.pow(2, attempt));
      attempt++;
    }
    
    throw new Error('Max retry attempts exceeded');
  }
}

OAuthセキュリティドキュメント

Google Calendarのような外部サービスと統合する際、透明性のあるセキュリティドキュメントがユーザーの信頼を構築します:

// Required OAuth scopes with clear justification
const REQUIRED_SCOPES = {
  'https://www.googleapis.com/auth/calendar.readonly': {
    purpose: 'Read guest calendar events to prevent booking conflicts',
    dataAccessed: 'Event titles, times, and availability status',
    retention: 'Not stored - used only for real-time availability checks'
  },
  'https://www.googleapis.com/auth/calendar.calendars.readonly': {
    purpose: 'List available calendars for booking integration',
    dataAccessed: 'Calendar names and IDs',
    retention: 'Cached for 24 hours to improve performance'
  }
} as const;

まとめ

セキュリティが重要なシステムにおける堅牢なエラーハンドリングには以下が必要です:

  1. 複雑なロジックの分離:焦点を絞ったテスト可能なコンポーネントへの分離
  2. 行動テスト:すべてのエラーシナリオにわたって結果を検証
  3. 戦略的ログ:機密データを公開することなくデバッグを支援
  4. 差別化された復旧戦略:エラータイプと影響に基づく戦略
  5. 透明性のあるセキュリティドキュメント:外部統合のため

エラーハンドリングを第一級の設計関心事として扱うことで、悪条件下でも優雅に失敗し、セキュリティ境界を維持するシステムを構築できます。

主要な発見

1
エラーハンドリング

金融フローの行動テスト

実装の詳細ではなく入金処理の結果をテストすることで、より耐性のあるテストスイートを作成

2
信頼性

差別化された復旧戦略

異なるエラータイプには、システムの可用性を維持するための特定のリトライポリシーとフォールバックアクションが必要

3
セキュリティ

セキュアなエラーログ

機密データを除外した包括的な監査証跡により、プライバシーを維持しながら効果的なデバッグが可能

4
テスト

重要なビジネスロジックの抽出

複雑な金融検証ロジックを焦点を絞ったヘルパーに分離することで、テストの可能性と信頼性が向上