Design Considerations
Legal and Regulatory Compliance
Before designing your notification service(s), be sure to take into account all related regulatory requirements and any rules that your partner bank may have in effect. For example, are you familiar with the CAN-SPAM Act? A full analysis is beyond the scope of this article. Please refer to your Q2 Expert and your banking partner for additional assistance.
Gaps in time
Any realtime notification system needs to contend with or be aware of a concept that, in this segment, we will refer to as "Gaps in Time." These are situations where an event occurs for a moment in the lifecycle of your Customer, but that for a variety of reasons the notification does not see final delivery to the Customer for some length of time after the moment.
Are events received over realtime guaranteed to be unique?
For a variety of reasons, the answer is no. For example, what if a service subscribed to the bus plucking off the message fails to .Complete() the event correctly and then, for a technical reason, the message does not move to the deadletter queue?
Is there a mechanism to reconcile what events I do or do not receive?
Yes, by importing the Event Notification file.
Who actually sends what?
What | Who | From | To |
---|---|---|---|
Originating event | Helix Platform | Helix API | Service Bus |
Email to Customer | FinTech (You) | FinTech (You) | Customer |
Toast Notification to Customer | FinTech (You) | FinTech (You) | Customer |
Event Notification File | Helix Platform | Helix | FinTech (You) |
Do you have example content of what I should send Customers?
Yes! Contact us and we'll ensure we provide the relative examples.
Updated about 1 year ago