InvoiceCloud

Payment Export Tool

This is the first project I made for InvoiceCloud. The tool I was tasked with creating was an internal tool that would allow our client services representatives to manually send payment export files to our Billers (clients). For context, there is a period in which certain batches of payments get processed and exported. If some people's payments do not receive confirmation from their financial institution prior to the batch being settled, then their payment would not be marked as approved even if it eventually does get approved. Because of this, there may be instances where people who paid would receive penalties. If Billers notice some people have not paid, they would call our client services representatives to get a payment export file manually sent to them. The issue with that was that CS (client services) had no way of generating that payment export file themselves.

Engineers would have to manually intervene and pull the export files themselves and give them to Client Services. This wasted engineering hours when it should have been achievable by client services. That is exactly what our tool aimed to do. We made a page in our company's internal application that allowed client services to send and download these payment export files themselves. This was originally done in an application called Skynet that utilizes ASP.Net Core, C#, and AngularJS. Halfway through the completion of the project, we had a meeting with the heads of the Site Reliability Engineering department. We were then told that we needed to migrate our tool to a different application. This application was a .NET Framework 4.8 web form programmed in VB.Net. We had to scrap all our code, but luckily we were able to keep our logic. We still had to meet the same deadline, so we began to work as soon as we could. We made a new mockup in Figma that better suits the front end of the new application. We then began coding right away. We had to use various Stored Procedures to make this possible. By using multiple Stored Procedures, we were able to fill the table with useful information to guide the Client Service representatives to the right batch to export. Using a mailgun method developed within the company, we were able to successfully export Excel files to the desired email as well as download them locally. This project was able to save over 3 days of time by making a lengthy process almost instant. This project was able to be successfully added to production and is enjoyed by hundreds of our Client Services representatives today.

ReCaptcha IP Whitelist Tool

This is the second project I created for InvoiceCloud. I was tasked with creating another self-serviceable tool that allowed client services to make changes themselves which previously had to be made by engineers. For additional context, this tool allowed client services to add IP addresses to a list which would remove the ReCaptcha challenges presented to our clients. Our client-facing software required a challenge to be made in order to verify that the user is not a bot trying to retrieve data. The issue presented itself with our Billers' customer service representatives being met with a challenge each time they tried to assist one of their customers with making a payment. This was something that became very annoying very fast for them. Especially if the challenges would be on a never-ending loop. In order to fix this, a whitelist for IP Addresses was set in place. The issue with the whitelist was that it was a text file. Because of this, an engineer would have

to add a new IP address instead of our Client Services. This process was unnecessarily lengthy as tickets had to be triaged to reach an engineer. Because of this, a tool had to be made that would allow client services to whitelist the IP addresses themselves right then and there. I, along with two other engineers, made that possible. The first step was to switch from a .txt file to a database. This was necessary in order to be scalable as well as incorporate CRUD. After that was done, it was time to create the page. This tool was going to live in one of our ASP.NET web form internal applications. We first created our page and added it to the master. From there we had to put the table which would display all the IP addresses. The initial design only had the IP addresses displayed and nothing else. Although minimalistic, there was a vast amount of space that could be utilized to display important information. We decided to incorporate the date an IP was added as well as the time it was added. While this was being done, an edit/ add feature was also being developed. This was a button that would open another window and allow the user to type in the IP they would like to add. After this is done, Regex would validate the text to make sure it is valid, and another validation would be made to see whether or not the IP already exists in the table. If it did not pass any validation, then it would not be added and the user will be alerted of their error. From there, a delete function was added. This was a button on the left of the table that, when clicked, will prompt the user to confirm their deletion.

CRM Okta SSO Integration

Our company's CRM is a critical component that is accessed every day. Although the CRM is successful in achieving its purpose, there is one major drawback to using it that affects the experience of the user. The CRM login system does not allow users to make their own passwords. It relies on randomly generating a password that contains numbers, letters, and special characters. As one may assume, the password is extremely difficult to remember. Because of this, tickets for forgotten passwords were extremely common with over 10 being made per week. In order to remedy this, the presented solution is to allow single sign-on. This would allow us to access the CRM along with our other applications through a convenient dashboard. We were tasked with doing this using SAML 2.0. Although this task may seem simple enough, it is being done in a .NET Framework 4.8 Web Form.

Currently, the only way to incorporate SAML2.0 in a .NET Framework 4.8 application is with a library named Sustainsys Saml2. The documentation of this package was also very limited, and finding any solutions to problems you encounter will be met with unanswered Stack Overflow questions. Most of the solutions to our problems had to be discovered by ourselves. After the proper configurations were made, the assertion had to be handled. There was also very limited documentation on this. My partner and I had to go through each available method in the library to figure out which was the one that would suit our purpose. Within a week of completing our proof of concept, we were able to successfully log in to the CRM using Okta. We were able to complete our difficult task within the thin time slot we were given. This was part of the reason why I received an extension. Although this was solved, there was a glaring issue that needed to be addressed. The CRM could be accessed through various methods. Production, test servers, and local builds all had different URLs for the CRM. In order to address this, we incorporated a Service provider (SP) initiated flow as well. This allowed us to have multiple URLs that could request an assertion from the IdP and successfully log in to the CRM. This solved the issue with production and test servers. The issue with locally building the CRM is that each URL has a unique port number. Adding each port number as a requestable SSO URL would be impossible as there was a limit of 100. The remedy for this was to remove SSO for local builds and enable it for production and test servers. In order to understand what environment the CRM is in, configurations in the Pipeline had to be made. We created an environment variable that served that purpose. Based on the integer, it would either automatically redirect the user to Okta (production), display the original login page with an Okta button (test servers), or not display the button at all (Local Build). That is currently the hurdle we are attempting to cross, and we are working closely with the platform quality engineering team to make this possible. Currently, we are struggling to receive the environment variable as it deletes itself during the cleaning process of deployment. The proper steps and configurations are being made in the YAML file to properly create the environment variable.