To strengthen security and comply with data protection standards, we will start masking sensitive information in the payer and card objects in payment APIresponses for payments with a status other than approved.

The endpoint structure does not change; only the content of some fields will become partially visible or masked.

• Personal data of the payer in the payer object will be masked, keeping only the payer.id in the response.
• Sensitive card data in the card object will be masked, keeping only what is necessary to identify the payment method.
  
  

Direct queries to the payments endpoint and integrations that consume these responses in their systems.

• Increase protection of financial and personal data.
• Reduce exposure of sensitive information in server-to-server integrations and application logs.
• Continue our principle of continuous improvement based on best practices and security regulations applicable to payment data processing.
  
  

1. Review your current integration
Identify where in your code you consume the payments endpoint and verify which fields of the payer and card objects you actually use.

2. Avoid dependency on sensitive data returned by the API
If you need buyer information for internal processes, prioritize using data captured directly in your own systems (for example, in your own checkout or CRM) rather than extracting it from the payments response.

3. Update validations and reports
Adjust any logic that depends on full field values of these fields to work with masked data (for example, exact comparisons, format validations, and similar checks).

4. Test the changes
Use the environment indicated in the documentation to validate how masked values are returned in responses and confirm your integration’s behavior.

If you have questions about how this change affects your integration or need support to make the required adjustments, contact our team through the Developers Support Center.