Onboard

Documentation

Overview

Onboard is a platform for sending emails to your Stripe customers. Onboard is designed for businesses that use Stripe to manage their subscriptions or use Stripe to create one-off charges.

Onboard will send welcome emails to your new customers, cancellation emails to customers who churn and dunning, pre-dunning emails to deal with payment problems and much more. You can set up all these emails with just a few clicks.

Connecting to Stripe

To get Onboard to send emails in response to your Stripe events, all you need to do is authorize Onboard with your Stripe account. You don't need to set up webhook endpoints or anything like this: we use Stripe Connect to sort all of the configuration in just one clicks.

This means your data stays within Stripe. We don't store any of your customer data on our system: everything is either requested on demand or pushed to us via Stripe events.

To connect, just click the big 'Connect to Stripe' button after you've signed up.

If you want to disconnect, you can click 'revoke access' in your Stripe account settings under the 'connect' tab.

Types of email

Note: 'triggering' here refers to when an email becomes elligible for sending. The actual time it will send depends on the time settings you've set in the 'customize targeting' section of the email editor.

  • Started trial emails
    Started trial emails are sent automatically to each customer whenever they subscribe to a plan that has a trial period.

    Triggered when we receive:

    If you have a welcome sequence that you trigger using the start of your customers' trials, you can use the advanced triggering options to stop sending these emails once customers have subscribed.

  • Trial will end soon emails
    Trial will end soon emails are sent automatically a few days before a customer's trial is due to end.

    Triggered based on:

    • A customer.subscription.created event where the trial_end attribute is not null (blank). The time the email sends is based on your settings. Note: Onboard ignores Stripe's own 'trial_will_end' webhooks, because we don't need them.
  • Trial expired emails
    Trial expired emails are sent automatically when a customer's trial comes to an end and they haven't added any payment details.

    Triggered based on:

  • Purchased subscription
    Purchased subscription emails are sent when a customer either purchases a subscription that doesn't have a trial, or successfully converts from a trial to a paying subscriber.

    Triggered based on either:

    When this email is triggered by a customer upgrading from a trial, you can choose the send the email either immediately, or when the trial officially ends and the customer is charged at the start of the new billing period. Set this using the tickbox in the 'advanced options' section.

  • Renewed emails
    Renewed emails are sent automatically when a customer\'s subscription ticks over onto their next billing period.

    Triggered when we receive:

  • Upgrade/downgrade emails
    Upgrade/downgrade emails are sent when a customer changes their subscription plan.

    Triggers when we receive:

  • Card updated emails
    Card updated emails are sent automatically whenever a customer's card is updated in a customer updates their card, when their card is updated manually within the Stripe admin interface, or when their bank issues them a new card with a new expiry date.

    Triggers when we receive any of the following:

  • Cancellation emails
    Cancellation rescue emails are sent automatically when a customer cancels their account. This can be a good opportunity to ask them if there's anything you can do better, or even offer them a discount if they re-subscribe.

    Triggered when we receive any of the following:

  • Pre-dunning emails
    Pre-dunning emails are emails sent automatically to each customer a few days before their card details are due to expire, to remind them to update their details.

    Triggered when we receive any of the following:

    • A customer.subscription.created event where the subscription will renew before the expiry date of the customer's default card.
    • A customer.subscription.updated event where the current_period_end has changed and the new value is before the expiry date of customer’s default_source
    • A customer.updated event where customer has updated their default_source and their active subscription’s current_period_end is before the expiry date of their new default_source

    With pre-dunning, if a customer updates their details, we need to make sure they don't keep receiving pre-dunning emails. Therefore any queued pre-dunning emails are invalidated when we receive either of the following:

  • Dunning emails
    Dunning emails are sent automatically after a customer's payment has failed, reminding them to update their payment details.

    Triggered when we receive:

    • An invoice.payment_failed event where the customer has a subscription, the invoice closed attribute is false and attempt_count is 1

    Any scheduled emails will be stopped from sending when we receive:

    Note: Stripe retries payment sources regularly and reissues the invoice.payment_failed event each time. Onboard will ignore these retries, only triggering where the event'sattempt_count is 1.

    Note: you should turn off dunning emails within Stripe to avoid spamming users with two sets of dunning emails.

  • Invoice receipt emails
    Invoice receipt emails are sent automatically when a customer completes a payment and is sent an invoice.

    Triggers whenever we receive:

  • One-off charge emails
    One-off charge emails are sent when a customer pays for a Stripe charge. You can create emails that target specific products, packages or other charge types by specifying the charge description to target in the 'advanced options' section.

    Triggers whenever we receive:

Email editing

Onboard's email editor accepts pure HTML. It does not interfere with or change your email's HTML before it is sent (with some exceptions, below). We recommend using a tool like Litmus to make sure your email looks awesome in all email clients before you send it.

That said, Onboard does convert any CSS styles to inline attributes, and also converts relative paths to absolute paths, as per email best practice.

It also parses Liquid markup.

Liquid markup

Onboard uses Liquid markup to render profile information stored in the Stripe customer metadata attribute. Each email rendered requests a customer object from the Stripe API and makes the response available on the customer object.

For example, take a response from the Stripe API that looks like this:

{ "firstName": "Joe", "lastName": "Bloggs" }

This response can be used in the email like this:

<p>Dear {{ customer.firstName }},</p>

Which will render like this:

Dear Joe,

Default values

What happens in the example above if the customer's 'firstName' property wasn't set? The email would render as follows:

Dear ,

Far from ideal! This is why we recommend you use Liquid's default value option to avoid embarrassing blank fields. You can use them like this:

<p>Dear {{customer.firstName | default: 'customer' }},</p>

Which would render as:

Dear customer,

You can also access your sender email address and name as follows:

<p>If you have any questions just email {{ sender.name }} on {{sender.email}}.</p>

Onboard supports all Liquid markup out of the box. You can read the Liquid documentation here.

Previewing emails

Clicking 'Preview...' will show you an rendered preview of the email. It's a good idea to use the 'view for specific customer' function to check your Liquid markup tags are rendering correctly. Simply enter a Stripe Customer ID into the box in the top right and click the refresh button to see the email as it will appear to a specific customer.

Note: emails will look different in different email clients. The preview function is designed as a rough preview only: we recommend using a tool like Litmus to make sure your email looks awesome in all email clients before you send it.

Test sends

Click 'Send test...' and enter up to five email addresses (separated by commas) to send a test email.

Important note: one of the key factors in deliverability is whether or not people open and click on the emails you send. Therefore it is crucial that each of your test email recipients open every test email you send and click on at least one link inside the email to keep your deliverability nice and high.

Troubleshooting

If you have any questions, email support@onboardhq.com and we'll get straight back to you.