Assign Billing Information for an End User
This endpoint is a flexible tool designed to collect additional information required for ad-hoc workflows, such as billing or regulatory reporting. The flexibility of the endpoint allows the payload format to be customized according to the specific use case, as agreed upon with the partner.
Key aspects:
- Negotiated Format: The info field format must be negotiated with the client before usage to ensure it meets the requirements of the specific use case.
- Validation: Validation rules for the info payload may vary depending on the format and purpose of the data being submitted.
- Versatility: This endpoint is not limited to billing information but can be repurposed for other ad-hoc workflows requiring custom data exchange.
- Support for Data Corrections: This endpoint can also be invoked to rectify previously submitted data. If multiple rectifications are sent, the system will always use the most recent rectification received.
Use Case Example: Regulatory Reporting in Argentina
A common use case for this endpoint is to collect information for regulatory reporting, such as meeting compliance requirements for Argentina’s Financial Information Unit (UIF). In this scenario, the required format for the info field is as follows:
Field Descriptions:
condición_extranjero (boolean): Indicates if the person is a foreign resident (true) or not (false).cuit (string): Unique Tax Identification Code (Clave Única de Identificación Tributaria) of the person.apellidos (string): Last name(s) of the person.nombres (string): First name(s) of the person.tipo_documento (string): Type of document (DNI, PASAPORTE).num_documento (string): Document number.nacionalidad (string): Nationality of the person.fecha_nac (string): Date of birth in the format DD/MM/YYYY.fecha_alta (string): Registration date in the formatDD/MM/YYYY.fecha_baja (string | null): Deregistration date in the formatDD/MM/YYYYornullif not applicable.es_pep (boolean): Indicates if the person is a Politically Exposed Person (trueorfalse).
Authorizations
B2B’s White Label API uses OAuth2. Currently there is only one supported authentication flow:
- clientCredentials allows you to access your own B2B account (First-Party Integration) and performs transactions against the public API. This oauth2 flow is well suited for this API, as it allows machine-to-machine communication.
Every call to the API has to be authenticated with an OAuth2 Token. In order to request this token, you will need to have sandbox or production API Keys (client id and client secret) that will be needed to generate a credential in order to negotiate an ephemeral access token.
Every request must be accompianed by an Authorization header with a value that follows the following schema: Bearer ACCESS_TOKEN
Path Parameters
Body
JSON object which can hold arbitrary data based on the negotiated requirements between the client and the system.