Summary
Intentionally, Join It supports complexity when it comes to relationships between Memberships and Payments. Through a simplified UX, we make attempts to hide this complexity from our customers - but there are times when it's important to make a distinction.
Payments can either be:
Directly related to a Membership
Related to a Membership by being under the same Account
Details of Core Concepts
Related Payments on a Membership Record
On a Membership Record, when viewing the Payments - there might be a section of Related Payments (see screenshot below).
The Related Payments show payments that are owned by the same Account, but not directly associated with the Membership Record that's currently being viewed.
Memberships and Payments do not have a one-to-one Relationship
The simplest relationship between two objects would be a one-to-one relationship - for every one membership there is one payment.
At Join It, we intentionally chose a more complex relationship - for example, if someone is purchasing 2 memberships in one transaction, we wanted a structure that would support 1 payment covering both of these memberships.
Therefore, we decided on a one-to-many relationship between Payments and Memberships. One Payment can cover many Memberships.
A Membership is owned by an Account
Within Join It's architecture, there's a concept of a 'Membership' and an 'Account'.
Accounts own 'Memberships' and a single Account can hold many memberships.
A 'Membership' is the actual record that represents the membership information - and a Membership object has traits such as:
Membership Type
Status
Expiration Date
An 'Account' represents the user - and an account object has traits such as:
Password
Payment Methods