 refers to their services as “Full-funnel Marketing & Sales Automation + CRM”, which essentially means a CRM that contains a marketing component. In more ways than one, SharpSpring is similar to the 

 platform — and offers standard CRM functions such as leads and forms, but they also have components like shopping cart abandonment and email marketing automation based on triggers.

Integrating SharpSpring into a website is actually fairly simple with the 

, which offers many methods/endpoints with a standard REST API. Since VIA is primarily a PHP and JS-based agency, there is a handy third-party 

 available that we use. However, for the purposes of this blog article, we are going to look at the API itself and the following example:

A web application that needs to send user data to SharpSpring as a lead and then place the lead into a custom list.

To create leads, SharpSpring offers the "createLeads" method, which can take up to 500 objects (though only 250 are recommended at once). A lead is only required to have an "emailAddress" (

When creating leads, if a lead already exists, the API will return object-level errors, which won't prevent the entire creation from failing.

So for our example, our application would send our user data to SharpSpring using the "createLeads" method and passing objects that contain "emailAddress", "firstName", and "lastName".

Once the request is returned, we will add them to our list.

Similar to the lead methods, list has the "addListMembers" and "addListMembersEmailAddress" methods.

Our team prefers using the "addListMemberEmailAddress" method since users only have to pass the email address versus the lead ID, which is a little easier to manage without keeping track of it. 

Adding a lead to a list is that easy, only requiring the lead email address and the list ID."

To note, this call is limited to 500 leads (there is no note on staying near 250 like the createLeads method).

Putting this all together in an example class, I have two methods, "createLeads" and "addLeadsToList". Both methods take an array of lead items, while "addLeadsToList" also takes the list ID.

As seen here, even without a library, the SharpSpring API is simple and straightforward to use.

As an added bonus, at the end of the script, we can output all the members from our list by using the "getListMembers" method. With this method, one just needs to pass the list ID.

Now you can create leads, add them to a list, and then output all the leads that belong to said list.

If you are looking for CRM integrations like SharpSpring or HubSpot into existing web platforms, our 

Backend Development

PHP, Javascript & React

Interactions with SharpSpring

 for invoicing subscriptions to users. While FreshBooks previously met PVA needs, in the last year or two there have been numerous bouts of API downtime and a confusing API migration that led the VIA team to explore other solutions.

Knowing FreshBooks was already using Stripe for the actual payments, our development team began looking into the 

 product as a replacement service, to fully integrate into Stripe. As part of this process, we had to consider how all of the data would migrate, how we would need to implement this on the website, how we would handle prorations, and the actual rollout of all this to an active subscriber base.

As noted earlier, FreshBooks already uses Stripe to handle the payments in the backend while FreshBooks sits on top and provides the invoicing layer. Migrating to Stripe cuts out the middleman, but also involves migrating all the user subscriptions from Stripe to Stripe — sounds strange but FreshBooks organized the subscriptions in a manner that our team needed to assess and change.

High level, the first step was to create new subscription products in Stripe. Once that was completed and documented, we imported the existing customer base into Stripe so every user was at least accounted for as a customer. At this point, Stripe was populated with usable data and products.

While not necessarily falling under the migration portion, the next step required adding new Stripe-related fields to our local subscriber database and adjusting the registration process to use Stripe to process payments and invoicing.

This total process was QA'd heavily, with pages of scenarios created to address all the known possible outcomes and multiple people testing each scenario out, to account for variability.

The biggest challenge in migrating existing subscriptions into our new subscription system was doing it in a timely manner while not creating too many artifacts.

The migration can be done when a user's subscription expires, but the PVA offers yearly subscriptions in addition to monthly and day passes, so in this case the migration couldn't be completed for at least a year as waiting for subscriptions to end wasn’t possible.

In the case of yearly subscriptions, the subscription would essentially start on the day of migration and a user would receive a proration of what they paid minus what time they have already used.

For example, if a PVA customer paid $400 for a yearly subscription 3 months ago, then they’ve used 25% of it (or $100). They would be prorated $300 and then invoiced $100 for the new subscription. Again, that subscription would basically restart on the day of migration.

To prevent any sort of bug from affecting the entire user base, the rollout of the Stripe invoicing system was limited to batches of users, starting with a select ten and increasing every week by a few hundred. This process was completely automated, sending a notification a week before and migrating the subscriber to Stripe the following week, issuing the proration, and informing the user.

During the rollout, the FreshBooks invoicing system was still live, with both systems being side by side. New subscribers would be funneled through Stripe while users not in that week's batch would see no difference.

As part of any new large feature, we prioritized QA, while also knowing that it wouldn’t be possible to detect all bugs. We were prepared for this and did in fact encounter some during the rollout. However, with this batched rollout, any bug didn't affect the entire user base and we were able to fix it without major disruption.

As mentioned above, users that were to be migrated were notified a week earlier and again on migration, with a link to pay their new Stripe invoice.

We were strategic in our approach of batching the rollout, so that our support team wasn’t flooded with questions at once, but rather in timely groups. This allowed us to assist PVA customers in the most efficient way possible.

In addition to email notices, banners were placed on the website notifying users of the move from FreshBooks to Stripe, and supporting copy and documentation were written beforehand to ensure ease and organization for our support team.

Going into this migration, our team knew we were in for a challenge as the site was live and active with thousands of subscribers. All of our planning and QA'ing paid off, as we only encountered the expected minor bugs coming out of the batched release.

While the batching is still active, the project has been a success overall, as users had/are having a relatively seamless process moving invoicing systems and now the PVA has a more steady and robust invoicing system powered by Stripe.

VIA has the ability to create custom eCommerce experiences and integrate existing platforms and solutions such as Stripe, PayPal, WooCommerce, and Shopify to provide a tailored experience. 

Migrating from FreshBooks to Stripe for invoicing

Non-profit Marketing

UX / UI

Platform and CRM Integrations

Illustration

Fund For The Arts

Back-end development does all the heavy lifting behind the scenes. From database design and deployment to writing application programming interfaces (APIs) to simply storing and serving your content, we’ve got you covered.

Backend Development

Backend Development: Case Studies

01

Fund For The Arts

Backend Development: Blog Posts

Interactions with SharpSpring

Migrating from FreshBooks to Stripe for invoicing