`storeInVault` option seems to have no effect

[michaelbromley]

General information

• SDK/Library version: 3.11.0
• Environment: Sandbox
• Language, language version, and OS: Node v16.15.1 on Windows 11

Issue description

I want to give my customers the option of whether to store their credit card details (when using the drop-in UI). Ideally the flow would go like this:

• get a client token from my server-side implementation
• render the drop-in
• customer enters card details. I also provide a checkbox "save these card details"
• since I'm also using a customerId when generating my client token, the default behaviour is to save the card to the vault.
• but if customer unchecks the "save card details" checkbox, I'd like to opt-out of vaulting the card.

I tried it like this:

    const response = await gateway.transaction.sale({
        customerId,
        amount: (amount / 100).toString(10),
        orderId: order.code,
        paymentMethodNonce,
        options: {
            submitForSettlement: true,
            storeInVault: saveCardDetails,   // false
            storeInVaultOnSuccess: saveCardDetails, // false
        },
    });

but the storeInVault and storeInVaultOnSuccess options seem to have no effect. It seems that, as long as I have passed a customerId when calling gateway.clientToken.generate({ customerId });, then the card will always be vaulted.

This seems to be confirmed by the discussion in this issue: https://github.com/braintree/braintree-android-drop-in/issues/39

So my question here is:

What is the intended purpose of the storeInVault option?

And to achieve the flow I want, do I just need to omit the customId when generating the client token? If so, is that considered a work-around or is that working as intended?

[Epreuve]

Hey @michaelbromley.

Since the Drop-in will automatically vault new payment methods if you use a client token with a customer ID as you've noted, and this happens prior to the server side transaction sale call, essentially what happens here is by the time the paymentMethodNonce is used in the server call, it already refers to a vaulted payment method.

Meaning as you've noted, the storeInVault & storeInVaultOnSuccess options have no effect, because it's already stored in the vault and those options have no deletion/removal behavior in that case. So it becomes a no-op.

In this case yes, it's working as intended and as an alternative, you would omit the customerId when creating a client token if you want to avoid this behavior as you suspected. If you have questions or feedback on how the Drop-in manages the auto vault feature, opening an issue in that repo is the best way to start a discussion.

[michaelbromley]

Hi @Epreuve Thanks for the explanation. OK I think then I should be able to work around this by providing the customer with a checkbox which, when changed, will re-load the dropin without passing the customerId. 👍