Catapush is a SaaS mobile messaging platform (in-app/push and chat) designed to help financial services and large enterprises to handle their customer communications. More reliable, traceable and secure than any other available alternative, provides significant cost reduction compare with SMS.
Thanks to a standalone push notification gateway, independent of Android FCM, HMS and iOS APNs , Catapush maintains a proprietary real time direct connection with devices using XMPP protocol thus sending push and in app messages faster and having the ability to deliver messages under critical situations. In fact Catapush let the enterprise sends push and in app messages to its end user mobile device/App, even if the App is closed or during mobile connection dropouts ensuring deliverability of important messages and delivery receipts. If push notifications are critical and part of a real time system, the enterprise need to go beyond FCM / HMS / APNs “best effort” native push notification services.
Catapush is an highly scalable SaaS platform for sending data-driven transactional notifications including targeted e-commerce and personalized one-to-one messages. Ideal for building applications that react in real time. In fact Catapush provides guaranteed and secure delivery of all messages sent, real time delivery status tracking (enqueued, sent, delivered, read) of each single message sent.
If the enterprise already has an App and end users who are already using it, it can use Catapush system to enable sending reliable and fast push and in app messages. The enterprise can access Catapush notification gateway using our Restful API. Our solution is currently developed for Android and iOS platforms.
Catapush messaging platform (see Exhibit 1 below) is made up of:
Exhibit 1
In order to start sending push notifications with Catapush platform you have to:
Catapush solution adds critical features to native push capabilities offered by Android and iOS best effort push services. A background connection with devices using XMPP protocol is always established for superior message delivery and tracking performances, automatic queuing of concurrent messages, single message delivery report status tracking sent all the way back to your system in real time, message expiry time when you want the system to stop retrying to send your push message to an undeliverable recipient and the option to send the message as SMS to reach users for important messages even when data connectivity or mobile app is not available. Finally the system enable to receive request or replies to push messages sent (2Way Communication).
Catapush system infrastructure is based on an advanced proprietary technological platform. All the infrastructure is provided on Amazon IaaS services (AWS) and the virtual machines have been deployed in Ireland and Germany. The servers are monitored by dedicated software programs 24X24. All the infrastructure and components are redundant and highly available and in the event of any element breaking down, the service continues to be supplied without interruption. Great attention has been given to the procedures and controls to guarantee maximum system security. Multiregion business continuity and disaster recovery procedures (Ireland and Germany) have been set up on the virtual infrastructure to ensure the continuity of the service even in the presence of catastrophic events.
Catapush has implemented a network operation center service to monitor and manage its systems 24X7X365. In addition dedicated software programs monitor all processes around the clock and in case of abnormality they notify a technician who will respond within one hour.
Zero maintenance windows and a 99,9% uptime. Data transfers encrypted with TLS 256 Bits all way through your user app (see How the security works below)
End user must be registered / logged in on the device since without a valid login to Catapush servers it is not possible to send messages with Catapush
In such a case the SDK / App needs Catapush credentials to authenticate itself to Catapush servers. At the first start / initialization of the Catapush SDK, the customer's App, which is already authenticated on the client company's backend, asks for its Catapush credentials (see Exhibit 2 below).
Exhibit 2
The backend of the client company at this point has two possibilities:
If the enterprise does not want to implement a own user registration/ login, at least it needs to implement the verification of the end user mobile number (as Catapush does on its messaging app Catapush Messenger )
In other words, the enterprise customer can use the registration of the end user mobile phone number as a verified ID after having verified via the sending of an one time password (OTP) sent via SMS
Each end user needs to have a Catapush user account for each mobile device (mobile / tablet) used to use the
enterprise App and receive push notifications.
At any moment, only one Catapush user can be active on a device to receive Catapush Push and in app
messages.
In the case of an enterprise App/user account used on more than one device, the company should make a dashboard
available for listing all registered devices where the end user can select on which device the end user want to
receive Catapush notifications
The native notification center is unique and is managed by the enterprise App. If an enterprise had already integrated the native Push services (FCM, HMS and APNs) and would like to continue to do so even after Catapush integration can do so. In other words the enterprise would maintain internally to its App the control of the native notification center (FCM, HMS and APNs). Subsequently, when a native notification with the "Catapush" identification arrives, the App notification center will need to recognize and forward it to the Catapush SDK for its execution. In order for this to be possible, the enterprise must develop a function for the recognition and addressing of the native "Catapush" notifications to Catapush SDK (existing bank customers have already implemented the feature without any problem). Alternatively, Catapush could take control of the native notification center and manage all the notifications for the enterprise.
The behaviour of the solution in case of deactivation of push notifications at OS level varies according to the operating system and in particular:
If the end user disables push notifications from the system settings, the Catapush SDK is not awakened by the operating system when it receives the native push notification, the behaviour is exactly the same as in the case in which the mobile device is switched off or without a network connection and it depends on the value which has been set for the message expire in the "expireTime" parameter on the sending APIs.
Let's assume that there is network connection but that notifications have been disabled and that the expireTime parameter has been set to 30 seconds: if the end user does not open the App in 30 seconds the message will expire, this means that an expired callback will be generated and when the end user opens the App after 30 seconds he will not receive that message via XMPP. If, on the other hand, the end user opens the App within 30 seconds, the notification will be downloaded from Catapush servers and the App can decide how to manage it, whether to view it in the App or whether to generate a local alert.
There is no way to know at the App / SDK level if the end user has muted the notifications for a certain
notification channel of a certain App.
The notifications are silenced only on the UI side but in reality they continue to work: in fact the SDK
receives the push notification, connects to Catapush server and downloads the XMPP message.
A “delivered” callback will be generated on the server side because of that. This is the behaviour of the system
and the App / SDK cannot get around it, because it is so by Android design.
Catapush keeps message stored on in its back end queues only during the delivery process. Afterward all messages are deleted from Catapush server.
On the end user device/ SDK Catapush manages a local DB where it stores all the messages received by the SDK; however Catapush SDK has no control over the graphic of message history rendering which is under control by the enterprise App that integrates the SDK.
If the end user update the app he does not lose any historical messages locally. If he deletes and reinstalls the App instead he loses all the messages save locally unless the enterprise has stored them in their back end and provide the end user with the possibility to recover them from its server when he reconnects again with the App using the same user account
The communication between Catapush AWS servers and the end user mobile device / App regarding the message delivery, is encrypted using XMPP with TLS in SSL
Since the enterprise controls the two end points i.e. the CRM upstream where the content message is created and the mobile App downstream where the content message is delivered and rendered to the end user, the enterprise can encrypt the content of the communication upstream and decipher it downstream. In such a case the content would be transmitted encrypted over Catapush encrypted channel for greater security even compared with SMS communication
Catapush platform offers the option of sending the message (exact the same or other content to be specified before sending the Push notification) also as an SMS in fallback in the event of a message delivery error within the message validity period as defined by the enterprise and customizable for every message sent.
Thanks to its proprietary technology Catapush enables the process of monitoring and reporting the message delivery status in real-time including the possible status of “message expired”, the consequent cancellation of the push message initially sent, and the resending of the communication via SMS in fallback. These functionalities are critical for all use cases that require a certain timing of delivery of important communication while avoiding the possibility of messages duplication and customer confusion. Indeed with Native push notification services, it is not possible to cancel the delivery of a push if the message does not get delivered on the device within a certain time interval or its predefined "validity period" and you opt to use another channel (eg SMS) as a fallback.
There are two ways to manage the SMS fallback:
If the enterprise requires it is also possible to send an SMS message via Catapush as a primary delivery channel for those end users who had not a smartphone and/or the App installed yet.
In such a case it is mandatory that the enterprise uses an international mobile phone number without 00 or + eg: 3933344556677 as Catapush end user ID.
By appropriately configuring the Catapush backend, when trying to send a message to such a end user recipient instead of sending to the enterprise back end an error eg "invalid push recipient" the Catapush system will recognizes it and send the message as an SMS via a partner SMS gateway API provider eg Commify with whom the enterprise should have previously obtained credentials / purchased SMS credit
The Android SDK is written in Java and the iOS SDK is writte in Objective-C.
The minimum version for the Android SDK is: API level greater than or equal to 21 (Android 5.0)
The minimum version for the iOS SDK is: iOS version 11
The size of boths SDKs are below 1MB, about 650KB
Api & Docs Map
