freinhard commented 8 years ago

A new field type in form definitions allows online payments. Use Stripe as payment gateway.

href commented 8 years ago

To implement this feature we have to look at a number of components.

Payment Provider
Prices
Charges/Refunds
Reporting

Payment Provider

Stripe is the obvious choice. Unfortunately they are still in private beta in Switzerland. That means our clients need to sign up with the beta and are not guaranteed entry. For what it's worth though, I signed up and got an invite 5 minutes later.

For integration we want to open a Stripe Connect account, which allows us to connect with other Stripe accounts. Unfortunately it's not yet possible to use "managed accounts" in Switzerland, which would allow us completely hide Stripe from the user (they would essentially just enter their bank account number).

Fee

Stripe takes a fee from each payment. We can add to this fee if we want to through Stripe Connect.

VAT

I'm not sure how the VAT(MwSt) is handled at the moment, but I assume that this is the town's problem. In any case, we need to work with towns in this regard to find out how they are doing this, because their calculations will have to change with the the added fee.

Including / Excluding Fees

We might also have to provide a way to add the MwSt on top of all payments. For example, the town might say that it needs 40.- for a daypass, so the citizen has to pay 41.50 for the town to actually receive 40.

It should be up to the town if they want to pay the fee themselves or if they want to pass that along to the citizens.

Prices

To charge anything to anyone we need to set prices. Those prices are ultimately associated with the ticket, but they are not derived from it.

I see the following places where prices make sense:

Custom forms
Reservations

Technically we could also set prices for events (for publication). This should be kept as a possibility, but I don't want to actually develop it for now. It's not a likely feature, just a possible one.

Custom Forms Pricing

Custom forms need the ability to set prices in a flexible way. Current forms have a number of options which influence the price. There are multiple items that can be ordered, different shipping options and so on.

Therefore I suggest we integrate pricing into Formcode. This could be a possible syntax:

# Personal Details
Products *=
    [ ] Govikon history book (+10 CHF)
    [ ] Govikon DVD (+15 CHF)

Delivery *=
    ( ) Pick up
    ( ) to Swiss address (+5 CHF)
    ( ) outside Switzerland (+15 CHF)

This doesn't necessarily reflect the syntax we will use and we also might end up implementing this outside of Formcode. It's technically something that we could support without it (or through some kind of extension mechanism).

Reservations Pricing

Daypasses are usually priced per pass and day. Rooms are more likely to have a single price per reservation. We should therefore:

Allow to set a price per allocation (reserved as a whole).
Allow to set a price per reservation on a calendar (that is for each date reserved).
Allow to set a price per ticket (that is for multiple reservations done in one step).

The price per allocation should be set on the allocation itself. The price of a reservation is set on the resource as such and the price per ticket is set through the form, just like custom forms.

Charges / Refunds

When filling out the form before the ticket is sent, the citizen will enter their credit card information which is then stored with Stripe. Only once the reservation/custom form has been processed will he actually be billed.

This has a few consequences:

We need a workflow state or some other way to mark a ticket as paid.
We need to be explicit about when the card is charged.
It's possible that the card cannot be charged (in which case it is up to the employee to proceed or cancel).
It must be possible to refund a charge.

A change in form data can lead to a change in the charge. This should not be possible. It should also not be possible to manipulate the charged amount. If there is any problem with the actual value, the form/reservation should be discarded and a new attempt should be made. This helps prevent disputes and errors.

I suggest that custom forms get an "accept and charge" and a "cancel" option like reservations already do. This would make the change more explicit. In any case we will have to show a popup before the charge occurs.

Since it's possible for charges to be disputed we should show a payment status with each ticket.

Workflow State / Paid Tickets

This has the added benefit of solving the problem that Rüti has with open tickets. We can be more specific about them in the future (they might still be open, but it would be clear why that is).

Charges without Credit Cards

Even if a citizen offers no credit card we can use the added pricing information to show the bill that needs to be made. This way we can always inform the citizen and the government employee about the agreed upon costs.

Reporting

With the added pricing information we can show a price for each ticket and render a simple report that shows what amounts were paid, what amounts are open and if there are any disputes ore problems.