@riocrypto/common-server 1.0.2911 → 1.0.2912

package/build/helpers/resolve-processor.js

@@ -28,8 +28,10 @@ const pickByShare = (candidates, position) => {
 // the only one available to them, which is why the candidate set comes from the
 // 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. Unless the rule says otherwise: a split set to apply to all
-// users divides the corridor by percentage alone and asks nobody.
+// 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.
 //
 // 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
@@ -118,13 +120,24 @@ 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 : [];
     const candidates = enablementOverridden
         ? eligible
-        : eligible.filter((processor) => !disabled.includes(processor) && !unset.includes(processor));
+        : eligible.filter((processor) => !disabled.includes(processor) && !gatedUnset.includes(processor));
     // What was filtered, carried by every decision below. Kept in one place so a
     // branch cannot quietly stop reporting one of them, since these sets are the
     // whole reason a decision can still be explained weeks later.
@@ -136,7 +149,7 @@ const resolveProcessor = ({ country, fiat, purpose, routingConfig, excludedProce
             // their rails off and can turn one back on; the other has never told us
             // which account their bank will let them pay, and needs to whitelist one
             // before anything can be routed.
-            reason: unset.length
+            reason: gatedUnset.length
                 ? common_1.RoutingDecisionReason.NoAcceptedCandidate
                 : common_1.RoutingDecisionReason.NoEnabledCandidate }, filtered), { decidedAt });
     }

package/package.json

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