@riocrypto/common-server 1.0.2912 → 1.0.2915

package/build/helpers/enablement-gate.d.ts

@@ -0,0 +1,29 @@
+import { ProcessorEnablementState } from "@riocrypto/common";
+/**
+ * Whether silence about a rail should be read as a refusal, for one customer in
+ * one corridor and one direction.
+ *
+ * The setting alone is not enough to answer it. Accounts are seeded and shown for
+ * the country a customer onboarded in, while an order or a quote may name any
+ * corridor we support, so a corridor where they have accepted nothing is one
+ * nobody has ever put in front of them. Reading silence as a refusal there
+ * refuses an order over an account the customer has no page to go and turn on,
+ * which is an outage of our own making rather than a decision they made.
+ *
+ * So the gate turns on with the customer's first yes in that corridor, and from
+ * then on only the rails they have accepted can carry an order. A no on its own
+ * does not turn it on: it is reachable while the direction is opt-out, where a
+ * customer can switch off the rail they were seeded with and leave the rest
+ * merely unspoken about, and those customers would otherwise be blocked the
+ * moment the direction was switched over. Their no is still honoured either way,
+ * since a disabled rail is dropped from routing whatever this returns.
+ *
+ * Lives on its own so that routing, the pages that show a customer which accounts
+ * will take their orders, and the guard that stops them switching off their last
+ * usable account all answer it the same way. Those disagreeing is what makes a
+ * customer see every account switched off while their orders route perfectly well.
+ */
+export declare const isEnablementGateActive: ({ enablement, requireExplicitEnablement, }: {
+    enablement?: Pick<ProcessorEnablementState, "enabled"> | undefined;
+    requireExplicitEnablement?: boolean | undefined;
+}) => boolean;

package/build/helpers/enablement-gate.js

@@ -0,0 +1,29 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.isEnablementGateActive = void 0;
+/**
+ * Whether silence about a rail should be read as a refusal, for one customer in
+ * one corridor and one direction.
+ *
+ * The setting alone is not enough to answer it. Accounts are seeded and shown for
+ * the country a customer onboarded in, while an order or a quote may name any
+ * corridor we support, so a corridor where they have accepted nothing is one
+ * nobody has ever put in front of them. Reading silence as a refusal there
+ * refuses an order over an account the customer has no page to go and turn on,
+ * which is an outage of our own making rather than a decision they made.
+ *
+ * So the gate turns on with the customer's first yes in that corridor, and from
+ * then on only the rails they have accepted can carry an order. A no on its own
+ * does not turn it on: it is reachable while the direction is opt-out, where a
+ * customer can switch off the rail they were seeded with and leave the rest
+ * merely unspoken about, and those customers would otherwise be blocked the
+ * moment the direction was switched over. Their no is still honoured either way,
+ * since a disabled rail is dropped from routing whatever this returns.
+ *
+ * Lives on its own so that routing, the pages that show a customer which accounts
+ * will take their orders, and the guard that stops them switching off their last
+ * usable account all answer it the same way. Those disagreeing is what makes a
+ * customer see every account switched off while their orders route perfectly well.
+ */
+const isEnablementGateActive = ({ enablement, requireExplicitEnablement, }) => Boolean(requireExplicitEnablement && (enablement === null || enablement === void 0 ? void 0 : enablement.enabled.length));
+exports.isEnablementGateActive = isEnablementGateActive;

package/build/helpers/payin-destinations.js

@@ -17,6 +17,7 @@ const fintoc_deposit_CLABE_1 = require("../models/fintoc-deposit-CLABE");
 const alfin_virtual_cci_1 = require("../models/alfin-virtual-cci");
 const processor_readiness_1 = require("../models/processor-readiness");
 const cluster_client_1 = require("../clients/cluster-client");
+const enablement_gate_1 = require("./enablement-gate");
 const processor_enablement_1 = require("./processor-enablement");
 // Rails that give each user their own destination, which therefore has to exist
 // before we can tell a customer where to pay. Every other rail is a shared house
