Homologation onboarding
For clients to integrate with our BAAS solutions, we request that they initially integrate in the HML environment and complete the entire certification process.
Homologation endpoint
HML API URL: Use https://hml-api.u4c-baas.com instead of https://pix.u4c-baas.com in the endpoints.
Steps to Authenticate (We need these from you)
- We need your IP/IP range from sandbox and production enviroment;
- Webhook URL;
- Webhook Auth method chosen;
- Webhook payload security method chosen.
The table below explain everything we need from you to start the homologation process.
Field | Description |
---|---|
IP Range | IP range or client-side IP to insert in the white list. |
URL | Address to which the webhook will be sent |
Method | HTTP method to be used (GET, POST, PUT, PATCH, or DELETE) |
Headers | Necessary HTTP headers |
Authentication | Type of authentication and requirements for authentication (API Key - Basic Auth - Bearer Auth - JWS) |
U4C implements IP blocking in the production environment, requiring partners to configure specific machine IPs for access to be authorized. This measure ensures the security and confidentiality of data.
Client Authentication Information (Setup the webhooks)
To ensure that we are sending the webhook to the right place, we implement at least one method of authentication with the destination URL. The authentication methods are described below.
- API Key
- Basic Auth
- Bearer Auth
- JWS
API Key
In the API Key model, the client needs to provide us with the API authentication key to be used in the webhook call, as well as the name of the header to be used.
Example:
Header | Value |
---|---|
x-api-key | 717e785c-3819-4084-be86-03fa6a1b5b4f |
Basic Auth
In the Basic Auth model, the client needs to provide us with the client_id and client_secret to be used in the authentication of the webhook API call, as well as the name of the header to be used.
Example:
Header | Value format |
---|---|
Authorization | Basic base64(client_id:client_secret) |
Bearer Auth
In the Bearer Auth model, the client needs to provide us with a curl or similar with the necessary data to call the token generation route and obtain a JWT or opaque token to be used in the authentication of the webhook API call, as well as the name of the header to be used.
Example of authentication route:
curl -X POST \\
-H "Content-Type: application/x-www-form-urlencoded" \\
-d "grant_type=client_credentials" \\
-d "client_id=your_client_id" \\
-d "client_secret=your_client_secret" \\
<https://your-api.com/oauth/token>
Example of webhook call:
Header | Value format |
---|---|
Authorization | Bearer ce2f8e6f-fc1d-4e9a-86c1-562b014e36a2 |
JWS
In the JWS model, we provide the public signing certificate used. If this form of authentication is chosen, we will convert the webhook payload into a JWT signed with a signing certificate using a private key and share the public key for the client to verify the payload signature, confirming that it was sent by us.
Security Methods
To secure the webhook payload, we employ at least one of the methods below.
- Mutual TLS
- JWE
Mutual TLS
In the Mutual TLS method, when sending the webhook during the handshake, we verify if the client's certificate was issued from an issuer provided by the client. Upon verifying the authenticity of the server certificate, we send the request with our certificate, and the server, in turn, can verify if our certificate was issued from a previously provided issuer.
JWE
In the JWE method, similar to the JWS method, we convert the webhook payload into an encrypted JWT with a public encryption certificate provided by the client and send the request to the client, who decrypts it with the private key.
Updated about 1 year ago