This Payment Portal is designed from the ground up to work both standalone using a built in authentication system and to integrate into an identity management system like Ory specifically using the identity management system called Kratos

The system is designed to allow the easy addition of new payment processors to allow customers to process payments with a variety of supported payment processors, accepting both fiat (e.g Paypal, Stripe) and Crypto (BTCPay).

Currently it supports processing individual payments, and I am working on supporting recurring payments.

This project is designed to integrate into Brondings which is a Bitcoin bank. I have worked closely with the Brondings developers to integrate Brondings into the Payment Portal via a series of REST APIs.

The system persists using PostgreSQL via a generic protocol designed to map internal classes to tables within PostgreSQL. Without the explicit use of an ORM. The complexity and scope of the project warranted designing a custom generic protocol that has subsequently been extracted and used in other projects.

The system is deployed using a custom Gitlab pipeline that deploys a Docker image into the live and test environment when new tags are pushed onto the Master branch. Issues are also tracked and resolved using Gitlab. I worked closely with the DevOps team to integrate this system into Kubernetes.

Brondings.com

Heorot is a microservice used to sell event tickets.

Heorot supports the creation of events, global products, and local products that are associated with a global product or event. Products that are finite (e.g event tickets) have a finite amount of time before it is automatically removed from a customers basket, so it is no longer possible to complete a checkout.

Heorot supports creating coupons for products that allow customers to make use of promotions/discounts.

Management of Heorot is performed using a website that allows an administrator to:

• Create new global products, events or local products
• Edit products.
• Inspect sales data.

Heorot interacts with the Stripe API to process transactions. It integrates closely as it has to manage the creation of products, shipping objects and price objects within a Stripe store.

Interaction with Heorot happens through a REST API and is used to power Scyldings.com

I worked closely with the front end developers of Scyldings.com to integrate Breca into Scyldings.com

Heorot persists using an Object Persistence library called BKNR Datastore

In retrospect using an Object Persistence library was a mistake and I should have created mappings to PostgreSQL. Heorot creates a lot of internal objects that are persistent, this takes up an excessive amount of disk space meaning snapshots have to be regularly pruned.

Breca is a content aggregator designed from the bottom up to be highly extensible. The primary purpose of it is to pull content from a source and push it to multiple sinks.

Breca pulls the content from the source FOO, parses the content, categorizes it based on the content e.g whether its paid, video or text content, using a rules based system that works on the HTML grabbed from FOO, then depending on the sink, applies tags and pushes it.

Breca is designed so that it is easily to 'bolt-in' new types of sources (an example is Substack) and sinks, rules can be written for that new source to categorize the content (if required) and push it to the sinks.

Breca persists using a custom but simple ORM built on top of PostgreSQL's JSONB datatype.

There is an administrator panel building using CLOG this allows an administrator to:

• Monitor logs for every source.
• Add and remove new sources.
• Stop and start Breca.

Breca powers the website Praxarchy.com which uses the Ghost publishing software.

LunaMech is a FOSS administration tool for Matrix which is 'An open network for secure, decentralised communication'

LunaMech started life as a tool used to help migrate to Matrix before Matrix had the concept of Spaces but has evolved far beyond that point.

Some example functionality:

• Managing users.
• Managing rooms/spaces.
• Integration with other projects through Webhooks (notifications of sales etc).
• Reading RSS feeds and updating rooms with new entries.
• Renaming rooms for Jitsi.
• A form of 2fa using DM's.
• Permissions system.
• TUI interface within designated rooms.
• Use of Synapse admin API.
• Posting to twitter.
• Graphics using Vecto.

An administrator interacts with LunaMech via a TUI in designated 'listening' rooms.

LunaMech was designed to be modular so most of the functionality outside of managing rooms/users/spaces is provided by modules.

LunaMech has been in constant use for almost 4 years.

LunaMech's stickerpicker is a vanity product that makes use of the widgets system built into Element which is the de-facto front end for Matrix. This product allows a user to send custom stickers to rooms within Matrix.

The stickerpicker utilizes the PostMessage browser API to communicate with Matrix. Payments are taken with Paypal or crypto using Coinpayments.

Signing up to the stickerpicker is done through a website and LunaMech is used for 2fa by sending a DM to the user. When signed in the user can manage their stickers and install the stickerpicker by following the instructions. Payments are handled using Coinpayments for Crypto and Paypal for fiat.

To persist the stickerpicker uses an ORM on top of PostgreSQL to manage the relationship between classes and tables in PostgreSQL.