solidusio / solidus_braintree Goto Github PK

Goal

We want to set the Solidus dependency of SolidusBraintree to > 3.4.0.dev, < 4 because it is not compatible with the starter frontend of Solidus 3.3.0. We want to target the dev version so that it can be used with the current Solidus master branch.

Background

We discussed backporting Starter Frontend v3.4 changes to v3.3 versus limiting SolidusBraintree to Solidus v3.4 in solidusio/solidus_starter_frontend#325.

Goal

We want to release SolidusBraintree 1.3 so that users can receive the latest changes up to and before the SolidusStarterFrontend update.

Implementation

1. Reset https://github.com/solidusio/solidus_braintree/tree/v1.x to c2c6452.
2. Release SolidusBraintree 1.3.

Current behavior
Single names entered in the Solidus shipping address form become duplicated with a space between during PayPal transactions. (I have not checked Venmo or CreditCard). This seems due to paypal_button.js logic when sending a request to TransactionsController.

Expected behavior
A single name should not be modified by the time of completion.

To Reproduce
Ensure you have PayPal enabled.

1. On the shipping stage, add only one word to the name field, such as John to the billing address.
2. Use the billing address for the shipping address.
3. Continue to checkout using PayPal.

The name will have become John John.

Solidus Version:
Using main at v4.1.0.dev / 474877aaad9139a0a9b8564a9e7279e5446bc12c (bin/sandbox).

Additional context
The shipping address is entered in Solidus, sent to PayPal, then sent back to Solidus (this logic has been quite problematic).

Solidus changed from using firstname and lastname to name, to be more inclusive of countries where only one name is used. This bug defeats the purpose of that.

It shouldn't be too difficult to add paypal to the new frontend forms. Some JS will be needed to make the integration seamless.

https://developers.braintreepayments.com/guides/paypal/client-side/javascript/v2

