Features
In this section, you will find all the features of the Unico IDPay product.
Introduction
Unico IDPay offers a wide range of endpoints, modules, and features, designed to adapt to different scenarios and use cases. Below, we present the key definitions and applications of each feature.
Payment Transactions
The first major feature of IDPay is to validate each transaction made within the establishment, ensuring that the sale can be processed for that user.
Transactions are organized into different modules, each designed to address specific scenarios and varied needs. Explore the available modules and see how each one can be applied to your use case:
Modules
With a subset of validations in transaction creation (Pre)
This module performs some pre-validations with the provided data. The returned status will be: waiting or fast-inconclusive. The link for biometric capture will only be provided if we are able to validate the user's CPF/credit card number.
This option can be used in various scenarios, including:
When the provided identification (e.g., CPF) belongs to the cardholder. This flow does not allow the user to provide a new CPF during validation, so if the provided identification is not consistent with the cardholder, it will negatively impact the approval rate;
When you want to minimize friction (opening the IDPay capture experience) without sacrificing approval, maximizing the approval rate of transactions returned as 'waiting';
When IDPay is at the top of its fraud prevention funnel;
In a 100% integrated solution with capture via Webview or iFrame;
Among others.
With all validations in transaction creation (Super Pre)
This module performs all pre-validations with the provided data. The returned status will be: waiting or fast-inconclusive. The link for biometric capture will only be provided if we are able to validate the user's CPF/credit card number.
This option can be used in various scenarios, including:
When the provided identification (e.g., CPF) belongs to the cardholder. This flow does not allow the user to provide a new CPF during validation, so if the provided identification is inconsistent with the cardholder, it will negatively impact the approval rate;
When you want to minimize friction (opening the IDPay capture experience) with a small loss in approval, maximizing the approval rate of transactions returned as 'waiting';
When IDPay is at the top of its fraud prevention funnel. In a 100% integrated solution with capture via Webview or iFrame;
Among others.
Without validation in transaction creation (Post)
This module does not perform any pre-validation when creating a transaction. The returned status will always be 'waiting', and the link will always be provided for the user to perform the biometric capture.
This option can be used in various scenarios, including:
When the provided identification (e.g., CPF) is not necessarily that of the cardholder (this flow allows the user to provide a new CPF during the capture experience);
When you want to use the IDPay capture experience for all transactions;
Preferably for sales recovery;
Among others.
Credit Card Onboarding
With this functionality, you can onboard your users' credit cards to your digital wallet, ensuring that the card belongs to the correct cardholder.
What differentiates this functionality from Payment Transactions are the endpoints and specific parameters of the REST API, which have been developed to optimally meet the needs of card validation and registration in your solution.
Continue reading with the suggested link below:
Still need help?
Didn't find something or still need help? If you're already a client or partner, you can reach out through our Help Center.
Last updated