• Events

• LocalGroups

• Activities

• Teams

• KnowHow

• RecentChanges

Milestones

5. Payment routines

The payment routines here can be implemented either as part of ams-front, or in a standalone website. There's no real dependency between them and the payment routines don't require any login. So I would almost suggest this to be a separate service.

The service should two URLs:

1. /payonline/(.*)
2. /donate/(.*)

The pages are exactly the same, and just aliases for each other. The optional value in (.*) is a payment reference. They should support the following parameters:

• amount - the amount to pay (default: 50)
• period - the period, m - monthly, y - yearly, o - one time (default: m)
• noform - 1 if no form should be displayed, only a button to pay (default: 0)

The logic should be wired up like this:

• Validate the payref (see below)
• If noform == 0:
• * if payref starts with FD: display donate form (with amount being the only field)
• * if payref starts with FC: display payment form (with amount and period being selectable)
• * if payref starts with anything else: display a payment form (with amount being the only field)
• If noform == 1 OR if a form has been submitted:
• * display a message: "you are going to transfer $amount ($period) via Concardis using payment reference $payref, to proceed, click on this button:"
• * if the payref starts with FC, then add two letters to the payref according to the following logic:
• ** yearcode = a letter A to Z (where 2012 is A, 2013 is B and so on)
• ** monthcode = a letter A to L (where January is A, February is B and so on)
• ** if period == m: add the letters $yearcode and $monthcode
• ** if period == y: add the letters $yearcode and Y
• ** if period == o: add the letters $yearcode and Z

• * display a <form> with hidden values (see Concardis documentation), and just one <input type="submit"> which will submit to Concardis. It's a bit tricky to create this form properly with all the values, but it's well documented and you can have a look at our existing code.

The way we will use the above is:

1. When a new donor/supporter has selected how much they will pay, in ams-front, there will be a redirect to the above system, like

   • https://payment.fsfe.org/payonline/FC0873435?amount=50&period=y&noform=1 This would then skip the input form (since we already know it), but display a <form> with hidden values which when the user clicks the submit button submits the right details to Concardis.

2. When we send emails to people asking for donations, we will include a link like:

   • https://payment.fsfe.org/donate/FD0983434/ This would then display an input form where the person can determine the amount, after which the same <form> with hidden variables as in (1) is displayed.

3. When an existing supporter's credit card expires and they need to setup a new one, we'll mail them like this:

   • "To setup a new payment, please go to https://payment.fsfe.org/payonline/FC0983434", which will display the form to select an amount and period.

4. When someone places an order for merchandise which they should pay, we will forward them to a link like:

   • https://payment.fsfe.org/payonline/MP3498734?amount=27&noform=1 which will display a button which takes them to the payment processor

The documentation for Concardis is here: https://support-payengine.v-psp.com/en/en/guides/integration%20guides/e-commerce

One version of code which create a form to submit to Concardis is here (for web orders): https://git.fsfe.org/FSFE/fsfe-website/src/branch/master/cgi-bin/order-payonline.pl Another version (for supporter payments) is here: https://git.fsfe.org/jonas/dmmy/src/branch/master/payonline.php

Validation of payref

The payment references should have one of the following forms:

• FCnnnnnnnnXX
• FDnnnnnnnnXX
• DAFSPCKnnnnn
• MPnnnnnnnnnn
• TXXXnnnnnnnX

For FC, it can also be just FCnnnnnnnn, since the XX part is added later. For FD, the XX is an optional part.

Completed

1 - Integrate fsfe-cd with "fsfe-cd"

Current fsfe-cd implement its own SQLAlchemy mapping by mimicing what it sees in the database. There's a newer and more complete SQLAlchemy mapping for the same database which we have here: https://git.fsfe.org/fsfe-ams/supporterdb/src/master/fsfe_cd/mapping.py We would like to integrate these so they use the same mapping. The advantage would be that if we do, then the new mapping.py has all the support which is needed to not only read but also change database fields, and knows what to do when some fields are changes (send email to inform about changes, etc).

So this milestone would be complete when fsfe-cd uses the mapping.py from supporterdb instead of its own.

2 - Present settings in settings view

When this work is completed, someone can login to https://my.fsfe.org/ and see their current settings, address, etc, retrieved from the fellowship database. This requires implementing an API call from ams-front to http://fsfe-cd/api/fellows/ to get the information relevant, and fsfe-cd needs to be passed appropriate authentication parameters with it (taken from the User object of the logged in user, specifically the access code and id token).

