Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VTEX UA-CH & UA Reduction Testing Results #314

Open
tibuurcio opened this issue Jul 25, 2022 · 1 comment
Open

VTEX UA-CH & UA Reduction Testing Results #314

tibuurcio opened this issue Jul 25, 2022 · 1 comment

Comments

@tibuurcio
Copy link

VTEX UA-CH & UA Reduction Testing Results

We, at VTEX, have tested the impact of UA Reduction on payment transactions in March 2022.
Initial results show no need for change in the Payments module because all evidence seems to indicate we won’t be impacted by the User-Agent reduction. We will continue communication with Payment and Antifraud partners to raise awareness of the change and anticipate impact on their side.

Below you'll find the full report for feedback.

Intro

  • VTEX is a leading Enterprise Digital Commerce Platform w/ global presence.
  • Inside VTEX's platform, we offer integrations with partners, such as ClearSale and CyberSource, which provide complete ecommerce fraud protection solutions.

Test objective

  • Understand the UA Reduction impact on VTEX anti-fraud solutions (e.g. ClearSale & CyberSource) and payments workflows.
  • Why is testing this important?
    • The User Agent is an important input in web payments. In most cases, it’s needed to authorize, run anti-fraud models and execute payment requests.

Questions we settled to answer

  • Map steps to test reduced User Agent in payment transactions.
  • Understand impact in VTEX Payments Gateway workflows.
  • Understand impact in our Payment Provider Protocol (used for payment services to integrate with VTEX).
  • Understand impact on fingerprinting generation from our partner's scripts.

Test setup overview

  • Reduced UA string implemented locally using Chrome’s flag.
  • Device fingerprint generated using script tag similar to the one in this example.
    • With the following script, we manually generated the fingerprint for the device in Chrome's developer console:
var deviceFingerprintIdCSV4 = 10000000 + Math.floor(Math.random() * 99999999);
(function (a, b, c, d, e, f, g) {
a['CsdpObject'] = e; a[e] = a[e] || function () {
(a[e].q = a[e].q || []).push(arguments)
}, a[e].l = 1 * new Date(); f = b.createElement(c),
g = b.getElementsByTagName(c)[0]; f.async = 1; f.src = d; g.parentNode.insertBefore(f, g)
})(window, document, 'script', '//device.clearsale.com.br/p/fp.js', 'csdp');
csdp('app', 'vtex.useragent');
csdp('sessionid', deviceFingerprintIdCSV4);
window.vtex.deviceFingerprint = deviceFingerprintIdCSV4;
  • Ran tests on a VTEX “Test Store” that runs in our production environment (i.e. real transactions) and using our Fraud Providers' production credentials.
  • Scenarios tested:
    • No device fingerprint
    • Device fingerprint generated with full UA string
    • Device fingerprint generated with reduced UA string

VTEX fingerprinting process

Important! All usages inside the Payments Gateway codebase are read and pass-along. VTEX doesn’t do any operations with this value.

  • Generating fingerprints on VTEX varies from provider to provider.
  • Generally, they’re generated on the client-side by inserting a script tag (mostly through Google Tag Manager).
  • Before an order is submitted (i.e. a payment event), VTEX runs the script and generates the device fingerprint.
  • Finally the value is passed to the provider via our Payment Provider Protocol API.

Results & findings

  • Tests were performed on our test store that works on a production environment (real transactions).
  • No impact on our Payments Gateway observed, therefore no changes on VTEX codebase required:
    • All usage of device fingerprints throughout the payments workflow are “read and pass along”. On the VTEX side, there are no operations done with the fingerprint values.
    • Tests suggest that if providers need more information not provided by the reduced UA string by default, the change (UA-CH API call) would be in the script of the provider; nothing would need to be changed on VTEX's side.
  • No significant changes observed in the provider’s “anti-fraud score/status” generated from scripts.
  • VTEX sees the need to communicate to 3rd parties on how to test UA reduction following a step-by-step process documented on VTEX's platform (usage of Chrome flag, generate fingerprint, configure credentials, test scenarios, etc).

Test Output Examples

image

image

@miketaylr
Copy link
Collaborator

Thank you for sharing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants