Plaid v2: per-product avg transaction size → bps Transfer revenue

Ports v1's per-product avg transaction size input into v2 and wires it into the bps/percent Transfer revenue formula, so percent-priced transfers price off real dollar volume instead of transaction count alone.

1. Why this exists

v1's Product Selection collects a per-product avg transaction size on every bps / percent / dynamic Transfer card. That value is the difference between pricing a transfer at 5 bps × 1000 txns × $200/txn (= $100k of revenue) and pricing it at 5 bps × 1000 txns (= $50 of revenue — meaningless).

v2 inherited the variable name but not the wiring. avgTransactionSize existed as a quote-level static currency with value: 0, used only by the Signal 3x-crypto list-price predicate. No UI input, no revenue multiply. Percent-priced Transfer revenue therefore landed orders of magnitude too low.

2. The two-marker design

The PR introduces two booleans on calculationSpec. They live on different SKUs because the FE input and the revenue multiply have different scopes.

3. Before / after revenue math

SKU coverage matrix

4. The product-scoped avgTransactionSize term

Reshaping avgTransactionSize from a quote-level static currency into a per-product formula variable follows the existing Xendit pattern (variables/xendit/registry.ts). The variable now resolves through a four-step fallback at evaluation time:

5. The engine multiply

The multiply is a single helper added to the generic engine flat path in pricingEngineService.ts, applied at three call sites (two recurring branches + the absolute month_idx branch). It's gated solely on the revenue marker:

const applyAvgTxnSizeMultiply = (flatRevenue: number): number => {
  if (!productSpec.calculationSpec.multiplyRevenueByTransactionSize)
    return flatRevenue;
  const txnSizeTerm = getTerm(productAttr, 'avgTransactionSize');
  const avgTxnSize =
    txnSizeTerm?.type === 'currency' ? txnSizeTerm.value : 0;
  if (!avgTxnSize) return flatRevenue; // v1 fallback: no txn size → plain revenue
  return flatRevenue * avgTxnSize * 0.01;
};

Three things to notice:

• Revenue-only. The displayed per-unit bps price is unchanged. Only the computed revenue number moves.
• v1's if (transactionSize) guard is preserved. When the marker is set but the term is 0 or missing, revenue falls back to count × price rather than collapsing to zero.
• productAttr is product-scoped. The helper threads product and productSpec into the attr so getTerm can hit the per-product override first.

6. UI wiring in pricingFlowSpec.json

A new column is added to the Transfer product-table, scoped via visibleForCategories: ["transfer"]:

{
  "term": {
    "id": "avgTransactionSizeRow",
    "variableId": "avgTransactionSize",
    "isUserEditable": true,
    "uiConfig": {
      "type": "currency",
      "title": "Avg. Txn Size",
      "align": "right",
      "simpleInput": true,
      "validation": { "min": 0, "precision": 0 }
    }
  },
  "visibleForCategories": ["transfer"],
  "width": "150px",
  "maxInputWidth": 117
}

The column shows on the whole Transfer category — finer per-row gating (showing it only on bps + dynamic rows, hiding on flat-fee rows in the same category) is the explicit scope of follow-up dealops-9v3.

7. What it doesn't change

8. Test coverage

The engine spec is written Jest-style; the registry and schema specs are Mocha — consistent with the package's mixed test conventions (new tests default to Mocha; the engine file uses Jest because its sibling specs already do).

9. Risks & open questions