0

Braintree API returns various internal IDs to business objects including IDs of Subscription, Plan, PaymentMethod, and such. Are there any security issues in sharing these IDs with end-users' applications (the front-end code running on users' devices)? (The end-user would not see these IDs, but they would be transmitted through the wire.)

Detailed example:

The user adds a payment method to the App. The App server forwards the request to Braintree, for example:

val result = gateway.paymentMethod.create(
            new PaymentMethodRequest()
              .customerId(user.billing.get.braintree.customerID)
              .paymentMethodNonce(nonce)
              .billingAddressId(user.billing.get.braintree.addressID.get)
              .options()
              .makeDefault(true)
              .verifyCard(true)
              .failOnDuplicatePaymentMethod(false)
              .done()
          )

Then the result is handled as follows:

Option(result.getTarget)
            .map {
              case card: CreditCard =>
                braintreePaymentMethod(
                  card.getClass.getCanonicalName,
                  card.getToken,
                  card.getImageUrl,
                  card.isDefault,
                  "ending " + card.getLast4
                )
            }
            .getOrElse(throw Payments.Exception.Braintree(result.getMessage))

The card.getToken returns the payment method's token as in interface:


public interface PaymentMethod {

    String getToken();
    boolean isDefault();
    String getImageUrl();
    String getCustomerId();
    List<Subscription> getSubscriptions();
}

The above token acquired by getToken is then used to check the existence of the payment method, moreover, used to remove, list and update the method.

Internally, in the App, this token could also be used to identify the payment method.

Recap: Are there any security issues to share this token with the user?

Dyin
  • 5,815
  • 8
  • 44
  • 69

3 Answers3

1

Braintree identifiers and tokens aren't interesting or relevant to users. There is no reason to share them. The last 4 of the card is all you need to show for their later reference purposes.

Preston PHX
  • 27,642
  • 4
  • 24
  • 44
  • Sure, but when a user wishes to delete a payment method or address, how will the user tell you which payment method or address to delete? In other words, what is your identifier? But I think we have a misunderstanding: by "sharing the token with the user" I mean to share it with the program running on the client-side (Angular application for example), not with the human itself. – Dyin Sep 06 '20 at 19:23
  • Well you said "end users" when you meant "the client side" – Preston PHX Sep 06 '20 at 19:26
  • Well yes, I apologize, I should correct that. Do you have any thoughts on that? – Dyin Sep 07 '20 at 08:35
  • Should be fine, as I understand it they're encrypted hashes that can only be used in an authorized API call to Braintree (from your server) – Preston PHX Sep 07 '20 at 18:59
1

I don't see any point in sharing the braintree identifiers with users.

If you want to provide some functionality over those payments or address then these should go through your api.

Ideally, you should not expose the braintree domain model directly to the users (this is standard pactice for almost every third party domain model). You can create your own domain model on top of braintree domain model. All of your api's will revolve around your domain model which will proxy for braintree domain model.

sarveshseri
  • 13,738
  • 28
  • 47
  • Thanks for your ideas! The domain model is not shared directly. Only identifiers. Since the API can only manipulate Braintree objects using their identifier, the API would have to use two identifiers (in case it is encouraged not to share the Braintree IDs). The API would then have to provide a different ID for the client for the payment method, then match it with the Braintree IDs. Sounds like double booking. – Dyin Sep 11 '20 at 18:32
1

If you have to use it, that's fine.Middleware can be used to ensure security here.

Johnny
  • 687
  • 1
  • 6
  • 22