Catapush Architecture and operating modes


Index

 

Solution description

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.

Components

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:

  1. RESTful API accessible from your application or web site
  2. Mobile Push Notifications Gateway which automatically integrates 2A) iOS APNs and Android FCM / HMS native push notifications services
  3. Mobile libraries SDKs for Android and iOS for push & in app messaging communication
  4. A proprietary real time direct channel with mobile devices /App using XMPP protocol (as Whatsapp does) for content delivery and delivery status tracing in real time

Exhibit 1
cata_architecture

How to start sending push messages

In order to start sending push notifications with Catapush platform you have to:

  1. Integrate our mobile libraries/SDKs in your app In a few hours integrate our iOS and Android libraries to enable reliable push notifications and in app messages in your mobile App. Follow the instructions provided by mobile cloud vendors Android FCM/HMS, iOS APNs.
  2. Register your application on our web platform When done we can connect the push notifications you are sending to the end users and the App over which they are subscribed. End users who are using your application have to register in order to receive notifications (see how the end user authentication process works described below)
  3. Call our Mobile Push Notification Gateway via Rest API Integrating our API into your backend system adding reliable push functionality is quick and simple. Just copy and paste our fully working code examples for the most widely used languages, such as PHP and ASP.NET, and in a few minutes you'll be ready to use our API to start sending reliable push notifications. Take a look at our REST Quickstart and learn how to quickly build an application that sends push notifications and in app messages using Catapush REST API.

Features

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).

Infrastructure

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/SSL 256 Bits all way through your user app (see How the security works below)

 

How end user authentication process works

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

Case 1 - The enterprise customer already has its own user authentication.

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
Catapush

The backend of the client company at this point has two possibilities:

  1. the Catapush credentials for this end user / device have already been created and therefore they get returned immediately to the App / SDK (e.g. end user / device already authenticated)
  2. The credentials for this end user / device have never been created and therefore they first need to be created on Catapush server by calling Catapush backend APIs, save this information locally and then return it to the App / SDK (e.g. end user / device authenticated the first time)

Case 2 - The enterprise customer does not have its own user authentication process in place.

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

How to manage users with multiple mobile devices

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

How Catapush co-exists with previous native push implementation

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.

How Catapush proprietary real time direct channel works

  1. The enterprise send a push message to an end user App
  2. The message on Catapush XMPP server is ready to be downloaded
  3. The end user App is closed/offline. Catapush sends a native Push to open its direct channel
    1. the native Push is a silent push (Android ) and high priority (iOS) with retry mechanism when possible
    2. The silent Push start the application
    3. The SDK downloads the message from Catapush server
    4. The SDK creates the notification locally or passes it to the enterprise App which renders it as desired eg if necessary decrypts it first

What happens if user disables Push notifications for the App on its device?

The behaviour of the solution in case of deactivation of push notifications at OS level varies according to the operating system and in particular:

iOS / APNs

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.

Android / FCM - HMS

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.

How server and in app message storage/inbox works

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

How security works: encrypted content over an encrypted channel

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

How SMS fallback works

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.

There are two ways to manage the SMS fallback:

  1. Automatically managed by the Catapush solution which in case of SMS fallback calls a partner SMS gateway API provider eg Commify with whom the enterprise should have previously obtained credentials / purchased SMS credit
  2. Managed independently by the enterprise's backend via the sending of the SMS fallback through its own existing SMS gateway/providers. In this case, the enterprise on its back end must implement a message resend functionality if it receives a delivery error from Catapush via call back API

How standalone SMS sending works

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



In which languages are written the SDKs? What are the min OS versions required?

The Android SDK is written in Java and the iOS SDK is writte in Objective-C.

The min version for the Android SDK is: Android version greater than or equal to 18 (Android 4.3)

The min version for the iOS SDK is: iOS version 10



BACK to Top