@cfxlabsinc/b2b-services
    Preparing search index...

    Rule CRUD for customer admins, and requirementsFor, which the payment confirm flow calls to learn what approval a payment needs. Recording the transactionApprovalRule.* activities is the caller's job, as for every other dashboard action (createUserActivity).

    Index
    db: B2bDatabase
    instance: (...args: []) => TransactionApprovalRuleService = ...

    The process default: built from each dependency's own instance().

    • The approval a payment needs: the steps of every ACTIVE rule that matches, grouped by rule name. A rule matches when every key it sets matches (productIds and categories on the payment's product, minAmountUsd against the BE-6 figure, inclusive). A payment with no USD figure (target amount only) matches an amount rule, so dual control is never bypassed.

      approverKeys are what the rail's confirm action checks, plus transactions/metadata:w: an approver executes the payment. The requester never counts as an approver (D4).

      Parameters

      • __namedParameters: {
            amount: { source: BigNumber } | { target: BigNumber } | null;
            approverKeys: string[];
            customerId: string;
            productId: string;
            quote: { sourceAmount: BigNumber } | null;
            requesterId: string;
            source: TransactionApprovalSource;
        }

      Returns Promise<
          | { ok: true; value: TransactionApprovalRequirements }
          | { error: ServiceError; ok: false },
      >

    • Parameters

      • __namedParameters: {
            customerId: string;
            ids?: string[];
            page?: number;
            pageSize?: number;
            statuses?: ("ACTIVE" | "DISABLED")[];
        }

      Returns Promise<
          {
              ok: true;
              value: {
                  hasNext: boolean;
                  items: TransactionApprovalRule[];
                  total: number;
              };
          },
      >