Client Token Inconsistencies

[m-s-morgan]

General information

• SDK/Library version: 7.4.0
• Environment: Sandbox
• iOS Version and Device: iOS 12.4.1 iPhone X
• Integration type and version: Carthage 0.33.0

Issue description

I wanted to create a new issue for this because I can't seem to find a great workaround and am currently stuck with an incomplete solution using the Drop-in SDK. The major problem seems to stem from the fact that the SDK wants to vault payment methods on the client-side by default when using a client token. A new customer will obviously not have a customer ID attached to this client token seemingly making vaulting on the client impossible. This causes an error when attempting to use Venmo as a payment option as the SDK will error with "Failed to store Venmo Account in vault." A tokenization key could be used to instead not vault the payment method on the client, but then 3DS cannot be used. I could be completely wrong, but the simplest solution to support everything would seem to be using a client token for everything, since we do not know which payment method the customer is going to select using the drop-in SDK. However, I'd like to be able to have the option to not vault anything on the client side, and leave the vaulting to be done on the server only. If there's a way to specify this somehow and still use the drop-in SDK, awesome. Otherwise, I suppose this would be a feature request. Thanks!

[scannillo]

A new customer will obviously not have a customer ID attached to this client token seemingly making vaulting on the client impossible.

For first time customers, you can create a customer to generate a customerID for future use on your server. Vaulting on the client will then be possible since you now have a customerID associated with this customer. But yes, the drop-in client won't handle creating customerIDs for you.

This causes an error when attempting to use Venmo as a payment option as the SDK will error with "Failed to store Venmo Account in vault."

Where is this error being returned to you? It should not return an error in the completion of BTDropInRequest's initWithAuthorization. You should still receive a result with a nonce and be able to properly continue on to transact even if vaulting didn't occur. Elaborate more though on this error if it is actually causing your integration to break.

I'd like to be able to have the option to not vault anything on the client side, and leave the vaulting to be done on the server only

You are correct that our drop-in is automatically attempting vaulting Venmo payments if a customerID is present. We currently don't offer a way to opt-out of this vaulting if a customerID is included in the clientToken, but this feature request is on our radar!

If there's a way to specify this somehow and still use the drop-in SDK

If you want to handle vaulting on the server, you can! If the client-SDK attempts to vault a payment method that already exists for a customerID, it will not be replicated in their vault, so you don't have to worry about that.

[m-s-morgan]

@scannillo the error is bubbled up through the drop-in SDK. I'm assuming it's being generated in the Braintree iOS SDK when it attempts to vault the Venmo payment info on the client with a client token that was initialized WITHOUT a customer ID.

Steps to reproduce would be:

1. Initialize the drop-in with a client token that was created WITHOUT a customer ID
2. Present the drop-in
3. Select Venmo and authorize
4. The error is thrown

[scannillo]

Thanks for providing steps to replicate! I was able to replicate the error you get.

For your development purposes for now, using a tokenizationKey works fine.

But our team will dig into this and work on an update!

[m-s-morgan]

@scannillo we are temporarily using a tokenization key but this prevents us from supporting 3DS. A great fix for our purposes would be to allow an option for the drop-in that tells it to NOT vault any payment method on the client side. But I realize you all have to support the greatest number of use cases, so please keep me informed on any updates to this. Thanks for the help.

[piclez]

I think I'm experiencing the same problem!

[scannillo]

A fix for this was released in v8.1.0.

You can opt in our out of venmo vaulting by setting the vaultVenmo boolean on BTDropInRequest. https://github.com/braintree/braintree-ios-drop-in/blob/b43cd163a2642aa21be40cac2695d97d25eb176a/BraintreeDropIn/Public/BTDropInRequest.h#L66-L68

[piclez]

Thank you! Do you also replicate this change for Android Drop In?

[scannillo]

@piclez No, vaulting on Venmo for Android Drop-In has not been implemented. See this GitHub issue.

However - this is something we will add to our roadmap and you can use the linked issue above to track the feature's progress in Android. Thank you!