Make every financial moment feel immediate and trustworthy.
Deliver verification codes, transaction alerts, risk notifications, and account updates through a resilient messaging layer with clear delivery records.
14,000+ developers and product teams rely on Sent for messaging
When the message is late, the financial action stops.
In financial products, messaging is part of the transaction. Delay blocks access, missing alerts weaken trust, and incomplete records make investigation harder.
Access waits on a message
An OTP or verification link that arrives late turns a simple login into abandonment, repeated requests, and support work.
Risk needs an immediate response
A suspicious transaction alert is valuable only when the customer can understand it and act before the risk spreads.
Every send must stand up to scrutiny
Operations and compliance teams need to know what was sent, through which route, when it changed state, and why it failed.
Meet Sent: the delivery layer between a financial event and customer action.
Your system creates the authentication, payment, risk, or account event. Sent validates the message request, routes delivery, and returns a traceable status for every attempt.
Keep access, activity, and risk communication moving.
The large cards focus on verification and transaction trust. The compact cards cover risk, account visibility, and reachability.
Deliver OTPs and verification codes
Send short-lived codes through reusable templates with code and expiry variables, a defined channel order, and status tracking for every attempt.
Make transaction alerts actionable
Confirm payments, card activity, transfers, withdrawals, and account changes with enough context to recognize the event and a safe path to act.
Warn before risk spreads
Send suspicious-activity and unusual-login alerts from your risk system the moment investigation or customer confirmation is needed.
Keep balances and obligations visible
Surface low balance, payment due, limit, loan, and subscription events without forcing the customer to search for them.
Reach users when one route is unavailable
Define channel fallback for critical messages so a missing app or unsupported device does not silently block the workflow.
Engineer financial messaging for resilience and traceability.
Build a resilient verification path
Keep code generation and attempt rules in your authentication system, then use Sent for template delivery, channel routing, status events, and fallback. This separation prevents the messaging layer from becoming the source of authentication truth.
Give operations evidence, not guesswork
Store Sent message IDs and use signed webhook events to follow queued, routed, sent, delivered, read where supported, failed, and received states. Failure reasons point the team toward the correct recovery path.
Security controls for messages that move money and access.
Keep sensitive financial data out of message content, use masked identifiers, and send customers into authenticated product surfaces for protected actions.
Separate required account communication from marketing, maintain customer preferences, and apply opt-out and country-specific messaging requirements.
Keep API keys server-side, verify webhook signatures, rotate credentials by environment, and use idempotency for mutation requests.
Frequently asked questions
No, and that is deliberate. Code generation and attempt rules stay in your authentication system so the messaging layer never becomes the source of authentication truth. Sent delivers the code and reports what happened to it.
SMS, WhatsApp, and RCS. You set the order Sent tries them in, so a code can follow the path your risk and reachability rules prefer.
Yes. If the first route fails, Sent can retry, switch provider, or move to the next channel you have defined, and every attempt is recorded separately.
Only enough for the customer to recognise the event and act. Use masked identifiers and send them into an authenticated product surface for anything protected.
Store the Sent message ID. Every state change — queued, routed, sent, delivered, read where supported, failed, received — is reported against it.
Where the channel supports them, yes. WhatsApp and RCS report read state; SMS reports delivery. The status event tells you which you are looking at.
Verify the signature on every event before acting on it, keep API keys server-side, and rotate credentials per environment.
Yes. Credentials, templates, and sending rules are separate per environment, so a test send can never reach a customer.
Sent supports PCI-aligned messaging workflows: sensitive data stays out of message content, identifiers are masked, and protected actions happen inside your own authenticated surfaces. Talk to sales for the current certification set.
Required account communication is kept separate from marketing. Marketing opt-outs are honoured across every channel, and country-specific rules are applied per customer.
One API. Every channel.
Contact Sales