OnlineFundraising's data model consists of several entities which are related to each other. The data model is relevant knowledge when trying to understand how OnlineFundraising works as a system.
Overview of entities
First and foremost, the data model has the entity Contact which contains personal data about a donor/member.
A contact can have one or more different subscriptions. A Subscription links contact, agreement and payment method, hence it provides information about how a contact is paying and that they are subscribing to a product (an agreement).
An Agreement is the product or what the contact subscribes to.
A good way to describe the difference between a subscription and an agreement is to imagine a Netflix subscription plan. A subscription plan could e.g. cost €15 which is charged every 1st of the month. The amount and the frequency with which the amount is payed is contained in the agreement, while the subscription contains information about how the contact is paying, and if they are subscribing to the agreement in question.
Agreements exist in two different versions:
1. A shared agreement: Staying in the Netflix example, a shared agreement is used for multiple subscribers. If Netflix changes the price, this will affect everyone who subscribes to the agreement.
2. A personal agreement: A personal agreement could e.g. be when a donor would like to specify the amount and frequency themselves. Donor is thereby the only one who subscribes to that particular agreement, and changes to that agreement will only affect the donor in question.
An AddOn is an addition to an agreement. An AddOn could e.g. be an ekstra donation next to a membership.
Payment Method describes how the contact is paying. The payment method can for instance be card or a form of direct debit, and it works as the connection from OnlineFundraising to the corresponding payment gateway.
A Payment represents that a payment is supposed to take place.
For a payment to take place a Charge Attempt takes place for the payment gateway in question,
When a charge attempt succeeds it results in a Transaction which informs that a payment amount was transferred from one account to another. The payment state will in this case change from pending to charged. In case a payment is refunded a new transaction is created with the negative amount, and this transaction is related to the original payment.
A Refund is a separate entity in the data model and it represents the payment amount which was refunded for a payment.