Reading a delivery receipt
A receipt is a sequence of states, not a verdict. Treating an intermediate one as final is the most common way a sending dashboard ends up lying to you.
Read the guide →Sending order confirmations
A confirmation is the moment a customer stops wondering whether the order went through. It is also the message most likely to be forwarded, screenshot and used as a receipt, which sets the bar for what it must contain.
What belongs in it
- The order reference, prominently — it is what support will ask for
- What was bought, at least in summary
- The amount, including currency
- What happens next, and when
- A link to the order in your own system
Send it now, not eventually
Confirmation is transactional and should not queue behind promotional traffic. Keeping the two message types distinct means a large campaign does not delay the message that tells someone their payment worked.
- Transactional sends are not filtered by opt-out suppression
- Each send is logged with its status, so support can answer from the record
- Delivery receipts are recorded where the channel provides them (SMS)
One event, more than one channel
Whether a confirmation goes out on SMS, email, WhatsApp, or more than one of them, is a decision about the customer rather than about the technology. The platform connects the accounts you hold on each channel and sends on the ones you choose.
Questions this usually raises
- Should the confirmation be in the same channel as the checkout?
- Not necessarily — it is whichever channel the customer will actually look at. Multiple channels can be connected and chosen per send.
- Can we include a discount code?
- Content is yours to compose; the platform sends what it is given. Treat a discount in a transactional message as a marketing decision with its own consent implications.
- What if the confirmation fails?
- The send records its error, and the failure is visible in the logs. A retry is a decision your system makes, remembering that a retry sends a second message.
Keep reading
Who decides whether a message is marketing
The platform asks you to declare what kind of message you are sending instead of inferring it from the text. That one field decides whether the opt-out gate applies — and the honesty of the declaration is yours.
Read the guide →One-time passwords
An OTP has three requirements and no fourth: it must arrive, it must arrive before it expires, and there must be a record that it was sent. Everything else about OTP delivery follows from those three.
Open →Shipping and delivery updates
Shipping updates are bursty and unforgiving: nothing for hours, then a batch for a whole route. The failure mode is a batch that stalls halfway through, so pacing and routing do most of the work here.
Open →Appointment reminders
A reminder works when it arrives early enough to change behaviour and says only what is needed to act: when, where, and how to change it. Everything beyond that reduces the chance it is read.
Open →Payment reminders
A payment reminder sits between transactional and promotional, and where you place it decides whether it is a service or a nuisance. The useful rule: if the recipient owes the message, it is transactional.
Open →Two-factor authentication
A 2FA message is an OTP with a security context: it is triggered by a login attempt, it is time-critical, and it is the message most likely to be complained about if it arrives unexpectedly — because an unexpected one means something happened to the account.
Open →Account security alerts
A security alert is not a notification, it is an opportunity for the account owner to interrupt something. That makes speed and clarity the only two things that matter, and detail a liability.
Open →Service and incident alerts
An incident alert arrives when something is already wrong, which is the worst possible moment to discover your send path is also down. Redundancy in the messaging layer is what makes the alert dependable.
Open →Customer feedback requests
Feedback requests are marketing in everything but name, and treating them as transactional is how a service relationship turns into a nuisance. They are the clearest case for suppression and for restraint on frequency.
Open →Scope. Whaleal Messaging is an orchestration layer over the CPaaS or BSP accounts you already hold. Your contracts, your rates and your sender identities stay yours, and nothing in the middle reprices them. Routing, pacing and logging run on the SMS channel; consent and content stay with you.