What GoCardless Taught Us About Building BC Extensions

Astral GoCardless was our first AppSource extension. Building it taught us more about Business Central extension development, AppSource validation and the real-world challenges of integrating a third-party payment platform with an ERP system than any training course ever could.

The idea was simple: our telecoms and MSP clients needed to collect payments by Direct Debit, and doing this outside of Business Central meant manual reconciliation. The execution, however, was anything but simple.

Lesson One: Design for the User, Not the API

GoCardless has a well-documented API that handles mandate creation, payment collection and webhook notifications. It would have been easy to build an extension that exposed these API functions directly to the user. But that would have required users to understand GoCardless terminology and concepts. Instead, we designed the extension around the Business Central user experience. Users create mandates from the customer card. They collect payments from the posted invoice. They see payment status on the customer ledger entries. The GoCardless complexity is hidden behind familiar BC interfaces.

Lesson Two: AppSource Validation Is Rigorous

Publishing on Microsoft AppSource requires passing a validation process that checks code quality, security, performance and compliance with BC development standards. The process caught issues in our code that we had missed in our own testing. It forced us to adopt better practices around error handling, telemetry and permission management. Every extension we have built since GoCardless has benefited from these lessons.

Lesson Three: Real-World Testing Is Different from Lab Testing

Our test environment worked flawlessly. The first client deployment revealed scenarios we had not anticipated: customers with multiple bank accounts, mandates that were pending approval when a payment collection was attempted, GoCardless webhooks arriving out of order. Each of these scenarios required handling that our initial design had not considered.

Lesson Four: Support Is Part of the Product

When a payment fails, the user does not care whether the failure occurred in Business Central, in GoCardless or in the customer's bank. They want to know what happened and what to do about it. This taught us that clear error messages, actionable guidance and responsive support are as important as the code itself.

The Result

Astral GoCardless is now a mature, stable extension used by clients across our customer base. The lessons we learned building it informed the development of every subsequent Astral extension. We now have multiple published AppSource extensions, and each one has benefited from the foundations laid during the GoCardless experience.