@@ -300,12 +301,24 @@ const getPayinDestinations = ({ mongoose, user, country, fiat, processors, provi
         .select({ processor: 1, status: 1, enablement: 1 })
         .lean();
     const readinessByProcessor = new Map(readiness.map((record) => [record.processor, record]));
+    // Read through the same gate routing uses, so a customer who has accepted nothing
+    // in this corridor is shown what will really happen - every account able to take
+    // an order - rather than every account switched off while their orders route fine.
+    const gateActive = (0, enablement_gate_1.isEnablementGateActive)({
+        enablement: {
+            enabled: processors.filter((processor) => {
+                var _a, _b, _c;
+                return ((_c = (_b = (_a = readinessByProcessor.get(processor)) === null || _a === void 0 ? void 0 : _a.enablement) === null || _b === void 0 ? void 0 : _b[common_1.Side.Buy]) === null || _c === void 0 ? void 0 : _c.isEnabled) === true;
+            }),
+        },
+        requireExplicitEnablement,
+    });
     const isEnabled = (processor) => {
         var _a;
         return (0, processor_enablement_1.isProcessorEnabled)({
             enablement: (_a = readinessByProcessor.get(processor)) === null || _a === void 0 ? void 0 : _a.enablement,
             side: common_1.Side.Buy,
-            requireExplicitEnablement,
+            requireExplicitEnablement: gateActive,
         });
     };
     const destinations = [];

package/build/helpers/processor-enablement.js

@@ -12,6 +12,7 @@ Object.defineProperty(exports, "__esModule", { value: true });
 exports.ensureDefaultEnablement = exports.setProcessorEnablement = exports.getProcessorEnablementState = exports.isProcessorEnabled = void 0;
 const common_1 = require("@riocrypto/common");
 const processor_readiness_1 = require("../models/processor-readiness");
+const enablement_gate_1 = require("./enablement-gate");
 const get_processor_1 = require("./get-processor");
 // Enablement is asked per side, so the purpose is fixed by the direction rather
 // than chosen by the caller: verifications are ours to place and are never gated.
@@ -95,9 +96,18 @@ const setProcessorEnablement = ({ mongoose, userId, country, fiat, side, process
             fiat,
             side,
         });
+        // Counts an unspoken rail as usable on exactly the terms routing does, which
+        // includes a customer who has accepted nothing here yet: their unspoken rails
+        // can still carry an order, so refusing to let them switch one off would be
+        // guarding a last usable account they do not have.
         const stillUsable = [
             ...state.enabled,
-            ...(requireExplicitEnablement ? [] : state.unset),
+            ...((0, enablement_gate_1.isEnablementGateActive)({
+                enablement: state,
+                requireExplicitEnablement,
+            })
+                ? []
+                : state.unset),
         ].filter((candidate) => candidate !== processor);
         if (!stillUsable.length) {
             throw new common_1.GenericInputError(side === common_1.Side.Buy

package/build/helpers/resolve-processor.js

@@ -2,6 +2,7 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.resolveProcessor = void 0;
 const common_1 = require("@riocrypto/common");
+const enablement_gate_1 = require("./enablement-gate");
 const getRule = (config, country, fiat, purpose) => { var _a, _b; return (_b = (_a = config === null || config === void 0 ? void 0 : config[country]) === null || _a === void 0 ? void 0 : _a[fiat]) === null || _b === void 0 ? void 0 : _b[purpose]; };
 // Renormalizes over the candidates it is given rather than assuming they still
 // add up to 100, which is what lets a rail drop out - excluded by environment, or
@@ -29,9 +30,9 @@ const pickByShare = (candidates, position) => {
 // corridor rather than from the rule. What keeps an order away from a rail is the
 // customer, by switching it off or, while that direction is opt-in, by never
 // turning it on. Two exceptions: a split set to apply to all users divides the
-// corridor by percentage alone and asks nobody, and a corridor the customer has
-// no answer on record for at all is one they were never asked about, so silence
-// there is not read as a refusal.
+// corridor by percentage alone and asks nobody, and a corridor where the customer
+// has accepted nothing yet is one they were never really asked about, so silence
+// there is not read as a refusal either.
 //
 // Does no IO of its own - the routing config and the user's enablement are passed
 // in - and the only nondeterminism is the per-order roll, which a caller can
@@ -120,21 +121,21 @@ const resolveProcessor = ({ country, fiat, purpose, routingConfig, excludedProce
     const isGated = purpose !== common_1.ProcessorRoutingPurpose.BankAccountVerification;
     const disabled = isGated ? (enablement === null || enablement === void 0 ? void 0 : enablement.disabled) || [] : [];
     const unset = isGated && requireExplicitEnablement ? (enablement === null || enablement === void 0 ? void 0 : enablement.unset) || [] : [];
-    // Silence only means no in a corridor the customer has actually been asked
-    // about. Accounts are seeded and shown for the country they onboarded in, while
-    // a quote may name any corridor, so a corridor with nothing at all on record is
-    // one nobody has ever offered them rather than one they turned down. Refusing
-    // there would refuse a price over an account the customer has no page to go and
-    // turn on, so the gate stands down and the corridor routes as it did before
-    // opt-in. Anything they have answered, in either direction, puts the gate back.
-    const wasAsked = Boolean(enablement && (enablement.enabled.length || enablement.disabled.length));
     // Recorded either way, and only acted on when the split leaves the choice with
     // the customer. An order routed over their objection is the one that will be
     // asked about later, so what they had said needs to survive on the decision.
     const enablementOverridden = isGated && Boolean(rule === null || rule === void 0 ? void 0 : rule.appliesToAllUsers);
-    // Both sets are still reported below whether or not they were acted on, so a
-    // decision that routed past unspoken rails can be told from one that had none.
-    const gatedUnset = wasAsked ? unset : [];
+    // Silence is only a refusal once the customer has told us what does work in this
+    // corridor - see isEnablementGateActive. Until then the rails they have not
+    // refused are all still in play, as they were before the direction went opt-in.
+    // The unspoken set is reported below either way, so a decision that routed past
+    // one can still be told from a decision that had none to route past.
+    const gatedUnset = (0, enablement_gate_1.isEnablementGateActive)({
+        enablement,
+        requireExplicitEnablement,
+    })
+        ? unset
+        : [];
     const candidates = enablementOverridden
         ? eligible
         : eligible.filter((processor) => !disabled.includes(processor) && !gatedUnset.includes(processor));

package/build/index.d.ts

@@ -187,6 +187,7 @@ export * from "./helpers/resolve-processor";
 export * from "./helpers/get-custom-rio-bank-account";
 export * from "./helpers/payin-destinations";
 export * from "./helpers/payin-verification";
+export * from "./helpers/enablement-gate";
 export * from "./helpers/processor-enablement";
 export * from "./helpers/record-observed-processor-readiness";
 export * from "./helpers/get-bulk-payment-from-reference";

package/build/index.js

@@ -203,6 +203,7 @@ __exportStar(require("./helpers/resolve-processor"), exports);
 __exportStar(require("./helpers/get-custom-rio-bank-account"), exports);
 __exportStar(require("./helpers/payin-destinations"), exports);
 __exportStar(require("./helpers/payin-verification"), exports);
+__exportStar(require("./helpers/enablement-gate"), exports);
 __exportStar(require("./helpers/processor-enablement"), exports);
 __exportStar(require("./helpers/record-observed-processor-readiness"), exports);
 __exportStar(require("./helpers/get-bulk-payment-from-reference"), exports);

package/build/models/bank-account.js

@@ -84,6 +84,14 @@ const buildBankAccount = (mongoose) => {
             },
         },
     });
+    // Duplicate check on create. The CLABE suffix also covers the CCI and
+    // accountNumber variants, which fall back to the userId/country/fiat prefix.
+    BankAccountSchema.index({ userId: 1, country: 1, fiat: 1, CLABE: 1 });
+    // Listing a single user's accounts, newest first.
+    BankAccountSchema.index({ userId: 1, createdAt: -1, _id: -1 });
+    // Admin and cluster listing, which filters on nothing and sorts the whole
+    // collection before paginating.
+    BankAccountSchema.index({ createdAt: -1, _id: -1 });
     BankAccountSchema.statics.build = (attrs) => {
         return new BankAccount(attrs);
     };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@riocrypto/common-server",
-  "version": "1.0.2912",
+  "version": "1.0.2915",
   "description": "",
   "main": "./build/index.js",
   "types": "./build/index.d.ts",