Fintech Messaging for Wallets, Payments and Digital Remittance
Between "sent" and "received", users want to know where their money is right now.
Horizon Dit supports fintech messaging for wallet providers, payment platforms and app-based remittance services in the UAE and GCC. Events from your KYC, ledger, payment and payout systems turn into status messages: verification progress, transfers in transit, declined payments, refunds, limits and security changes. Users get them inside your app by Push, and through SMS or Email whenever the app is out of reach, as do recipients abroad and the merchants you pay out to. SMS and Email messages can go out in English or Arabic.
A transfer in progress or a payment awaiting confirmation is money the user can no longer see. Without a status update, the next move is a support ticket or a second payment, and an app-only business has no branch where anyone can walk in and ask.
Sign-ups stall at verification
Documents go in, then nothing comes back. A user who cannot tell whether review has started, or which document was rejected, rarely returns to finish. The check itself belongs to your KYC process; telling the user where it stands is the job of messaging.
App-first is not app-only
Push works only while the app is installed and notifications are switched on. The cases where a message counts most, a lost phone, a locked account, a recipient abroad who never downloaded the app, are exactly the ones where the app cannot be counted on.
Rules that follow the licence
In the UAE, payment service providers and e-wallet operators licensed by the Central Bank work under the authentication and instant-messaging restrictions that apply to banks; fintechs licensed in DIFC, ADGM or other markets answer to their own regulators. Under any licence, a genuine message has to stand apart from impersonation scams and never ask for a code, PIN or card number.
A payment provider's systems already know when money moves, stops or comes back. What users see of it comes down to whether each of those events produces a message, and whether it lands with the right person: the account holder, the person receiving a transfer, or the merchant waiting for a payout.
Horizon Dit sends those events as status messages through the channels your licence allows, with promotional traffic kept on a separate track under the applicable consent and marketing rules.
When a sensitive change needs confirming, such as a new device or a new beneficiary, the user is sent to the confirmation step set by your security policy; nothing is approved through a reply.
[Money Events]
The Money Events Worth Telling Someone About
Behind every card is an event one of your systems already emits, and the label underneath names which one. Most messages go to the user; recipients abroad and merchants get messages of their own.
KYC Status and Document Requests
Users hear when their documents arrive, when review starts and when it ends, and exactly what to fix if a document is unreadable or has expired. Each request points back to the app for the upload, while the documents and the decision stay with your KYC process.
Examples: Documents received · Under review · More information needed · Verification complete · ID expiring soon
EVENT FROM: your KYC or onboarding system
Account Readiness and Limits
Once verification clears, the user learns the wallet is ready and what it can hold or send. As spending nears a daily or monthly ceiling, or a higher verification level lifts it, the new limit is spelled out before a payment fails against it.
A transfer or payment is confirmed when it leaves, updated while it is in progress and closed off when it lands. Incoming money, completed top-ups and pay-later charges are reported along the same lines.
Examples: Transfer sent · In progress · Money received · Top-up completed · Pay-later instalment charged
EVENT FROM: your ledger or payment processor
Failed, Declined and Returned Payments
When a top-up is declined, a balance falls short or a transfer bounces back over wrong beneficiary details, the message names the cause and the fix. A payment held for review gets a message too, so the user does not try again and pay twice.
Examples: Card declined · Insufficient balance · Transfer returned · Held for review · Pay-later instalment charge declined
EVENT FROM: your payment processor or transfer partner
Refunds and Reversals
Users are told when a merchant starts a refund, when the money lands back on their card or wallet, and when a duplicate charge is reversed. Dispute outcomes close the loop.
A new device linked, a passcode changed, a card frozen from the app or a beneficiary added: each produces an alert that says what changed and how to report it if the user did not make the change. Anything that needs confirming goes through the confirmation your security policy requires, via Customer Verification, never a code sent back by reply.
In remittance apps, the person receiving money often lives in another country and has never opened your app. They can be told a transfer is on its way or has reached their bank account or mobile wallet, wherever the channel is available in the destination market.
Examples: Transfer on its way · Credited to bank account · Credited to mobile wallet · Recipient details needed
EVENT FROM: your transfer partner or payout network
Merchant Payouts and Disputes
Payment platforms answer to merchants as well as to the people paying them. Payouts sent or delayed, settlement reports, chargebacks with a response deadline and documents requested during merchant onboarding each reach the merchant when the event occurs.
Examples: Payout sent · Payout delayed · Settlement report ready · Chargeback opened · Business documents requested
EVENT FROM: your settlement or disputes system
[Channels]
In the App First, Outside It When Needed
Most of a fintech user's journey happens on one screen. Three channels cover it: one inside the product, and two that reach people the app does not. Both SMS and Email can carry English or Arabic text.
Push Notifications
Status changes delivered within your app, one tap from the place where the user retries a payment, uploads a document or freezes a card.
SMS
The route outside the app, for users who have switched notifications off, a phone that has been lost or replaced, and recipients abroad who never installed the app at all.
Email
Payment receipts, refund confirmations, document requests that link to the app, and settlement reports for merchants: records a user or a finance team will want to file.
RCS can be added for recipients whose phones and networks support it.
[Solutions]
Where Verification, Routing and Coordination Meet a Payment Flow
Each Solution attaches to a different point in a fintech service: a sensitive change on the account, a message crossing borders, and a document check that runs over several channels.
Customer Verification
A confirmation step when a new device is linked, a beneficiary is added or an account is recovered, with the method chosen by your own security policy. The message points the user to the step; the step itself does the confirming.
Messages to users and recipients in many countries go out over delivery paths chosen for each destination network, rather than one route for every market.
A verification sequence spread over Email, Push and SMS (document request, reminder, result) runs as a single sequence, so the user is not asked twice for the same file.
Six States of a User's Money, Each With an Update of Its Own
Each stage below is tagged with the status of the user's funds. That status is the question behind most messages a fintech app sends, and it decides how urgent each one is. Security events can happen at any point, so they run across the journey instead of belonging to one stage.
Sign-Up & Verification
Documents are submitted, reviewed, then accepted or sent back. Every turn of the review is reported, and any request opens the upload screen.
Funds status: None yet
Ready & Funded
The wallet opens, limits are set by verification level, a card is linked and the first top-up lands.
Funds status: Available
Money in Motion
A payment, transfer or pay-later charge is under way. The user hears that it has left and, when it takes time, that it is still progressing.
Funds status: In transit
Arrival
The transfer completes, the recipient abroad is told, and the merchant's payout is sent.
Funds status: Settled
Exceptions
Declined cards, short balances, returned or held transfers and reached limits each come with the reason and what to do next.
Funds status: Stopped or held
Refunds & Disputes
A merchant issues a refund, a double charge is undone, a chargeback opens or closes. Each step tells the user or the merchant where the money stands.
Funds status: Returning
[What Changes]
Less Guesswork for Users, Lighter Queues for Your Teams
The effect of status messaging shows most clearly in the work it takes off support, operations and risk teams, and in users who carry on instead of giving up.
Transfers That Explain Themselves When users can see that a transfer is in progress or complete, the question of where the money has gone gets answered before it reaches support.
Sign-Ups That Keep Moving Users who know which document is missing, and where to send it, are better placed to finish verification instead of leaving it half done.
Failed Payments Users Can Fix A decline that names its cause, such as a short balance or an expired card, gives the user something to change before trying again, and a held payment is not sent a second time.
Refund Progress Users Can See A refund whose progress the user can follow removes a reason to raise a dispute over money that is already on its way back.
Payouts Merchants Can Plan Around For payment platforms, settlement and dispute updates sent as each event occurs give merchants a clearer view of their cash than waiting for the next statement.
[Integration & Controls]
What Sits Between Your Ledger and the User's Screen
The status messages described here rest on four platform components, each linked to its own detail.
Event Sources
KYC and onboarding systems, ledgers, payment processors and payout systems can be connected through the API and webhooks. Those events can trigger messages, with the result of each delivery going back to the originating system.
Role-based access separates the people sending status messages from those running promotions. Delivery records and messaging history show what went out, and account activity logging shows who did what in the account.
Horizon Dit watches the traffic on its platform for signs of fraud or spam, which protects your sender and the account you send from. Whether a payment is suspicious remains your risk team's call.
Yes, after they are connected through the API and webhooks. A status change in any of them, such as a verification decision, a completed transfer or a declined card, can produce a message; the integration then returns delivery status for each one. How each system is connected is covered under Developers.
No. Identity checks, document review and the decision to approve a user remain with your KYC provider and your own compliance team. Horizon Dit sends what surrounds that process: confirmation that documents arrived, a note that something is missing, word that verification is complete. Messages send the user back to your app to upload; documents are never requested or exchanged through the message itself.
Replies are not how payments get approved in the flows described here. In the UAE, Central Bank-licensed payment providers and wallets no longer rely on SMS or email codes for authentication, and the method is a matter for each provider's security policy. Users reach that step in the app from the message, and the Customer Verification page describes scenarios such as a device change or a new beneficiary. Providers licensed elsewhere follow their own regulator's rules.
Both channels run on Horizon Dit. For institutions licensed by the UAE Central Bank, payment service providers among them, the Central Bank does not allow WhatsApp, Telegram or similar apps to be used for requesting or sharing customer data, processing transactions or sending authentication like one-time passwords. Fintechs licensed by the DFSA, the FSRA or regulators outside the UAE work under their own rules. The updates covered here run on Push, SMS and Email.
Yes. Messages can reach recipients beyond the region through international messaging, depending on which channels operate in that country and on its sender rules. SMS provides a route for recipients who do not use your app.
This one. A checkout instalment plan follows a purchase and a schedule of automatic charges, so its messages are payment events: an instalment charged, a charge declined, a refund that lowers the amount still due. Lending that runs through an ongoing account or financing relationship with a bank or lender belongs under Finance.
Yes. Role-based access decides which people may send which kinds of message, so promotional campaigns sit apart from status and security messages. Promotions go out under the applicable consent and marketing rules of each market, with support for consent records and opt-outs; Compliance describes these controls in detail.
[Ready to Start?]
Start With the Statuses Your Product Already Tracks
Send us the statuses your KYC, ledger and settlement systems produce. We will go through which ones deserve a message, who should receive each, and on which channel.
Enter your email address to receive a new password.
Please check your email inbox
Contact Sales
Get expert guidance on channels, setup, and messaging strategy.
This website uses cookies
We use necessary cookies to make our website and web-based interface work. To get more information about these cookies, how and why we use them and how you can change your settings, check our Cookie Preferences.