This is a version of SolidusBraintree that has the new StarterFrontend generator (see #112).

• After #96, we want to release a new major version of this extension.
• Blocked by #91
• Blocked by #92

We use show_flash function to print a message when the tokenization has an error, but show_flash
is only defined in Solidus backend.

Maybe change it to an alert ?

We want to check with Braintree if it's necessary to re-collect the device data of the user whenever they make a payment transaction using an existing payment source.

Goal

We want to ensure that the other SolidusBraintree payment options are tracking the device data so that the feature would be consistent across all SolidusBraintree payment options.

Background

We added device data collection in #116 but it seems we only implemented it for the hosted form.

Background

This was pushed back from #99 because we didn't want the table rename to block users from migrating to v2.0.0 of SolidusBraintree. We were also not sure whether to force users to rename to the new prefix or continue supporting the old prefix for existing users.

There was also a concern about the impact of a table rename for large databases and whether a scalable approach (e.g. duplicating the table, double writing, phasing out the old one) is the responsibility of the extension or we can proceed with a vanilla rename_table and let anything more complex than that to be handled by each store.

Blockers

Depends on #102.

Requirements

Tester might need to be in US. Wasn't successful in faking a Venmo payment. See #102 (comment).

I’m looking a way to use Solidus Braintree extension only using the supplied Paypal Braintree SDK Token found in Paypal. Found about this option in paypal documentation https://developer.paypal.com/docs/accept-payments/express-checkout/ec-braintree-sdk/get-started .
Is it posible to configure solidus_paypal_braintree to work this way? Any workaround?

Actually I'm using the https://github.com/Lostmyname/solidus_paypal_express/network unmaintained extension, but I understand that the future development is on this extension.

The advantage is that you won't need to initially open a Braintree account that is more restrictive for some merchants, and is easier for merchants to open initially a Paypal Business account.

After upgrading our site to Solidus 1.3, which changes a lot of the backend UI, I can't seem to get the Drop In UI to appear anymore. Is anyone else experiencing this?

I would like to use the JS component Drop UI

https://developers.braintreepayments.com/guides/drop-in/overview/javascript/v3

How I can integrate with the gem?

Premise

We have two braintree extensions for solidus, the newer one (solidus_paypal_braintree, SPB from now on) is called after the first integration that was available but later grew out of it and now encompasses multiple payment methods. The former (solidus_braintree, SB from now on) has a more sensible name, but is stuck in the past.

What

We should merge both into different versions of SB, more specifically:

1. merge the history of SPB into the one of SB (add the remote for SPB then merge with a merge-strategy that discards all the old code)
2. update the namespace and allow people to choose the namespace for database table names
3. release a new major of SB
4. release a new major of SPB that is empty and only depends on the newly released SB, with a post-install message that suggests switching the dependency in the gemfile
5. archive the SPB repo

Considerations

• using majors we clearly try to get the attention of the users upgrading and give them a fair chance at understanding what's going on
• going forward we'll have less confusion on what extension is the right one for your application
• users using a git dependency in their gemfile will still have the burden of checking commits or the changelog manually

/cc @chrean @kennyadsl

Goal

We want to rename the SolidusPaypalBraintree namespace to SolidusBraintree to simplify the extension's name and avoid it being confused with SolidusPaypalCommercePlatform.

Requirements

• For backward compatibility, we also need to contextually allow people to choose the namespace for database table names, so that those who are using the solidus_paypal_braintree_prefix can still update to the latest version.
• We want to limit the manual changes that users of SolidusPaypalBraintree have to make in order to transition to SolidusBraintree. We may want to consider to alias the SolidusPaypalBraintree class and the solidus_paypal_braintree JS file names. The aliases have to be deprecated.
• We want to ensure that existing payments to SolidusPaypalBraintree will work with the new name. We may want to add a data migration to rename the source type of these payments from SolidusPaypalBraintree to SolidusBraintree.

Dependencies

This is blocked by #92.

Goal

We want to add an overview to SolidusBraintree's README so that people will know what SolidusBraintree does and what kind of transactions it supports.

Implementation

• Add: solidus_braintree is an extension that adds support for using Braintree as a payment source in your Solidus store. It supports Apple Pay, PayPal, Venmo Pay, and credit card transactions.
• Indicate the technologies used (like API version, hosted forms etc).

When using the braintree integration in the admin backend, it tries (and fails) to create a customer profile when checking out as guest, as there is no user attached to the order. Is this intended behaviour?

I get the following error, while running this app when navigating to Admin page:

undefined local variable or method `solidus_paypal_braintree' for #<#Class:0x0000555c44c27b80:0x0000555c46c46218>

App is running inside Docker. Does anyone has any idea?

This is a version of SolidusBraintree that only has the name change (#99) and not the shift to StarterFrontend (#112).

Goal

We want to ensure that the other SolidusBraintree payment options are tracking the device data so that the feature would be consistent across all SolidusBraintree payment options.

Background

We added device data collection in #116 but it seems we only implemented it for the hosted form.

PayPal documentation

Although https://developer.paypal.com/braintree/docs/guides/premium-fraud-management-tools/overview doesn't include Venmo Pay as a supported payment method, https://developer.paypal.com/braintree/docs/guides/venmo/client-side#collect-device-data still says we should collect device data for Venmo.

Can someone explain the difference in roadmaps between this gem and https://github.com/solidusio/solidus_paypal_braintree ?

Solidus_paypal_braintree is linked from the solidus website and includes frontend integration for braintree, whereas apparently this gem does not. I'm just wondering which will be around for the long term...

Problem

Braintree v.zero supports up to 7 payment method types. Solidus's Spree::Gateway class assumes the payment source is a Spree::CreditCard. Only one of Braintree's payment method types maps to a Spree::CreditCard. We only know the payment method type at the time of Spree::Payment creation.

1. Multiple Payment Methods

Create new Spree::Gateways for each payment method type that Braintree supports (Paypal, CreditCard, Coinbase, ApplePay, etc.).

Pros

• Follows the Spree::Gateway convention
• Ability to treat payment methods specifically
• Easiest to reason about

Cons

• Its a hack: They all are conceptually the same gateway
• Shared/Duplicated configuration
• Complicates client token generation
• Complicates attaching payment_method_id

2. Braintree Catch-all Class

Create a new payment source class named BraintreeSource that has one-to-one relationships to each payment method type. Each relationship is optional, as long as one is associated.

Pros

• Allows use of a single payment method for all Braintree types
• One source abstraction

Cons

• Would break compatibility with solidus_gateway
• Double the polymorphism!

3. Repurpose CreditCard Class

Use Spree::CreditCard class as a catchall for all payment method types. (Put Paypal email in the name field, and leave everything else nil.)

Pros

• Easy
• Currently works, as is
• No Solidus changes required

Cons

• Hackiest solution, literally cannot get hackier
• It's a hack
• Hack
• PayPal is not a credit card

4. Payment Source Marshalling

Replace polymorphic source association on Spree::Payment with a text field and marshall the payment method data into JSON. It will have a type key such as credit_card or paypal and contain fields specific to that type.

Pros

• Most flexible, supports any payment type, including future ones
• Easy to extend with any gateway

Cons

• Hard to query
• Potentially lose having a class backed source

5. Skip Spree::Gateway, subclass Spree::PaymentMethod

Instead of trying to get Braintree fit into Spree::Gateway, go one level up, subclassing Spree::PaymentMethod and implement the Braintree Catch-all Class solution on top of this new payment method class.

Pros

• Pros of Braintree Catch-all Class
• Maintain compatibility with solidus_gateway or anything that depends on Spree::Gateway

Cons

• The Braintree gateway IS a gateway, conceptually it should inherit from Spree::Gateway
• Duplication of some code in Spree::Gateway and our new class.

Background

We're currently getting the following errors in CI. See https://app.circleci.com/pipelines/github/solidusio/solidus_braintree/269/workflows/7d232690-2ca1-4ae6-af14-8e7380fc37b8/jobs/741:

     Spree::LogEntry::DisallowedClass:
       Tried to dump unspecified class: SolidusBraintree::Response
     
       You can specify custom classes to be loaded in config/initializers/spree.rb. E.g:
     
       Spree.config do |config|
         config.log_entry_permitted_classes = ['MyClass']
       end
     # /home/circleci/.rubygems/bundler/gems/solidus-5d119ba3d1e0/core/app/models/spree/log_entry.rb:97:in `rescue in handle_psych_serialization_errors'
     # /home/circleci/.rubygems/bundler/gems/solidus-5d119ba3d1e0/core/app/models/spree/log_entry.rb:94:in `handle_psych_serialization_errors'
     # /home/circleci/.rubygems/bundler/gems/solidus-5d119ba3d1e0/core/app/models/spree/log_entry.rb:83:in `parsed_details='
     # /home/circleci/.rubygems/bundler/gems/solidus-5d119ba3d1e0/core/app/models/spree/payment/processing.rb:209:in `record_response'
     # /home/circleci/.rubygems/bundler/gems/solidus-5d119ba3d1e0/core/app/models/spree/payment/processing.rb:187:in `handle_response'
     # /home/circleci/.rubygems/bundler/gems/solidus-5d119ba3d1e0/core/app/models/spree/payment/processing.rb:48:in `block in authorize!'
     # /home/circleci/.rubygems/bundler/gems/solidus-5d119ba3d1e0/core/app/models/spree/payment/processing.rb:213:in `protect_from_connection_error'
     # /home/circleci/.rubygems/bundler/gems/solidus-5d119ba3d1e0/core/app/models/spree/payment/processing.rb:42:in `authorize!'
     # /home/circleci/.rubygems/bundler/gems/solidus-5d119ba3d1e0/core/app/models/spree/payment/processing.rb:33:in `process!'

These are the failing examples:

rspec ./spec/models/solidus_braintree/gateway_spec.rb:73 # SolidusBraintree::Gateway making a payment on an order can complete an order
rspec ./spec/models/solidus_braintree/transaction_import_spec.rb:161 # SolidusBraintree::TransactionImport#import! with passing validation when order end state is confirm is complete and capturable
rspec ./spec/system/frontend/braintree_credit_card_checkout_spec.rb:99 # entering credit card details with valid credit card data checks out successfully
rspec ./spec/system/frontend/braintree_credit_card_checkout_spec.rb:113 # entering credit card details with valid credit card data with 3D secure enabled checks out successfully
rspec ./spec/system/frontend/braintree_credit_card_checkout_spec.rb:167 # entering credit card details with invalid credit card data when user enters valid data allows them to resubmit and complete the purchase
rspec ./spec/system/backend/new_payment_spec.rb:112 # creating a new payment with invalid credit card data when user enters valid data creates the payment successfully
rspec ./spec/system/backend/new_payment_spec.rb:37 # creating a new payment with valid credit card data checks out successfully

I've confirmed that I'm also getting the error in development:

Caused by

I think we need to update SolidusBraintree in response to solidusio/solidus#4950.

Goal

We want the SolidusBraintree InstallGenerator to install the frontend code so that users can customize it easily.

TODOs

• Reorganize InstallGenerator to match SolidusPaypalCommercePlatform structure.
• Take note to install helpers and images as well.
• Test: Update a Rails app with solidus_paypal_braintree to the new version.
  • I was able to successfully update a Rails app with solidus_paypal_braintree to SolidusBraintree. See https://github.com/gsmendoza/solidus_store/tree/rails-7-0-4--solidus-3-4-0-dev--braintree--renamed.
• Check if we need to remove the /frontend/ directories.
  • Looks like we don't need to remove the frontend directories from the asset directories since they are also in SolidusPaypalCommercePlatform.
• Check if we can remove the add_paypal_funding_source_to_payment override.
• Update README to install solidus starter frontend before installing solidus_braintree.
  • Break down Solidus gem and remove solidus_frontend.
  • Update Solidus gems to 3.4.0.dev.
  • bin/rails app:template LOCATION=https://github.com/solidusio/solidus_starter_frontend/raw/v3.4/template.rb.

Expected behavior

Given I have installed SolidusBraintree on my Solidus app
And I have disabled the use_data_collector preference (see https://github.com/solidusio/solidus_braintree#disabling-the-data-collector)
And I have enabled the Hosted Fields credit card form
When I run the app
Then the Hosted Fields credit card form should not use the data collector
And the app should not collect device data

Current behavior

The hosted form uses the data collector regardless of the use_data_collector preference setting. See

Background

We enabled useDataCollector for SolidusBraintree.HostedForm in #116.

Can't record or rerecord new specs with paypal braintree.

When trying to re-record specs or record new specs with paypal payments an error occurs:

Spree::Core::GatewayError:
       This merchant account does not allow PayPal payments using the old Vault flow.

See: https://developers.braintreepayments.com/reference/general/validation-errors/all/ruby#code-92919

We either need to allow this on the braintree account or update the paypal vaulting method.

Goal

We want to make Solidus Braintree compatible with Starter Frontend so that it can be used with the latest Solidus versions.

Spike application

https://github.com/gsmendoza/solidus_store/tree/rails-7-0-4--solidus-3-3-0--braintree--solidus-starter-frontend

Solidus Version:

Latest, using the solidus sandbox.

To Reproduce

1. rails new my_store_braintree_3
2. cd my_store_braintree_3
3. bundle add solidus
4. open Gemfile and use the local version of Solidus using the branch of this PR.
5. bin/rails g solidus:install using braintree as payment option

Current behavior
Braintree Payment Method is not present in the list of available payment methods in admin.

Expected behavior
It should be present.

Screenshots

Backport to v2.x:

• #116
• #129

Summary

A error Braintree response would raise the following error:

Spree::LogEntry::DisallowedClass:
  Tried to dump unspecified class: Symbol

  You can specify custom classes to be loaded in config/initializers/spree.rb. E.g:

  Spree.config do |config|
    config.log_entry_permitted_classes = ['MyClass']
  end
# ./app/controllers/checkouts_controller.rb:54:in `transition_forward'
# ./app/controllers/checkouts_controller.rb:21:in `update'
# ./app/controllers/store_controller.rb:26:in `block in lock_order'
# ./app/controllers/store_controller.rb:26:in `lock_order'

Solidus Version:

3.4.0.dev

Cause

When SolidusBraintree::Response.build(result) accepts an error result, the result.params it passes to the new response has symbol keys. Here's a sample of the result.params:

    {:transaction=>
      {:amount=>"20.00",
       :order_id=>"R300000001",
       :channel=>"Solidus",
       :options=>{:store_in_vault_on_success=>"true"},
       :payment_method_token=>"0ev7m4dt",
       :customer_id=>"180763858",
       :type=>"sale"}}

Solution

Deep-stringify the result params.

Demonstration

See https://github.com/solidusio/solidus_braintree/tree/gsmendoza/110-log-entry-disallowed-class-demo for a demonstration of the error and the my attempts to fix it. Start from the "Try enabling venmo specs" commit.

Additional context

Related to #108.

There is also a PR in Solidus that will temporarily allow bad payloads to be saved in payment log entries. See solidusio/solidus#4953

Spree.t('XXXX') is deprecated and all uses need to be changed to I18n.t('spree.XXXX')

A few days ago, sure of what to propose, I made this pull request #65 . Because of the failed tests, I understood that I was wrong. The POST /api/payment_client_token endpoint is not just an extension of the API services, but is also used internally in Braintree's javascript SDK. In your opinion, what is the best and secure way to provide the AJAX call with the user api token?

Another approach is to fix the README and specs, leaving the endpoint public. In this scenario, what could be collateral damages? So far it has been public.

Goal

We want to add device data collection because PayPal recommends that all customer-initiated transactions include device data. Device data increases the accuracy of their available Premium Fraud Management Tools in determining when a transaction is fraudulent. See https://developer.paypal.com/braintree/docs/guides/premium-fraud-management-tools/device-data-collection.

Background

@SyborgStudios contributed the initial PR. See #103.

Tasks

• Remove IS_FRONTEND since we now have separate hosted_form.js files for frontend and backend.
• Always use data collector in frontend HostedForm.
• Check if client and data-collector JS files are being included:
  • <script src="https://js.braintreegateway.com/web/3.91.0/js/client.min.js"></script>
  • <script src="https://js.braintreegateway.com/web/3.91.0/js/data-collector.min.js"></script>
  • Test if PayPal checkout is successful.

Isn't the new 3ds 2.0 with Javascript SDK v3 required from 14th September 2019 on?
Braintree keeps sending mails regarding this.
https://developers.braintreepayments.com/guides/3d-secure/migration/javascript/v3
Not sure if the mentioned fallback to 3ds v1 will always work.

Will this extension cover this?

Hi guys,

Braintree wants me to do 3D Secure for each transaction over 200 bucks.
Is that already built in in the GEM?

Our current frontend views uses what braintree call a "custom integration". Though slightly more inconvenient to customize, I would prefer we use their "Hosted Fields" integration, which allows for the easiest level of PCI compliance, SAQ A.

• https://developers.braintreepayments.com/guides/hosted-fields/overview/javascript/v2
• https://developers.braintreepayments.com/guides/hosted-fields/upgrading-from-custom/javascript/v2

Right now Solidus::Gateway::BraintreeGateway model allows options to be passed to the generate_client_token method when generating the braintree token.

However when calling the api to call generate the token. No options are passed or considered
https://github.com/solidusio/solidus_braintree/blob/d9c8f26f941d912c482ba3b98934f331c50370ac/app/controllers/spree/api/braintree_client_token_controller.rb

This means every card is created on a new Braintree Customer. If a user is logged in, that user should belong to 1 Braintree Customer and all cards created should be attached to that same customer. The hosted fields right now does not support this as far as I can see.

This feature becomes extremely important with braintree recurring billing and updating a payment method. The update will fail because the newly created card belongs to another customer and not the same customer as on the subscription.

The token creation would look something like:

Braintree::ClientToken.generate customer_id: <customer id>

Current implementation is posting credit card data directly back to the server

Started PATCH "/checkout/update/payment" for 127.0.0.1 at 2016-02-08 05:56:54 -0500
Processing by Spree::CheckoutController#update as HTML
Parameters: {"utf8"=>"✓",
"authenticity_token"=>"KLjo/1QEPRso8DOuTXlcCVZPlDD3/BcIxuWTUzh+/HhpbDw0gCfDVnYRiCHK8u00oRJGxW0Mbx33o6B0AIjmgg==",
"order"=>{"payments_attributes"=>[{"payment_method_id"=>"2"}], "coupon_code"=>""}, "payment_source"=>{"2"=>{"name"=>"Test
User", "number"=>"[FILTERED]", "expiry"=>"11 / 17", "verification_value"=>"[FILTERED]",
"address_attributes"=>{"firstname"=>"Test ", "lastname"=>"User", "company"=>"", "address1"=>"431 Test Ave", "address2"=>"",
"city"=>"Testing", "country_id"=>"232", "state_id"=>"3561", "state_name"=>"", "zipcode"=>"10001", "phone"=>"212-111-1111",
"alternative_phone"=>""}, "cc_type"=>"visa"}}, "state"=>"payment"}

v.zero SDK does not post back credit card data, just a payment method nonce:

{"payment_method_nonce"=>"761e1fad-94a3-4737-add1-6cccf7ec1b8d"}

Blockers

Depends on #102.

Requirements

Tester needs to be in Spain/Italy and must have an Apple device. See https://github.com/solidusio/solidus_braintree#apple-pay and https://developer.apple.com/apple-pay/sandbox-testing.

Goal

We want to support Payment Request API because

1. This would provide a better customer experience for our users.
2. It might become some kind of standard in the ecommerce industry in the future.

Questions

• Should we update SolidusBraintree JS from 3.84 to 3.91?
• Should we implement on both frontend and backend components?

Background

We have designated SolidusBraintree v2.x as the last major of the extension before the migration to SolidusStarterFrontend, which will be released in SolidusBraintree v3.x.

Dependencies

Blocked by #103.

• Fixes #72
• Fixes #84

Goal

We want to replace the SolidusBraintree code with that from the Solidus PayPal Braintree, while at the same time keeping the commits of both repos.

Implementation

Consider adding the remote for SPB then merge with a merge-strategy that discards all the old code, something like:

git remote add solidus_paypal_braintree [email protected]:solidusio/solidus_paypal_braintree.git
git reset --hard solidus_paypal_braintree/master
git merge origin/master --strategy ours --allow-unrelated-histories

Goal

We want to release a new version of solidus_braintree (1.3.0) with the current code on master before the merge (#92) so that solidus_braintree code from 2018 to today will be available as a gem.

If solidus_frontend is not included in the application (as is likely the case with most stores, as custom frontends are common), the braintree_security Deface override fails to compile:

Unable to precompile 'spree/checkout/_confirm' due to:
Missing template spree/checkout/_confirm with {:locale=>[:en], :formats=>[:html], :variants=>[], :handlers=>[:erb, :builder, :raw, :ruby, :coffee, :haml, :rabl], :versions=>[:v10, :v9, :v8, :v7, :v6, :v5, :v4, :v3, :v2, :v1]}. Searched in:
  * "/home/stewart/dev/store/app/views"
  * "/home/stewart/dev/store/vendor/bundle/ruby/2.2.0/gems/teaspoon-1.1.5/app/views"
  * "/home/stewart/dev/store/vendor/bundle/ruby/2.2.0/gems/solidus_auth_devise-1.5.0/lib/views/backend"
  * "/home/stewart/dev/store/vendor/bundle/ruby/2.2.0/gems/devise-4.2.0/app/views"
  * "/home/stewart/dev/store/vendor/bundle/ruby/2.2.0/gems/solidus_braintree-1.1.0/app/views"
  * "/home/stewart/dev/store/vendor/bundle/ruby/2.2.0/bundler/gems/solidus-bfe4b247b961/backend/app/views"
  * "/home/stewart/dev/store/vendor/bundle/ruby/2.2.0/bundler/gems/solidus-bfe4b247b961/api/app/views"
  * "/home/stewart/dev/store/vendor/bundle/ruby/2.2.0/bundler/gems/solidus-bfe4b247b961/core/app/views"
  * "/home/stewart/dev/store/vendor/bundle/ruby/2.2.0/gems/kaminari-0.17.0/app/views"

This could possibly be fixed by writing the override as a Ruby file, and only applying the override if solidus_frontend is present.

Backport changes in #123 to v2.x.

Goal

We want to ensure that the other SolidusBraintree payment options are tracking the device data so that the feature would be consistent across all SolidusBraintree payment options.

Requirement

Given we have Premium Fraud Tools enabled on our Braintree account
And there is a user checking out an item
When the user checks out the item using PayPal Checkout with Vault
Then SolidusBraintree should collect the user's device data and send it to Braintree
And Braintree should confirm that the device data has been captured, that is, it should include a risk data section in its transaction response, like this:

[Braintree]   <risk-data>
[Braintree]     <id>ka4fb2kz</id>
[Braintree]     <decision>Approve</decision>
[Braintree]     <fraud-service-provider>fraud_protection_advanced</fraud-service-provider>
[Braintree]     <device-data-captured type="boolean">true</device-data-captured>
[Braintree]     <liability-shift nil="true"/>
[Braintree]     <decision-reasons type="array"/>
[Braintree]     <transaction-risk-score>341</transaction-risk-score>
[Braintree]   </risk-data>

Background

We added device data collection in #116 but it seems we only implemented it for the hosted form.

PayPal documentation

• According to https://developer.paypal.com/braintree/docs/guides/paypal/overview/javascript/v3,
  • Checkout - Device data is automatically included with each transaction
  • Checkout with Vault - Must collect and submit device data on non-recurring transactions created from the Vault
• https://developer.paypal.com/braintree/articles/guides/fraud-tools/premium/overview#payment-methods-supported doesn't include PayPal Checkout in its list of supported payment methods. Not sure if PayPal is not included because it's truly not supported, or not included just because we can assume it's already supported.