← iOS

Push Notifications

Push Notifications and Payloads

When a push notification is sent a corresponding entry is made in the Alerts table (this may not be the case for Payment Processing and Micro Deposits). It can be retrieved by the alertId (passed in the notification “extras”) using the singleAlert endpoint.

The following are the currently supported push notifications and the corresponding alertType that is used to retrieve an alert using singleAlert. Payment Processing and Micro Deposits may not be done yet. (None are available in the alerts table, but there is an alternate way of doing this than using the keen project. Team Aviato are the folks there, and I’ve contacted them. Micro Deposits isn’t in production yet.) With Payments Processing and Micro Deposits not being in the alerts table, there is no way to determine that a specific alert/push notification is related to either of those notifications.

Currently there is no way to determine what type of alert a push notification relates to. While you can use the text of the alert to do that, that’s not a good method of doing so.

Supported Push Notifications and Payloads

LowBalanceAlert = 1              // Low Balance Alert
LowCreditAlert = 2               // Low Credit Alert
PaymentDueAlert = 3              // Payment Due Alert
BillReminderAlert = 4            // Bill Reminder Alert
LoginProblemAlert = 5            // Login Problem Alert
AccountRecoveryAlert = 6         // Account Recovery Alert
DepositAlert = 7                 // Deposit Alert
MessageAlert = 8                 // Message Alert
PaymentProcessingAlert = 9       // Payment Processing Alert
RDCAccountStatusAlert = 10       // RDC Account Status Alert
MicroDepositsReminderAlert = 11  // Micro Deposits Reminder Alert

The following are the extras that are provided for each of the notifications.

Low Balance

alertType = 1

Balance encountered that was lower than the low balance threshold.

alertId     // a UUID
accountId   // a UUID

Low Credit

alertType = 2

Available credit encountered that was lower than the low available credit threshold.

alertId     // a UUID
accountId   // a UUID

Payment Due

alertType = 3

Payment for a credit account is due soon.

alertId     // a UUID
accountId   // a UUID

Bill Reminder Alert

alertType = 4

A reminder for a user’s bills was created according to that bill’s reminder days schedule.

alertId     // a UUID
billId      // a UUID

Login Problem Alert

alertType = 5

A problem was encountered while trying to login to a user’s account.

alertId     // a UUID
loginId     // a UUID
accountId   // a UUID

Account Recovery

alertType = 6

alertId     // a UUID
loginId     // a UUID

Message

A message is created for a user from the financial institution.

alertType = 7

alertId     // a UUID
messageId   // a UUID

Deposit Alert

alertType = 8

A deposit transaction was aggregated.

alertId          // a UUID
accountId        // a UUID
transactionId    // a UUID

Payment Processing

alertType = 9

An alert to inform the user that the payment did get sent.

alertId          // a UUID
paymentId        // a UUID
Context on the payment processing alert:

When a bill payment is created using the task flow there is a point where the clients get an event for reviewing the payment that is about to be created, and then in response the clients send an event up to confirm the payment.

After the payment is accepted the clients receive an event telling them that it went through. A scenario came up a long time ago where a client dropped connection between confirming the payment and receiving final word from the API that it went through. A user ended up making several payments because the clients just showed an error, even though the payment actually went through.

What was done to fix this was to say: “Ok, if I lose connection or have some error in between telling the API to confirm the payment and getting a result back telling me whether it worked for sure, I’ll show this alternative success screen that says “Payment Processing” and tell the user we don’t know for sure.” In addition to this, there is a task event that the clients send up after getting the final result to tell the API that we receive it. It’s some kind of PaymentAck task event. If the API never receives this acknowledgement event from the clients they will send a notification to them after a bit to say that it finished one way or another and they should do a sync to get updated payments.

It’s unclear if this is still implemented or if it works.

RDC Account Status

alertType = 10

An alert to tell the user about changes to their rdc account(s).

alertId		// a UUID
??          // There is no further information that I could find to indicate
            // there was more infomration

Micro Deposits Reminder

alertType = 11

alertId
externalTransferAccountId

This may not yet be in production.

Reference