I was recently on a call with the founder of a Salesforce Implementation company new to Blackthorn, explaining how our customers and our own company use our Payments app to automate our subscription billing processes.

Chris. Wow. This is so intuitive and so easy. I want to use it myself, let alone offer it to our customers, he said.

I’ve had several calls like this. It made me realize there are likely other CEO’s, CRO’s or CFO’s or anyone really out there who could save some time and headache by learning how we automate billing.

I figured the best way to explain how to scale payments and subscriptions was to give a quick tour through the evolution of our app, and the steps we took to scale our payments and billing processes through the features and updates to our app.

But before we dive in, a little background: Blackthorn Payments initially focused on making payments easy, taking the approach of delivering functionality (going deep) instead of 20+ gateways (going wide). We support Stripe, Authorize.net, and PayPal (by API), with a focus on consuming nearly all of the Stripe API, but with the longer-term plan to go wide with gateway support. Our goal is to enable customers to achieve 95% of their unique payment processes without having to write a single line of code.

In case you want to skip to a specific use case around payments, here’s a handy section index:

  1. Overview & Origin – The idea
  2. Charges & Refunds – Basic payments in Salesforce
  3. PayLink – Simple, secure payment links
  4. Payment Schedules – Flexible recurring charges
  5. DocumentLink – Invoices with PayLink

1. Overview and Origin: 2015

Blackthorn Payments evolved out of my own need to support how I was selling and billing customers for the use of our product. The lightbulb came on in 2015 when I was using other AppExchange payments apps on my previous company’s Salesforce consulting projects. They were hard to configure (to say the least), go-live took weeks, and all required lengthy automation via code or configuration to perform minimum functions. At the time, none of them supported Stripe, today’s most innovative and popular payment gateway. I thought if I could make an app that was easy to install and use, others might also use it.

2. Charges and Refunds: Early 2016

We started with the basics: the ability to charge and refund our customers. We opted to store tokenized card credentials sensitive data (card numbers and CVV codes) never got stored, not even encrypted in Salesforce out-of-the-box, in their object, called a Payment Method. These tokens made it easy for card data to be reused for subsequent charges across multiple Opportunities or other objects.

I would call a customer to take a card number over the phone, enter it into our Payment Method object, and save the record. This action sent a callout to Stripe to tokenize the card immediately, then create a new Transaction representing the amount to charge. I then charged the card from the Transaction and got real-time feedback on payment success or failure.

3. Paylink: Late 2016

Our next challenge was creating functionality where we could send someone a link to enter their card information that was branded, simple to navigate, and worked on all devices.

PayLink was created as a way to send a configurable payment request to pay by card. The ability to change a logo, background color, card color, currency, and other aspects eliminated the need to write custom code. This was a great approach for one-time charges.

4. Payment Schedules: Early 2017

Paylink worked great for individuals who wanted to pay quickly with a follow-up email receipt. But it didn’t work for companies that needed recurring charges.

Payment Schedules were created as a way to charge customers on a flexible, recurring frequency. It’s the same approach that most gateways take for subscriptions, such as PayPal. Our most common scenario was to charge customers a set fee either monthly, quarterly, or annually. However, most customers wanted full invoices.

5. DocumentLink: Late 2017

Most billing tools create either PDF invoices or non-payable web views of invoices. We created DocumentLink as a way to send a link for someone to view an invoice with a button to pay the invoice directly from the document. It is usable on any device over the web by card and ACH pull, includes a downloadable PDF, and has merge field capabilities.

There are a lot of advantages to using a subscription-based billing model for customers and companies. For businesses using Salesforce to manage customer relationships, being able to create and manage billing and transactions entirely in Salesforce has ample benefits. Better cash flow management increased customer retention, and better financial forecasting are just a few.

So, there you have it. If you’re looking to scale your billing operations to originate simple payments or complex subscriptions out of Salesforce, these features have worked wonders for us, without having to write custom code to make it work.

Interested in learning more? Reach out to our amazing team, or try it out for yourself today with a free trial.