The parameters which should be published and be able to be viewed in this pane include:

• Email
• Backup email
• Title
• Full name
• Street address
• Post code
• City
• Country (select box)
• Language
• Birth date
• Opt-in to communication from the FSFE (checkbox)

3 - Change settings in settings view

When work on this milestone is completed, it's possible to not only view the information in the settings page, but also change it. The same settings as those in milestone 2 should be changeable. This requires implementing a new view in fsfe-cd to handle changing data. When an API call to change information is received, the updates should be made (can be done directly, since at this point the integration of the new mapping from 1 is done).

4 - Account registration

When this milestone is complete, it's possible to sign up to make a one time or regular donation or create a new volunteer account via the http://my.fsfe.org/ website. The forms are largely there already. but the processes will look a bit different:

• When signing up as a volunteer, the form is in register/volunteer.html (but please REMOVE any mention of local groups or teams to join here. let's keep it simple).
• When signing up as a supporter (financial contributor, even one time or regular), the form is in supporter/form (here too, remove local groups and teams).

When a form is processed, it should call fsfe-cd with the data provided, and fsfe-cd should use the functions from the new mapping.py to create the relevant objects.

When creating an account, it's vital to check if an account with that email already exists! If it does, the user should be given a notice about this and be asked to login using email. This doesn't apply to one time donors though; if an entry exist for one time donations, we should simply call the executable with the new information and the executable will deal with matching this to the existing account.

Workflow

• my.fsfe.org:/
  • Has the button "Support" leading to my.fsfe.org:/signup
• my.fsfe.org:/signup
  • Has the options, "Volunteer" leading to :/signup/volunteer, "Supporter" leading to :/signup/supporter
• my.fsfe.org:/signup/volunteer
  • person.purpose = 'a'
  • form contains name and email
  • upon submit, create user
• my.fsfe.org:/signup/supporter
  • person.purpose = 'x'
  • form contains name and email
  • upon submit, create user

The mail sent when person.purpose = 'x' should contain a one-time login link to the website, with the message "to continue your registration, click here". The login link should be created the same way as when someone clicks to login with an email link on https://my.fsfe.org/login/email/ The link should direct the user to a page my.fsfe.org:/settings/contribute:

• my.fsfe.org:/settings/contribute
  • if person.purpose == 'x', or person.purpose == 'o' then:
    • form contains two boxes:
    • "Make a one-time donation" with only contribution amount.
    • "Setup a recurring donation": with period (monthly, yearly) and amount.
    • Filling in an amount and clicking OK should set person.purpose = 'o' if it's a one time donation, and person.purpose = 'd' else, and then redirect the user to our payment pages (just make a dummy redirect for now).
  • if person.purpose is 'd'
    • form contains two boxes:
    • "Make a one-time donation" with only contribution amount.
    • "Change your recurring donation": with period (monthly, yearly) and amount. (with a warning that changing the recurring donation isn't automatic, and the user will be notified when the change is done)
    • Filling in an amount and clicking OK on a one-time donation should redirect the user to our payment pages (just make a dummy redirect for now).

    • Filling in a change to the recurring donation should trigger an email being sent to contact@fsfe.org with the new details

• my.fsfe.org:/settings
  • If the user doesn't have a login name set, then this page should have a box at the top with information: "You don't have a username or password set, if you'd like to create one for future logins, or to login to FSFE services, click [here]"
  • Else, this page should have the fields:
    • Full name
    • Title
    • Birth date
    • Primary email
    • Secondary email
    • Address
    • Zip code
    • City
    • Country
    • Opt-in for newsletter
  • There should also be a link somewhere with "contribution" which leads to my.fsfe.org:/settings/contribute
  • And a link with "change password" which leads to my.fsfe.org:/settings/password
• my.fsfe.org:/settings/login
  • Allow the user to set a login name if they don't have one already
    • If the user HAS a login name, it should be possible to change it, but with BIG WARNINGS saying that if they change the login, they will lose access to any data associated with the old login name
    • If the user doesn't have a login name, they can of course enter and set one, after which they should be redirected to my.fsfe.org:/settings/password to also set a password for it.
• my.fsfe.org:/settings/password

  • Fields to set password. Take note that if the user doesn't *have* a password (for instance because it's a new user and they haven't set one yet), then they shouldn't be asked for their old password just a new one.