Online Payments

[rugulous]

We need to allow users some way to pay for their memberships and show entries online (whilst still allowing them to pay by bank transfer or cheque).

BYBA has received a donation of Square card payment machines to enable them to take card payments on the day, so this new solution should play nicely with Square.

The ideal solution would also play nicely with https://github.com/BritishYouthBandAssociation/OrgAdmin/issues/216 to allow us to generate a multitude of invoices.

This change may require a restructure of the current database

[rugulous]

My thoughts are:

Create an Invoice table that stores all the metadata - Date, Reference, Payment Status, Total Cost Create a InvoiceDetail table that stores details of the payee and recipients - name and address Create an InvoiceItem table that stores the line items - description, cost, count

The invoice generator then doesn't have to jump through any hoops and can read straight from here

If there are any incorrect details on an unpaid invoice then we just void it and generate a new correct one

These Invoices are then used to power the online payments - you would pay one invoice at a time. Signed up for membership? Invoice. Registered for a show? New invoice. Registered for 3 more shows? Another invoice

Happy to chat about this!

[rugulous]

In theory - this new invoice/payment structure can also be used to store any calculated discounts, so we don't just have random prices without explanation all over the place

[matt-fidd]

[rugulous]

As I mentioned last night, here's one possible way of linking everything up

... where the OrderItemTypeId is used to determine if the order item is linked to a membership, event registration, ticket sale, etc. Then if we need to check if one of these particular items has been paid for we can link back e.g. Membership -> OrderItems (where OrderItemTypeId = 1) -> Orders

Alternatively we could have a IsPaid on each entity and update this once when the Order gets paid, which stops all the extra joins but means we need to keep on top of any changes to payment status

We could also link the other way - tie the entities to the order

... or, any other thoughts you may have @matt-fidd !!

[matt-fidd]

Right, I've decided on an approach. What do you reckon @rugulous ?

ERD:

Process diagram (not sure if this makes sense to anyone else but it helped me work this through, I also think I used this format incorrectly but ah well):

Only think I can think of really that might need looking at is abstracting square out of the Order table into something else but I don't think it matters too much for now.

[rugulous]

Looks good!

Just had 3 things occur to me for the first time (sorry)

• do we need to store the Square fees (so we can have more accurate reporting)?

• do we need to record the discounts applied against the order (so it doesn't just look like the costs have gone all skewy)

• the old payments came from Stripe, do we need to map these too? If so, that's possibly where abstracting Square would be needed - could be as simple as having ExternalPaymentId (Square/Stripe ID) and a PaymentProvider telling us who processed the transaction?

[matt-fidd]

Not quite sure what you mean by square fees? - sorry.

I did think about it but I thought it might be a separate issue to add afterwards

Yeah we probably should, although not sure we need the stripe data, abstracting out is almost definitely the best way

[rugulous]

@matt-fidd sorry my bad!

I think I've answered my own question anyways - if we're using Square to be the actual financial package and just having values in OrgAdmin for sending to Square, we can ignore 1 + 3. But, for completeness, what I meant by Square fees was the commission they take off the top - e.g. if this was 20p + 1.4%, should we keep track of that for each transaction so we know that instead of £30 we're actually expecting like £29.60 or something?