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:
- Overview & Origin - The idea
- Charges & Refunds - Basic payments in Salesforce
- PayLink - Simple, secure payment links
- Payment Schedules - Flexible recurring charges
- DocumentLink - Invoices with PayLink
- Blackthorn Billing with Stripe - Subscription-based billing (Skip to here if you want to see how I manage our company’s billing today)
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.
6. Stripe Billing: Late 2018
DocumentLink is a great way to send one-time invoices. However, businesses seeking itemized receipts for each charge in a series of recurring charges needed something different.
At the beginning of 2019, our sales started scaling. We needed a more automated billing system that took care of concepts such as proration, auto-generated invoices per billing frequency, and web-based payments with ACH-push and cards. We extended our Stripe integration to consume the bulk of the Stripe Billing API and added support for subscription creation from Opportunities.
Our process is now as follows:
- Sales team members use Quotes to set products for our generated order forms. When the deal closes, the Quote lines are synced with Opportunity lines.
- Each Opportunity Product has a corresponding Stripe Billing Plan. Each Account has its Stripe Customer record. If neither exists, I create them using our app. I set the lookups on the Opportunity to their respective records and push the structure to Stripe from the Salesforce Opportunity.
- A subscription is created in Stripe, with or without a trial period (such as a contract that starts May 1 but closed on April 23), and an invoice is automatically generated and sent on the correct date with the correct days until due.
- Once paid, a Transaction is generated in Salesforce via the webhook sent from Stripe along with the invoice. The structure is related to its source Opportunity. Because of this connection, we’re able to manage sales team commissions from the source Opportunity, without any manual reconciliation. The deal, subscription, and payment are all automatically tied to each other.
- We’ve even gone so far as to create formulas within our Salesforce instance to calculate sales team commissions based upon multiple Opportunity factors: Number of years, product type, and quota attainment threshold.
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 me, firstname.lastname@example.org, or our amazing team, or try it out for yourself today with a free trial.