Connecting Asaas and Perfex CRM

The challenge

Outdated customer links and callback routing failures disrupted billing and invoice updates.

This project started with an Asaas module already purchased for Perfex CRM. Upmy’s work customized and corrected integration behavior affecting billing: identification checks, customer links and payment callbacks. The authorship of the third-party foundation remains separate from this intervention.

The integration needed to handle situations in which the customer record associated with a charge was no longer consistent. The callback route also had an issue affecting communication with the CRM. The documented scope focused on those points and the processing of received events.

How the workflow works

1. 01

   Review identification

   The work included Brazilian CPF/CNPJ tax ID checks and validation of the customer link used for billing. This addresses the relationship between the CRM record and the record used by the integration.

2. 02

   Handle removed customers

   The paths involving customers removed from Asaas were adjusted. This scenario matters because an old reference may no longer correspond to an available customer at the provider.

3. 03

   Correct the callback

   The webhook route was adjusted to receive payment events. Receiving an event is part of the path required to update invoices, but does not alone establish full financial reconciliation.

4. 04

   Check the changes

   The evidence records PHP syntax checks and an HTTP 200 response from the route. Final confirmation of the invoice update depended on replaying a payment event in that environment.

The work

Improvements to Brazilian tax ID validation, removed-customer handling and Asaas event processing.

• Customer and billing link validation
• Payment event handling
• Customization of a third-party module

Customer records and charges need to stay connected

The module handles customer information that passes between systems. An invalid identifier or a reference to a removed record can affect the workflow before payment callbacks are considered. The customization addressed those documented scenarios.

This type of maintenance starts with understanding the existing integration. The case does not describe rebuilding the entire CRM or implementing every Asaas API feature. It demonstrates a focused intervention in a purchased module, reviewing the behavior needed by the operation.

A responding route is one validation step

After the correction, the callback route responded to the HTTP check. That verifies one part of communication. Establishing the complete workflow still requires receiving a relevant event and observing the correct update to the corresponding invoice.

The documented result is updated code and a validated route, with financial acceptance testing dependent on the installation environment. A new proposal should identify the module version, license, customer scenarios and events that will actually be checked.

Delivery and context

Code updated and the callback route validated. Financial acceptance testing is required for each installation.

Frequently asked questions