Contrib.social

Feature idea - Data capture, 3dSecurity 2.0, etc...

Open on Drupal.org →
Created on 11 July 2023, 12 months ago
Updated 10 June 2024, 18 days ago

Hey All!

I have been meaning to add this patch (hopefully it helps anyone) which adds some new functionality for Braintree implementation (if that what you need). This is not perfect patch and not fully tested.

These are the config that seems to work perfectly fine

Things it adds

  1. Ability to turn off on whether payment method needs to be stored. In some cases we don't want always to create reoccurring payment methods on Braintree
  2. Enabled 3DS 2.0 security
  3. Make 3dSecurity as required
  4. Ability to send shipping and billing address to Braintree (important for Paypal to shift liability)
  5. Only accept payments when liability is fully shifted
  6. Capture Device data for Advanced Fraud tools
  7. Enable Post Code capture requirement
📌 Task
Status

Needs work

Version

1.0

Component

Code

Created by

🇬🇧United Kingdom Povilas Uogintas

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @Povilas Uogintas
  • Comment 12 months ago →
    🇬🇧United Kingdom Povilas Uogintas

    Added a new patch that is compatible with 1.4.0 version! just in case

  • Comment 11 months ago →
    🇬🇧United Kingdom Povilas Uogintas
  • Comment 11 months ago →
    🇬🇧United Kingdom Povilas Uogintas
  • Comment 9 months ago →
    🇬🇧United Kingdom Povilas Uogintas

    again I do not think is gaining tracking but I have updated patch to work with current dev.... Again 3D 2.0 security works. Device capture data works which enables all fully advanced fraud tools enabled + sending shipping address to paypal meaning your payments are fully responsibility shifted...

  • Comment 18 days ago →
    🇮🇱Israel jsacksick

    Hi @Povilas Uogintas and thanks for your work. Would it be possible to split the changes? For example, make a separate patch for collecting / passing the device data?
    I think your approach is correct (add a setting to toggle the device data collection).

    What I don't understand is that the "device_data" parameter is described as required in some cases, but haven't seen any "complaints" in our queue and not sure why...

    To get your changes in, splitting this into different feature requests is definitely going to make this easier.

  • Status changed to Needs work 18 days ago
  • Comment 18 days ago →
    🇮🇱Israel jsacksick

    Also, we need to store the device_data in the payment method. JSON encoding the remote ID doesn't seem like the right approach to me... This would be a breaking change.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024