Part 16: Integrating 3rd party Lightning
Introduction
This guide aims to program a website to accept “Bitcoin”. In the previous tutorial, We added “strike” as a standalone project. This time we are going to fully integrate it into our “server” and “CDN” (“sr.js”)
The SQL
The SQL in this release changed a lot as we are now offering multipile payment types we could no longer rely on the BTC address to be the join across the tables. Also because a lightning payment requires an amount which we do not always have we cannot cache a lightning address the way we do a Bitcoin one.
As a result, we implemented a session which is based on “uuidv1”
We changed the name of the session table to “usersessions” added a session id as well as changed address into 2 fields “btcaddress” and “lightaddress”. Note we could have used an address lookup table here to manage many types, however, we will most likely only support BTC and Lightning(if this changes we can easily implement this change)
We also added a timestamp so we know when the session was created in case we ever decided to add features such as cart abandonment etc.
CREATE TABLE `usersessions` (
`id` INTEGER PRIMARY KEY AUTOINCREMENT,
`processed` INTEGER DEFAULT 0,
`swept` INTEGER DEFAULT 0,
`userid` INTEGER,
`net` INTEGER DEFAULT 1,
`amount` TEXT DEFAULT 0,
`paymenttype` INTEGER DEFAULT 1,
`sessionid` TEXT,
`sessiontime` INTEGER,
`btcaddress` TEXT,
`lightaddress` TEXT
);The only other changes we made was to replace the “address” join in other fields and use “sessoinid” as well.
The Code
The branch for the code for this release can be found “here”
WWW
We made one small change to the init function and that as to pass in the ability to turn Lightning on or off.
<script type="text/javascript">
/*
0 = server url
1 = animated
2 = quantity count
3 = cdn url
4 = uid
5 = theme
6 = billing address
7 = shipping address
8 = start country
9 = lighting enabled
*/
//local
SR.init([
"http://127.0.0.1:3030/",
false,
15,
"http://127.0.0.1:8081/cdn/",
"3",
"",
1,
1,
"GB",
1
]);
CDN / SERVER
Most the changes this time were in “SR.js” the “server” was obviously updated to handle the new requests. As I said we are no longer going to be listing all the code (as it is getting too long to read in a blog format) we will cover the salient updates.
Session Generation
We now store a cookie in a session which means everytime you now do a hard refresh you call the server and create a new session. This not only speeds things up allows us to have multiple payment types in one session. Note we did not retrieve the cart contents on a hard refresh but we will do that in a future update.
It also has the added bonus of giving us a preloader (in a way) which use (at present) to generate a BTC address but can make it do a lot. One idea as mentioned above is to send the user cart so we maintain cart integrity over time, hard refreshes etc.
Multipile payment types
Now we have Lightning and Bitcoin to chose from this branches a number of UX flow and if we added more the complexity would rise more so we had to refactor the whole address/generation functionality on both the CDN and SERVER.
Server webhooks
We had a lot of code in server webhooks which did not have to be there so we removed it and refactored the function.
Misc
We fixed numerous bugs and refactored how a lot of the server code is working. It is a lot more friendly to work with now.
Admin
We made minimal changes to the admin, mainly the being able to deal with Lighting payments and the new session code. In a future update, we will focus exclusively on the admin as there is a lot we can be adding to improve this section.
Conclusion
This now gives us a pretty decent platform to deal with Bitcoin and Lightning payments. Of course, we are going to replace “strike” at some point with code completely under our control but this is adequate for now.
Next time around we will either clean up all the code and do a full regression in which case there will be no tutorial or implement an address cache method to be able to run ECS without any BTC node running on the server.
