Skip to main content
Waffo Pancake sends two independent streams of email, both configured under Settings → Notifications and controlled separately:

Customer emails

Go to your buyers — receipts, renewals, cancellations.

Merchant notifications

Go to your team, via a per-store recipient list.
The bell icon in the Dashboard header is a preview of an in-app notification centre not yet connected to live data — it stays empty. Email is how notifications reach you today.

​
Notification Settings

Configure which notifications you receive in Settings → Notifications.

​
Customer Emails

Transactional email the platform sends your buyers under your store’s name:
All of these are always on except Upcoming charge, which you can switch off per store under Settings → Notifications → Customer Emails. Switching it off stops the reminder for every subscription in that store, yearly plans included — card networks expect buyers to get advance notice of an annual renewal, so meeting that expectation is then your responsibility. The rest are transactional records the platform must send as Merchant of Record; they go out automatically and need nothing from you.

​
Merchant Email Notifications

Merchant notifications go to a recipient list, not a single fixed mailbox. So finance takes chargebacks and past-due while operations takes only new orders. Add recipients under Settings → Notifications.
Emptying the list stops merchant notifications entirely — there is no fallback address. Removing the last recipient asks you to confirm, because from then on nobody is notified.
Customer emails are a separate pipeline, unaffected by this list.

Manage recipients via API

Add, update, and remove notification recipients programmatically.

​
Webhooks

Email suits people; webhooks suit systems. If you need events delivered to your own service — to revoke access, sync a CRM, or drive your own alerting — subscribe to webhooks instead of parsing email. Webhook events and email notifications are configured independently: turning off a merchant email does not stop the matching webhook, and vice versa.

​
Best Practices

Give each recipient only the events they act on — finance takes chargebacks and past-due, operations takes new orders. A mailbox that receives everything gets filtered into a folder nobody reads.
Subscription past due is the one notification tied to money you have already lost. Make sure at least one recipient subscribes to it.
Recipients are addresses, not accounts. Pointing one at a team alias rather than an individual keeps notifications flowing when someone is away or leaves.
If a system needs to react to an event, subscribe to the webhook. Email is for people.