Closed alexbrashear closed 6 years ago
@alexbrashear Thanks for reaching out.
Are you using a tokenization key
OR client token
WITHOUT a customer in production? And is it different than what you use in your sandbox testing?
At the moment, Drop-in will always attempt to vault
Venmo, which fails when using either of the above methods. We're working on a release to fix this issue (which won't vault when using a tokenization key
). If that isn't the case, we can dig a little deeper.
Hey @demerino thanks for getting back to me!
I am using a client token
, when you say without a customer in production what do you mean? Currently we have no customers in production, when I tried to pay with venmo I did it when I did not yet have a valid customer ID.
Will it also not vault when using a client token
or will this release just fix for the tokenization key
? Is there anything I can do now to avoid this issue?
If you're not using a customer
then I'd suggest using a tokenization key
. Are there reasons you are using a client token
instead of a tokenization key
?
So my understanding is that we need a client token to store the users payment information.
Basically I generate a token to open the drop in UI and when they make a purchase i store their customerID in the keychain so we have it next time we need to create a token. That way their old credit card or whatever shows up as a previously used method of payment.
We don’t ever store the customerID in a server tho, we store users separately and without any payment information.
If we use the tokenization key will the user be able to pay with a payment method they used previously with the drop in UI (assuming they don’t delete the app)?
On Wed, Nov 8, 2017 at 5:09 PM David Merino notifications@github.com wrote:
If you're not using a customer then I'd suggest using a tokenization key. Are there reasons you are using a client token instead of a tokenization key?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/braintree/braintree-ios-drop-in/issues/61#issuecomment-342977584, or mute the thread https://github.com/notifications/unsubscribe-auth/AFKM2WTty15CQTqvkfmyh2jEmnol7-q0ks5s0iavgaJpZM4QV59a .
Hmmm, if you are using a Client Token with a customer, then it is unrelated to the bug I mentioned above. You probably are using a customer when you generate the Client Token if you're seeing previously used payment methods.
Something like this: https://developers.braintreepayments.com/reference/request/client-token/generate/java#customer_id
That is how Drop-in is able to know which payment methods to fetch.
If that is not the issue, then I'm curious why you're not getting a callback. Try putting breakpoints in the Venmo Driver that should handle the return: https://github.com/braintree/braintree_ios/blob/master/BraintreeVenmo/BTVenmoDriver.m#L236-L240
Hey @demerino set a couple breakpoints in the Venmo Driver - here is what I found:
It looks like the error is happening when it tries to vault the venmo account information.
- (void)vaultVenmoAccountNonce:(NSString *)nonce {
NSMutableDictionary *params = [NSMutableDictionary new];
params[@"venmoAccount"] = @{
@"nonce": nonce
};
[self.apiClient POST:@"v1/payment_methods/venmo_accounts"
parameters:params
completion:^(BTJSON *body, __unused NSHTTPURLResponse *response, NSError *error) {
[self informDelegateWillProcessAppSwitchReturn];
if (error) {
[self.apiClient sendAnalyticsEvent:@"ios.pay-with-venmo.vault.failure"];
self.appSwitchCompletionBlock(nil, error);
} else {
[self.apiClient sendAnalyticsEvent:@"ios.pay-with-venmo.vault.success"];
BTJSON *venmoAccountJson = body[@"venmoAccounts"][0];
self.appSwitchCompletionBlock([BTVenmoAccountNonce venmoAccountWithJSON:venmoAccountJson], venmoAccountJson.asError);
}
self.appSwitchCompletionBlock = nil;
}];
}
It errors out and then sends back nil
in the completion instead of the nonce. Any ideas why this might be happening?
We've pushed out a fix if you use a Tokenization Key. You should ensure that your Client Token was created with a customer if you intend to display previously used payment methods.
Closing, let us know if you still have issues.
General information
Issue description
Im having trouble debugging an issue where I tap Venmo in the Drop in UI, it goes to Venmo, I authorize Venmo and it appears to be successful. It then returns to my app, but it is still on the list of payment methods in the drop in UI and nothing seems to have happened. Tapping Venmo again will again take me to the Venmo app and request to authorize (did it silently fail or something?) I put a break point on the return statement here and it is triggered on returning to the app.
Breakpoints in the
BTDropInControllerHandler
are not though. Venmo was working for me in the Sandbox environment - when I performed this same operation it came back with the "venmojoe" user which I guess was a test.Any help you could give me in debugging this issue would be much appreciated - thanks!