gistfile1.txt

Hi Jak,

Not a problem, you do raise some good points. First off, I would like to point out that uniqueness of credit cards is determined across your entire gateway account, since credit cards are not linked to specific merchant accounts in the gateway. Once stored, a credit card can be used on any merchant account in the gateway, but attempting to store that card again, if you’re doing duplicate card checking, wouldn’t be possible.

Regarding the use cases you’ve brought up, they do bring some of the inherent limitations of doing duplicate checking to light. If merchants are looking to ensure that duplicate cards are kept out of their vault, they’ll have to find some way to allow for joint credit cards. One way I can think to manage this would be to find a way to allow people to link their account to someone else’s account in your application, then give them access to the other user’s payment methods. Of course, there is potential for malicious users to take advantage of this, so you would have to be extremely mindful of the security risks involved. I wouldn’t recommend this option, due to the risks involved.

You could always do your own check by storing the credit card unique identifier on your end, then checking it against the ones you already have stored to see if it matches. If it does, you can build in logic to see whether you should allow it to be stored. If it shouldn’t be stored, then you could always delete the credit card via the API.

Hopefully this information is helpful. Just let me know if there’s anything else you need.

Thanks,

Eric Nelson
Braintree Support

E: support@braintreepayments.com | P: 877.434.2894 | T: @braintree

This message was sent in reference to Braintree Case #84568.


On Apr 17, 2013 at 06:35PM CDT Jak Charlton <jakcharlton@gmail.com> wrote:

Thanks for the reply Eric!

We already present a list of cards to the customer, but dont yet have
editing capability for those cards - and we can't match the card details
just entered to the ones they have stored as again, we dont have a token to
match it against - at present the best we can do is say "sorry but youve
entered a duplicate, figure out which one and use that one" - which is less
than ideal


Your answer raises some edge case problems though - if a credit card can
only exist in the vault against one customer, then:

1) Someone else can "steal" my credit card by entering it on their account,
whereby I can no longer use my own card via Braintree

2) A general use case might be that I use my card to pay for my product,
linking the card to my account. My wife then wants to pay for a product,
and I tell her to use my card - in which case she cannot. This would also
be an issue for joint cards (which I presume will be duplicates)

Both of these issues will be made far worse if a credit card is not only
unique to a customer, but also across merchant accounts (meaning any other
site can lock out a card) - I don't think you did mean this, perhaps you
can clarify?




Jak 

On Apr 17, 2013 at 06:17PM CDT "Braintree Support" <support@braintreepayments.com> wrote:

Hi Jak,

Thanks for the question, it’s definitely an interesting one. When a card fails to be stored because it matches one that’s already stored in the vault, we don’t return information about the card/token that already exists that it matched. Logistically, this is somewhat difficult, as the card could be linked to a completely different customer in the vault and returning that customer’s information could be problematic. This would be rare, but we would want to allow for that possibility.

I would say that the ideal flow here would be to present a list of available cards to that customer when they want to add a new card, then give them the option to update their existing card or add a new card. If the create call fails because it already exists, you can inform the customer that this card is already stored, and can direct them to update the existing card instead of creating a new one.

Hopefully this helps! Please let me know if there’s anything else you need.

Thanks,

Eric Nelson
Braintree Support

E: support@braintreepayments.com | P: 877.434.2894 | T: @braintree

This message was sent in reference to Braintree Case #84568.


On Apr 17, 2013 at 05:47PM CDT Jak Charlton <jakcharlton@gmail.com> wrote:

When using fail_on_duplicate_payment_method is there any simple way of
getting back the token of the credit card it matched?

We allow a customer to enter a new payment card, but if they have
a duplicate already in the vault we either want to update that card
(perhaps they entered new Cardholder name), or delete that card and create
a new one with the new details ...

Any idea on the best way to achieve this?




def self.create_credit_card(member, credit_card_params)
result = Braintree::CreditCard.create(
customer_id: member.braintree_id,
cardholder_name: credit_card_params[:name],
number: credit_card_params[:number],
expiration_date:
"#{credit_card_params[:expiry_month]}/20#{credit_card_params[:expiry_year]}",
cvv: credit_card_params[:cvv],
options: { make_default: true, fail_on_duplicate_payment_method:
true }
)
return result.credit_card if result.success?

# deal with duplicate card in vault
# as only an error is thrown here, we really need to use the one in the
vault, but have no way of getting at it ...


[[e6c10f15a01e382