Last week ended on a positive note with better security for accessing bank data. This week, we started by enhancing the UI to display a transaction summary and linked accounts on the dashboard. We’ve also added a button to initiate the flow for connecting bank accounts. And then...the unexpected began. The classic unknown unknowns struck, reminding us that with anything new, surprises are bound to appear. So, what was this first challenge?

The Requisition ID Issue

When initiating a bank connection with GoCardless, you create what they call a “requisition.” Upon requesting a requisition, GoCardless provides an "empty" requisition—a link guiding the user to their bank’s authorization page. After authenticating, the user is redirected back to Reboard. During testing, we opened this link in a new window and closed it when authentication was complete. Not ideal for user experience, but it worked for testing. However, when redirecting in the same tab, the requisition ID was lost, preventing us from retrieving the “filled” requisition with the bank data.

Our Solution

We decided to save the empty requisition in our database with its ID. When the user returns to Reboard, we check if the requisition is filled by requesting the updated version from GoCardless. If no bank account is linked or authentication failed, we discard the empty requisition and prompt the user to try again. While this issue wasn’t technically complex, it was time-consuming, and it revealed an area GoCardless could simplify by including the requisition ID in the return link.

The Next Hurdle

Our second challenge arose with a real bank account. We successfully linked our business bank account, but after a few page refreshes… nothing worked anymore. We realized the difference between testing on a “sandbox” bank, which allows unlimited access, versus a real bank that restricts access to bank data, typically to four requests every 24 hours. Clearly, telling customers, “Reboard works…but only four times a day” was not an option.

Another Database Solution

To address this, we now store GoCardless data in Firebase and refresh it every 12 hours. The interface no longer pulls directly from GoCardless; instead, it’s stored and securely updated in our database. Initially, we aimed to avoid storing sensitive data, but this was the only feasible option. As always, our Firebase data is encrypted during transmission and storage, ensuring our customers’ data remains secure. After implementing this, we meticulously reviewed the code to ensure users can only access their data, and we’re confident enough to deploy.

Deploying this much code at once is unusual, but here it’s essential for both security and functionality. Tomorrow, we’ll push the update and focus on minor bug fixes that arise in production. The rest of this week will be lighter technically as we continue improving the UI and updating our landing page with images of Rebot, our new mascot. Once these final touches are complete, we’ll connect with our first customer to access their data and implement the rent payment automation. Here’s hoping we can finally wave goodbye to the GoCardless integration issues and take on new challenges.