braintree-web/venmo

Members

(static) VERSION :string

The current version of the SDK, i.e. 3.91.0.

Source:

Methods

(static) create(options, callbackopt) → {Promise|void}

Parameters:
Name Type Attributes Description
options object

Creation options:

Properties
Name Type Attributes Default Description
client Client <optional>

A Client instance.
authorization string <optional>

A tokenizationKey or clientToken. Can be used in place of options.client.
allowNewBrowserTab boolean <optional>
 true

This should be set to false if your payment flow requires returning to the same tab, e.g. single page applications. Doing so causes isBrowserSupported to return true only for mobile web browsers that support returning from the Venmo app to the same tab.
allowWebviews boolean <optional>
 true

This should be set to false if your payment flow does not occur from within a webview that you control. Doing so causes isBrowserSupported to return true only for mobile web browsers that are not webviews.
ignoreHistoryChanges boolean <optional>
 false

When the Venmo app returns to the website, it will modify the hash of the url to include data about the tokenization. By default, the SDK will put the state of the hash back to where it was before the change was made. Pass true to handle the hash change instead of the SDK.
profileId string <optional>

The Venmo profile ID to be used during payment authorization. Customers will see the business name and logo associated with this Venmo profile, and it will show up in the Venmo app as a "Connected Merchant". Venmo profile IDs can be found in the Braintree Control Panel. Omitting this value will use the default Venmo profile.
deepLinkReturnUrl string <optional>

An override for the URL that the Venmo iOS app opens to return from an app switch.
requireManualReturn boolean <optional>
 false

When true, the customer will have to manually switch back to the browser/webview that is presenting Venmo to complete the payment.
useRedirectForIOS boolean <optional>
 false

Normally, the Venmo flow is launched using window.open and the Venmo app intercepts that call and opens the Venmo app instead. If the customer does not have the Venmo app installed, it opens the Venmo website in a new window and instructs the customer to install the app. In iOS webviews and Safari View Controllers (a webview-like environment which is indistinguishable from Safari for JavaScript environments), this call to window.open will always fail to app switch to Venmo, resulting instead in a white screen. Because of this, an alternate approach is required to launch the Venmo flow.

When useRedirectForIOS is true and the Venmo flow is started in an iOS environment, the Venmo flow will be started by setting window.location.href to the Venmo website (which will still be intercepted by the Venmo app and should be the same behavior as if window.open was called). However, if the customer does not have the Venmo app installed, the merchant page will instead be replaced with the Venmo website and the customer will need to use the browser's back button to return to the merchant's website. Ensure that your customer's checkout information will not be lost if they are navigated away from the website and return using the browser back button.

Due to a bug in iOS's implementation of window.open in iOS webviews and Safari View Controllers, if useRedirectForIOS is not set to true and the flow is launched from an iOS webview or Safari View Controller, the customer will be presented with a blank screen, halting the flow and leaving the customer unable to return to the merchant's website. Setting useRedirectForIOS to true will allow the flow to continue, but the Venmo app will be unable to return back to the webview/Safari View Controller. It will instead open the merchant's site in a new window in the customer's browser, which means the merchant site must be able to process the Venmo payment. If the SDK is configured with allowNewBrowserTab = false, it is unlikely that the website is set up to process the Venmo payment from a new window.

If processing the payment from a new window is not possible, use this flag in conjunction with requireManualReturn so that the customer may start the flow from a webview/Safari View Controller or their Safari browser and manually return to the place that originated the flow once the Venmo app has authorized the payment and instructed them to do so.
paymentMethodUsage string <optional>

The intended usage for the Venmo payment method nonce. Possible options are:

  • single_use - intended as a one time transaction
  • multi_use - intended to be vaulted and used for multiple transactions
displayName string <optional>

The business name that will be displayed in the Venmo app payment approval screen. Only applicable when used with paymentMethodUsage and used by merchants onboarded as PayFast channel partners.
allowDesktop boolean <optional>

Used to support desktop users. When enabled, the default mode is to render a scannable QR-code customers scan with their phone's to approve via the mobile app.
allowDesktopWebLogin boolean <optional>
 false

When true, the customer will authorize payment via a window popup that allows them to sign in to their Venmo account. This is used explicitly for customers operating from desktop browsers wanting to avoid the QR Code flow.
mobileWebFallBack boolean <optional>

Use this option when you want to use a web-login experience, such as if on mobile and the Venmo app isn't installed.
allowAndroidRecreation boolean <optional>
 true

This flag is for when your integration uses the Android PopupBridge. Setting this flag to false will avoid a page refresh when returning to your page after payment authorization. If not specified, it defaults to true and the Android activity will be recreated, resulting in a page refresh.

Note: This flow currently requires a full page redirect, which means to utilize this flow your page will need to be able to handle the checkout session across different pages.
callback callback <optional>

The second argument, data, is the Venmo instance. If no callback is provided, create returns a promise that resolves with the Venmo instance.
Source:
Examples
braintree.venmo.create({
  client: clientInstance
}).then(function (venmoInstance) {
  // venmoInstance is ready to be used.
}).catch(function (createErr) {
  console.error('Error creating Venmo instance', createErr);
});

Allow desktop flow to be used 

braintree.venmo.create({
  client: clientInstance,
  allowDesktop: true
}).then(function (venmoInstance) {
  // venmoInstance is ready to be used.
}).catch(function (createErr) {
  console.error('Error creating Venmo instance', createErr);
});

(static) isBrowserSupported(optionsopt) → {boolean}

Parameters:
Name Type Attributes Description
options object <optional>

browser support options:

Properties
Name Type Attributes Default Description
allowNewBrowserTab boolean <optional>
 true

This should be set to false if your payment flow requires returning to the same tab, e.g. single page applications.
allowWebviews boolean <optional>
 true

This should be set to false if your payment flow does not occur from within a webview that you control.
Source:
Examples
if (braintree.venmo.isBrowserSupported()) {
  // set up Venmo
}

Explicitly require browser support returning to the same tab 

if (braintree.venmo.isBrowserSupported({
  allowNewBrowserTab: false
})) {
  // set up Venmo
}

Explicitly set webviews as disallowed browsers 

if (braintree.venmo.isBrowserSupported({
  allowWebviews: false
})) {
  // set up Venmo
}