The idea is that we will marshal the payment, send it to the campsite’s
instance by email, and then unmarshal it as a booking, that way we can
have a one way replication from the internal to the public instance with
a way back to send the payments.
For testing purposes, i just create the booking in the same instance.
Had to change the booking relation’s permissions to allow insert from
a guest, much like for payments, because the notification from Redsys
comes as a guest connection. I need this even with all the
marshal/unmarshal shenanigans because not everyone will have an internal
instance, thus need to allow bookings from guest connections.
Customer wants this because the booking is not automatically created,
thus it is possible to overbook. They want to accept the payment of
those that they can actually book.
After months of keeping what does the ACSI checkbox mean, now customer
told us that we should add a discount based on a series of
arbitrary conditions that, and need to be done NOW!
There is no UI to edit the conditions due to lack of time.
Redsys are a bunch of … something: they **only** recognize HTTP 200
as success; HTTP 204 apparently is an error for they, and don’t get
me started in not understanding what to do with an HTP 301.
Let’s just give in, and relax.
Had to do a couple of changes to the database: add the currency_code to
the payment relation, to format the price according to the payment’s
currency instead of the company’s; and the reference SQL function, to
replace the equivalent golang function, so that i can use it to index
payments.
The rest is mostly the same as any other page, except that the
individual payment’s page is not a form, but a regular info dump.
I also moved the payment settings as a sub-route of payments, as i
believe this makes more sense than an additional user menu item.
Customer wants to require a down payment of 30 % for bookings made
one week or more before the actual date, and to make the full payment
otherwise.
This would require yet another relation to keep these values. Fuck it;
i added them to the function, as they are very unlikely to change.
That forced me to change the test for draft_payment to use relative
dates, otherwise there is no way i can have stable results in the
future.
To send the actual mail with sendmail, i have stolen the code from
go-mail[0] and removed everything i did not need. This is because there
is no Go package to send email in Debian 12, and this was easier than
to build the DEB for go-mail.
Once i have the time….
[0]: https://go-mail.dev/
I have to basically do the reverse of signing the request to verify that
the notification comes from them. Lots of code just for that.
I return the changed status from the PL/pgSQL function because i will
need to email customers when a payment is completed, and i need to know
when.
jordi fita mas