For the complete documentation index, see llms.txt. This page is also available as Markdown.

Web

SDK

How to Start

To use You via the SDK, the first step is to register the domains, always using the HTTPS protocol, which will be used as the host to display the iFrame of the user's journey on You.

To start using the SDK, you need to install the Unico Web SDK. It's worth noting that "You" uses the same SDK as IDPay:

$ npm install idpay-b2b-sdk

The personalized button (renderButton) is available from version 2.2.4 onwards. For the classic init + open flow, the minimum version is 2.2.3.

Available methods

1

init(options)

This method initializes the SDK by pre-loading the assets, creating a more fluid experience for the end user. Use this method before creating the process. At this point, our SDK may indicate that the device does not support our flow.

If you use renderButton you do not need to call initrenderButton already plays this role. Keep init + open for the classic integration.

import { YouSDK } from "idpay-b2b-sdk";

const initializeYouSDK = async () => {
  try {
    const result = await YouSDK.init({
      env: 'uat', // It will only be filled in if it is a test environment
      hasPayments: true // if uses payment in the You flow
    });

    if (result?.statusPreValidation === 'DEVICE_SUPPORTED') {
      // SDK ready. Proceeding to process creation
      return;
    }

    // Handle the scenario where the device isn't compatible. No proceed to invoice creation
    
  } catch (error) {
    // Handle initialization failures
  }
}
2

open(options)

This method opens the You experience. For the IFRAME type flow, this function displays the pre-loaded iframe and starts the message flow between the client page and the You experience.

Parameters:

options - is an object with configuration properties:

  • id

    • Receives the ID of the process created. This ID is important so that we can obtain the details of the process and carry out the flow correctly (it can be obtained when creating the process via API).

  • token

    • Receives the token of the invoice created. This token is important so that we can authenticate the journey and ensure that only authorized domains use it (can be obtained when creating the process via API).

  • onFinish(process)

    • Receives a callback function that will be executed at the end of the You journey, passing as an argument the process object with the following data: { captureConcluded, concluded, id }

const id = '9bc22bac-1e64-49a5-94d6-9e4f8ec9a1bf';
const token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c';

const process = {
  transaction: {
    id: '9bc22bac-1e64-49a5-94d6-9e4f8ec9a1bf',
    token: 'V_adQssw5c', // last 10 caracteres from token
    concluded: true,
  }
};

const onFinishCallback = invoice => {
  console.log('Process', process);
}

YouSDK.open({
  transactionId: id,
  token: token,
  onFinish: onFinishCallback
});

// You can also close the SDK explicitly using the method below
YouSDK.close();

Sequence Diagram

The sequence diagram below demonstrates how to use the SDK with init + open:

How it should look in onboarding experience

How it should look in payments experience

3

renderButton(options)

Renders the You payment button inside a container on your page and starts the flow automatically when the user clicks it. It also plays the role of init (lazy-loads the assets and runs the device pre-validation), so a separate init call is not required.

Available from SDK version 2.2.4 onwards.

Parameters:

options - is an object with configuration properties:

  • container

    • Element (or CSS selector) where the button will be mounted. Required. See "Container requirements" below.

  • id

    • ID of the created process (obtained when creating the process via API). Required.

  • token

    • Token of the created process (obtained when creating the process via API). Required.

  • env

    • Environment ( uat or prod). Defines where the SDK loads its assets from; it is only filled in for test environments.

  • onReady(payload)

    • Callback fired when the button is rendered.

  • onClick(payload)

    • Callback fired when the user clicks the button, right before the flow opens. Useful for funnel metrics (rendered vs clicked).

  • onFinish(process)

    • Callback fired at the end of the journey, with the process object: { captureConcluded, concluded, id } (same as open).

  • onError(payload)

    • Callback fired when the button cannot be rendered or the device is not supported. Receives { reason } (see "Error reasons" below).

import { YouSDK } from "idpay-b2b-sdk";

const id = '9bc22bac-1e64-49a5-94d6-9e4f8ec9a1bf';
const token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...';

const button = YouSDK.renderButton({
  container: '#unico-pay-button',
  id,
  token,
  env: 'uat', // only for test environments
  onReady: () => {
    // Button is on screen
  },
  onClick: () => {
    // User clicked the button (the flow opens next)
  },
  onFinish: (process) => {
    console.log('Process', process);
  },
  onError: ({ reason }) => {
    // e.g. DEVICE_NOT_SUPPORT — do not show the button
  },
});

// Lifecycle handle
button.destroy();  // unmounts the button and removes listeners
button.refresh();  // re-renders the button

For the button to render correctly, the container must:

  • Exist in the DOM and be visible (not display: none).

  • Be a block-level element with usable width, and not be clipped by a wrapper using overflow/transform.

Error reasons (onError)

reason
When

DEVICE_NOT_SUPPORT

The device did not pass the pre-validation. Do not show the button / do not proceed with the flow.

CONTAINER_NOT_FOUND

The informed container does not exist in the DOM.

CONTAINER_UNSUPPORTED

The container is hidden or has zero size at mount time.

IFRAME_BLOCKED

The button iframe could not load (likely a CSP / blocking issue).

Sequence Diagram

The sequence diagram below demonstrates how to use the SDK with renderButton:

Security

Opt for the Iframe Solution with Auth Token Instead of CSP

After careful analysis of our needs and challenges, we have decided to adopt a solution based on iframes with authentication tokens rather than implementing a Content Security Policy (CSP). This choice was motivated by various considerations related to the security and flexibility required to meet our clients demands.

Context and Challenges with CSP

Content Security Policy (CSP) is a powerful tool for protecting web applications against various types of attacks, such as Cross-Site Scripting (XSS) and code injection. However, when configuring a CSP policy, it is necessary to define a strict list of trusted domains. This approach is effective when the domains are fixed and predictable. However, for our clients, who often use dynamic and variable domains, this rigid configuration presents significant challenges.

Vulnerability with Dynamic Domains

Dynamic domains pose a substantial security risk when using CSP. When a client has domains that frequently change or are created dynamically, it would be necessary to constantly update the CSP policy to include these new domains. This not only increases maintenance efforts but also exposes the domains to which the CSP policy applies. Each domain added to the CSP policy is potentially a vulnerability point if not adequately managed.

Solution with Iframe and Auth Token

To mitigate these risks and meet the flexibility required by our clients, we opted to use iframes combined with authentication tokens. This solution provides an additional layer of security and avoids the need to expose or manage an extensive and dynamic list of domains.

How It Works

  • Secure Authentication: Each iframe is loaded with a unique authentication token for each transaction, ensuring that only authorized users can access the content. This token is verified in real-time, providing an additional layer of security and control.

  • Content Isolation: The use of iframes allows for the isolation of content in a separate context, reducing the risk of interference between different origins and mitigating potential attacks.

  • Flexibility for Dynamic Domains: By not relying on a static CSP policy, our solution easily adapts to our clients' dynamic domains without the need for constant updates to security policies.

Atualizado