Does a Risk Manager "Require 3D Secure" rule ever evaluate API card-on-file (merchant-initiated) payments?

Questions
1

We have a Risk Manager rule on a live US location:

  • Action: Authenticate payment with 3D Secure (3DS)
  • Payment source: Online
  • Condition: Payment amount is more than $0.01

(The condition is only there because the rule builder requires at least one
condition — we want the rule to apply to every buyer-present online payment,
with no amount threshold.)

We have two distinct payment paths against the same location.

1. Buyer present — we WANT 3DS here.
Web Payments SDK, card.tokenize(verificationDetails) with intent: 'CHARGE',
customerInitiated: true, sellerKeyedIn: false and a billingContact. The
resulting token goes to CreatePayment with
customer_details.customer_initiated = true.

2. Recurring, no buyer — 3DS is impossible here.
A scheduled server job runs once a month and calls CreatePayment with:

  • source_id = a stored card id (ccof:…), created via CreateCard with the
    source_id set to a previous payment’s id
  • customer_details.customer_initiated = false, seller_keyed_in = false
  • no browser, no buyer, no verification token

Nothing in path 2 could answer a 3DS challenge.

Questions

  1. Can the rule above ever cause the path-2 charge to be declined with
    CARD_DECLINED_VERIFICATION_REQUIRED, or otherwise require 3DS?

  2. We are relying on two statements in your documentation. Are both accurate
    and current for a Require-3DS rule scoped to the Online payment source?

    • “API card on file payments are not eligible for Square 3D Secure.”
      (Support: Use 3D Secure with Square Risk Manager)
    • “Payments initiated by sellers … will not go through 3D Secure”, and
      “If the seller initiates the payment and the buyer is not present, then
      you don’t need to verify the buyer, but instead set
      CustomerDetails.customer_initiated to false.”       (SCA overview)

  3. Is the Online payment source in a Risk Manager rule capable of matching
    a server-initiated card-on-file charge at all, or does it only match
    buyer-present Web Payments SDK transactions?

  4. Is setting customer_details.customer_initiated = false on its own
    sufficient to exempt a payment from a Require-3DS rule, or does the
    exemption depend on the card-on-file source_id as well? (We currently do
    both; we would like to know which one is actually carrying the exemption.)

  5. Risk Manager does not appear to exist in the Sandbox dashboard, so we cannot
    test any of this against a sandbox rule. Is there a supported way to test
    Risk Manager rule behaviour before it affects live payments?

Why this matters to us

Path 2 is how owner-financed land buyers are billed. If the rule intercepted
it, every buyer would fail in the same monthly run, and a 3DS decline on a
recurring charge looks exactly like a wave of declined cards — so it would read
as a customer problem rather than a configuration one.

3
  1. No, the rule will not decline path-2 charges. API card-on-file payments (ccof:… as source_id) are not eligible for Square 3D Secure (Risk Manager 3DS docs). The “Require 3D Secure” action cannot fire on them, so CARD_DECLINED_VERIFICATION_REQUIRED will not occur on path 2.
  2. Both documentation statements are accurate and current.
  3. The Online payment source does not match a server-initiated card-on-file charge. Card-on-file API payments are excluded from 3DS eligibility entirely. The Online source in Risk Manager applies to buyer-present Web Payments SDK transactions where the integration passes buyer verification details during tokenization.
  4. The card-on-file source_id is what carries the exemption. A ccof:… source is ineligible for 3DS regardless of customer_details flags. Setting customer_initiated = false is correct practice for recurring billing (it signals the network this is a merchant-initiated transaction).
  5. No, Risk Manager is not available in Sandbox. This is a known Sandbox parity gap. We recommends testing with a separate free production account.