Overview > Tutorials > ECAL Payment Reminders

ECAL Payment Reminders

Create an ECAL Account and Schedule
- Log into your ECAL Account and follow the prompts in the ‘Getting Started Guide’ to create a schedule that can be used for general messages (optional)
- Register your Webhook endpoint to capture the User’s subscription details (e.g. email & ecal_id) as they subscribe for Payment reminders
Configure Button Display and allow Users to subscribe
- Link the Schedule to a Button. Ensure the button is linked to only 1 schedule.
- All Button Displays for your private schedule service must have the Welcome Message enabled, so your subscribers receive an instant ‘success’ message in calendar when they subscribe
- To enable the ‘Welcome Message’ go to the ‘Options’ tab in the ’edit’ section of the Button Display
- Scroll down and toggle-off the option to disable Sharing. This is a direct and personal subscription and sharing is not necessary
- Publish your ECAL ‘Sync to Calendar’ Button so users can subscribe to receive private events into their personal calendar
Publish your ECAL ‘Sync to Calendar’ Button following the instructions here
Use ECAL’s Private Event API to publish events to User’s calendar

Scenario	User syncs to the ECAL Service for the First Time.
Pre-condition(s)	● User is not already subscribed to the ECAL service for this account ● The widget has been installed and webhooks have been configured
Actor	User (New Subscriber to ECAL services)
Description	After browsing your web portal or mobile app, or receiving an email or SMS, the user chooses to select the “Sync to Calendar” link.
Trigger(s)	User clicks the “Sync to Calendar” link.
Basic Flow	1. User selects the “Sync to Calendar” link. 2. ECAL widget opens in a modal window (mobile responsive). 3. User selects their Calendar program to connect their calendar to the Event. 4. “Welcome Event” is automatically inserted into User’s calendar confirming their calendar is now successfully connected. 5. Notification sent to the registered webhook containing User’s subscription details (e.g. email & ecal_id). See Webhook configuration to recieve User’s ecalId 6. The client’s system can access Private Events in User’s calendar. See Retrieving Private Events 7. User’s calendar is linked to the client’s system via ECAL’s webhook and API
Alternative path(s)	Not Applicable.

Scenario	An ECAL Publisher elects to create a new Private Event for a User through the Client’s system.
Pre-condition(s)	● User is already subscribed to the ECAL service. ● Client’s system is integrated with ECAL for the purpose of Private Schedules.
Actor	● User (Subscriber) ● System (Client’s triggering system) ● Client (Customer of ECAL) ● Publisher (Client’s allocated user of ECAL)
Description	A User is linked to a Client’s system through the ECAL webhook and API as part of a Private Schedule. The Publisher elects to manage a Private Event associated to a User.
Trigger(s)	The Publisher elects to manage a User’s Private Event/s.
Basic Flow	1. Publisher elects to Add a New Private Event to a User’s calendar. 2. Client’s system updates the ECAL API with Event Details See Adding Private Events 3. ECAL identifies user has an existing ECAL subscription 4. ECAL inserts the Event into the User’s calendar.
Alternative path(s)	1. The Publisher elects to Delete a Private Event 2. The Publisher elects to Update a Private Event
Example Events	Examples of how our existing clients leverage Private Events: ● Insert a new ‘Payment Upcoming’ event ● Insert a new ‘Payment Due’ event ● Insert a ‘Promise to Pay’ confirmation event ● Insert a ‘Payment Overdue’ event

Scenario	The status of an event changes, whereby the User needs to be informed of the new event content
Pre-condition(s)	● User is already subscribed to the ECAL service ● Client’s system is integrated with ECAL for the purpose of Private Schedules ● An event currently exists within the User’s calendar
Actor	● User (Subscriber) ● System (Client’s triggering system) ● Client (Customer of ECAL) ● Publisher (Client’s allocated user of ECAL)
Description	The business rules of the client identify that a User is to be informed of a status change to an existing event
Trigger(s)	Client’s system has received an update, triggering business rules that require the User’s calendar to be updated
Basic Flow	1. Publisher elects to Modify a Private Event in a User’s calendar 2. Client’s system updates the ECAL API with Event Details. See Updating a Private Event 3. ECAL identifies user has an existing ECAL subscription 4. ECAL inserts the Event into the User’s calendar.
Alternative path(s)	Event is no longer valid: Publisher Deletes a Private Event
Example Events	Examples of how our existing clients leverage the ability to update Private Events: ● Payment information may have changed, such as amount due or payment due date (eg: user has entered into a ‘promise to pay’ arrangement) ● Confirmation that payment has been received: “✅ Payment Received” ● Warning that payment is yet to be received

Scenario	The business rules of the Client identify that the event needs to be removed from the User’s calendar
Pre-condition(s)	● User is already subscribed to the ECAL service ● Client’s system is integrated with ECAL for the purpose of Private Schedules ● An event currently exists within the User’s calendar
Actor	● User (Subscriber) ● System (Client’s triggering system) ● Client (Customer of ECAL) ● Publisher (Client’s allocated user of ECAL)
Description	The business rules of the Client identify that an existing Private Event is to be removed from a User’s calendar.
Trigger(s)	Client’s system has received an update, triggering business rules that require the User’s calendar to be updated.
Basic Flow	1. Publisher elects to Delete a Private Event from a User’s calendar 2. Client’s system informs the ECAL API to delete event. See Deleting a Private Event 3. ECAL identifies user has an existing ECAL subscription 4. ECAL removes the Event from the User’s calendar
Alternative path(s)	Not Applicable
Example Events	Examples of how our existing clients leverage the ability to update Private Events: ● Payment has been received ● Loan has been fully paid and / or user ceases to be a customer of client.

In this Article: