In the Braintree documentation reference https://developers.braintreepayments.com/guides/3d-secure/server-side/ruby#create-a-transaction-using-a-3d-secure-upgraded-nonce, it is stated (1**):

IMPORTANT
3D Secure information is lost when a 3D Secured payment_method_nonce is used in a Customer: Create or a Payment Method: Create call without a verify_card flag.

As far as we tested in the sandbox environment, this information is available ONLY for the response.nonce given by the client verifyCard method. https://developers.braintreepayments.com/guides/3d-secure/client-side/javascript/v3#hosted-fields
If we create another nonce from a vaulted credit card with there is no three_ds_information

result = gateway.payment_method_nonce.create("PAYMENT_METHOD_TOKEN")
nonce = result.payment_method_nonce.nonce

Now looking at our Dashboard > Vault > Verifications page:

When we store the card and we do not use verify_card: true on the server-side script, then there is no verification record created.
But If we use verify_card: true then there is a verification record for the payment method.

Navigating to verification record information:

This screen shows:

1. The amount of money that was charged to the credit card (could be $0 or $1 as documentation says).
2. The 3D Secure Information where we can see the payment method was enrolled with 3D Secure 2.1.0

Questions

About verify_card: true

• Is it mandatory to have this verify_card: true in order to have the card enrolled with 3D

  Secure? Meaning, does the warning (1**) above, enforce us to use it?
  No, it is not mandatory. It can be confusing because card verifications and 3D Secure verifications have similar names and there can be a 3D Secure verification associated with a card verification. However, card verifications are not a requirement of 3DS. A card's enrollment within 3D Secure is determined by their card-issuing bank.

  The warning is primarily to deter merchants who are trying to use 3DS-enriched nonces with payment method tokens. 3DS information cannot be directly associated with payment method tokens, as it is intended for single use. As such, it can only be associated with single transactions or card verifications (which are technically also a transaction). That is why you are seeing the 3DS information within the card verification, as opposed to directly within the payment method token.

  It is almost always more optimal to use a 3DS-enriched nonce to create a transaction directly, though for delayed billing instances or metered billing instances it may be necessary to associate the 3DS information with a card verification instead.

• By using the verify_card: true and as shown in the screenshot, as we always see in the sandbox environment only $0, is this a placeholder that can be ignored in a 3DS verification? Or is this something independent and is done no matter what?

  $0 is the default verification_amount. If you are associating the 3DS information with a verification, the verification_amount should match the amount passed in the 3DS verifyCard.

• Will the customers be really charged? or will it be a transaction to be submitted for settlement then cancelled?

  3DS verifyCard does not charge customers. However, a card verification does attempt to create an authorization for the verification_amount on the customer's bank account, which is then followed by an automatic void request.

• Is it possible to get the 3D Secure Information from the API to know which cards were enrolled in the vault? Perhaps it is payment_method.verification.three_d_secure_info but in order to use this we need to pass verify_card: true. Is there another API to get the three_d_secure_info of the card?

  You can check for a card's 3DS enrollment (and other info) via the payment method nonce, transaction, or verification response objects.

  About metered recurring transactions

• We do metered recurring payment, so we set transaction_source: 'recurring' in later transaction sales, what will be the result:
• If the payment method is subjected to SCA and
  • we use verify_card: true to create the payment_method

    The result will still ultimately depend on the card-issuing bank's decision. However, if there is a transaction or verification with 3DS information associated, subsequent recurring/unscheduled transactions are much more likely to be approved. If no transaction or verification has 3DS information, subsequent transaction attempts will more likely be 2099 declined for lack of 3DS.
    Please note, if the amount is not fixed, it may be more appropriate to pass transaction_source: unscheduled.

  • we use verify_card: false to create the payment_method

    If the payment method is not subject to requiring SCA, passing verify_card: true will ensure that a card verification is created. 3DS information should not affect whether subsequent transactions are successful with the payment method token.

    If false is passed, a card verification will not occur when vaulting the payment method. This will prevent other fraud tools such as AVS or CVV from applying before storing the payment method.

• If the payment method is not subjected to SCA and
  • we use verify_card: true to create the payment_method
  • we use verify_card: false to create the payment_method
    ?