Surfcity lets you find and share parking spaces in residential areas. Yet this is not the whole story.
We have created Surfcity to solve pretty basic need we face. We live in a typical European urban space - and our friends and family members or the other visitors coming to our residential area have no means to park their vehicles. Almost all parking spaces in the area are privately owned, yet may be half of them is free at any given time! We see this again and again in many recent urban developments across our region.
You might say, fine, another 'share something' app and anyway you or your visitors would be better off using public transport or bike - and rightly so. So why did we do this?
On one side we are in the happy phase of our lives remarkable by the fact that going anywhere on our own and lightweight is almost unfeasible. You've got it, we have small kids. But we would as well as to introduce other people into something we are excited about - that the way we exchange and keep value might change forever.
We took parking space sharing use case as an opportunity to research and learn as we go on:
- how Bitcoin can be used within our service
- how does it compare with traditional payments / payout rails
- how to build a service with user privacy in top mind while fulfilling legal obligations
Why Bitcoin? Bitcoin is on trajectory to prove itself as a completely new store of value. Its unique quality properties includes predefined supply, no single point of control and transferability over internet. However there is still unclear roadmap, how and if it can be used as a medium of exchange at scale without compromising of its fundamental appeal. Here we want to tell you what concepts we have tried and discovered on the way.
We want to make easier for other people and businesses to make proper decisions on where and how to deploy support for Bitcoin payments and payouts.
So what's the job about?
Scalable private parking space sharing should not be for free (even it can definitely work that way for smaller communities). Both the risks involved and expected income for single or couple spaces' owners are quite limited. In case you own whole parking lot at lucrative location, there are other, more robust and physically installed solutions that do not rely on mobile app only. Space owners in residential areas will most likely not make any fortune on this so it can be seen as well as a help provided to surrounding community. Money involved can be seen as a way to prevent abuse of service. What do space owners need?
- Get paid for made bookings
- Minimum hassle to offer their space
- Easily set up space availability
What do people looking to book a parking space for them or for their visitors need?
- Friction-less on boarding, bookings and payments
- Be able to navigate to the space
- Protection of their privacy - nobody except parties making an agreement should get access to private data, e.g. car identification
- Be sure that the offer is trustworthy (space exists, is available and actually owned by offering party)
We decided to not to limit options regarding payments and payouts. Each Surfcity space owner can choose payout method from the ones supported and any user booking a parking space can choose suitable payment method. Undercover, Surfcity combines them into seamless service, that allows both sides to choose between fiat or Bitcoin way to pay or get paid.
Payment and payout settings
That way, Surfcity serves as a natural on boarding e.g. into Bitcoin's Lightning payments. Surfcity handles all related services under the legal framework that we describe later.
We have thrown a little of under the hood cryptography on the other challenges - namely to test, whether community-level knowledge of who is the rightful owner of offered parking space can be re-used with reasonable results within the Surfcity. As a result, space owners give and receive cryptographically signed badges as a community-driven proof of ownership. We combine this approach with other more traditional fraud-prevention techniques.
We as well want to make sure that as much as possible user data stays private. There is no account registration for using the app, identity is represented by keys stored on device. Data about cars to be parked are encrypted and can be read only by the space owner, not even by us. Encryption and decryption process happens fully on their devices so that users booking parking space have the option to do so without sharing any private information with Surfcity.
We will cover ownership verification and privacy in more depth later in this article.
Payments for parking space booking
So how does Surfcity handle payments? There were many talks about how to build fully decentralized sharing platforms. Do you remember how Uber planned to become decentralized? There are many obstacles to such architecture that can be grouped into two categories:
- How to ensure the quality and integrity of the service if it depends on realities that happen outside of the platform
- How to pay each other for the service ideally without intermediary in near real-time and make the service aware that the payment occurred
Those challenges are so serious, that we are not aware about any truly decentralized system that successfully handles both categories. Even Bitcoin can operate in decentralized fashion only thanks to the fact, that it does not require to trust and consume any data from any source external to the system. But, if we can't have both, can we solve at least the payment related one?
Classic payments service
When booking a parking space, you pay for your booking as a part of the process. After successful payment, Surfcity gives you access to detailed information regarding exact location and description of the parking space (like visible no. of a parking box) and, if needed, you can pass GPS coordinates to your preferred navigation app.
By far most widely used way to process such a payment is e-commerce payment via debit or credit card. In recent years, Google and Apple in cooperation with card payment networks and issuing banks have built convenience layers to make payment experience much more fluent as well as secure on mobile devices - they use "tokenized" representation of a card enrolled in their payment app and handle the communication with card payment networks that route it to the card issuing banks.
We implemented Stripe payment gateway that lets Surfcity users pay for booking with Google or Apple pay or to enter the card information (which is of course far from hassle-free). Surfcity now supports the following payment currencies:
|Supported currency||Minimal payment||Fixed fee||% fee|
|EUR||EUR 0.50||EUR 0.25||1.4% - 2.8%|
|GBP||GBP 0.50||GBP 0.20||1.4% - 2.8%|
|CZK||CZK 15||CZK 6.50||1.4% - 2.8%|
Payment with EUR, GBP, CZK
Our card payment gateway provides reliable service with great APIs and does a lot of work underneath to make payments happen. They of course pay to Surfcity company account, not directly to space owners. This limitation has few reasons, mostly related to the regulatory framework they need to follow. There is no way to initiate the payment on behalf of someone else and subsequently let Stripe to send it to arbitrary account.
Second issue is related to the fact that card payment rails are centralized systems that need to scale to very high throughputs in realtime (Only for VISA in dozens thousands tx/s). In such situation you always end up with small payments being discouraged in some way, e.g. through fixed fees and limits, because otherwise their sheer number would likely make the system unscalable or unprofitable.
We thus add card processing fixed fee to every booking and round up booking amount to minimal payment limit. The variable fee is covered by Surfcity service margin that we add to the rental price set by the space owner. We will explain how Surfcity service margin is calculated later in this article.
Bitcoin payments to the rescue?
Bitcoin as the currency labelled by its inventor to 'peer-to-peer electronic cash system' has been compared to VISA from the very beginning. This comparison is quite misleading. Bitcoin is not an equivalent of a payment rail such as VISA. Nevertheless, the idea that Bitcoin in its core protocol should provide comparable and cheaper payments to VISA, lead to major conflicts within its stakeholders an subsequent forks of Bitcoin.
It was stupid idea from the beginning, because network whose consensus rules needs to be verified on tens of thousands nodes can never achieve the same throughput as centralized system whose consensus rules are checked in single process. If it had happened, Bitcoin network would have slowly become the very same centralized system, loosing its fundamental promises, such as create money based on fixed supply schedule with no central issuer. As time goes on, market has solved this question, it is enough to check the price or market cap history of Bitcoin against its forks.
Making Bitcoin payment for renting a parking space, validate and save it in thousands of copies across the whole world seems really awkward, but let's look at it anyway: parking space owner could provide its Bitcoin address and parking user would pay from his wallet. Surfcity could monitor that the payment has been made against its own Bitcoin node where the new transaction would be broadcasted through Bitcoin's p2p network in few seconds. This concept has however two major problems:
- Bitcoin on-chain payments are often not economical for small amounts, depending on free fee market
- Bitcoin on-chain payment settles only after miners bundle it into a 'block' of confirmed transactions. While transaction has not at least few confirmations, it can be easily reverted (double-spent). Confirmation time depends on fee used and the state of the network, 10 minutes on average.
Both of those problems are an outcome of Bitcoin's fundamental design choices and show that core protocol simply serves different purposes then VISA: its primary goals are security, consensus rules stability and resistance to takeover by single party. Bitcoin is base layer of new money and those objectives are simply much more required then a promise of cheap payments.
Bitcoin Lightning (partially) to the rescue
Lightning is an instant payment network built on top of Bitcoin core protocol. Once having so called 'payment channels' set up, it allows transferring funds between two parties directly, instantly and without immediately posting the transactions to the blockchain. Thanks to this it theoretically scales almost without limitations, provides instant and in general very cheap transactions, while your Bitcoins remain still fully under your control.
Ideally, we would like to initiate payment that is, once booking ends, automatically paid to space owner lightning wallet. However there is a catch - as payments between Lightning nodes are truly peer-to-peer, without anybody else storing the copies of transactions, it is fundamental that both parties are online when making the payment. This is of course quite a big trouble in our typical retail scenario. At the same time, Surfcity has no good means to initiate payment on behalf of the user and check that it actually has been completed without being one of the parties in the transaction. There are some clever concepts in the making on how to accept Lightning payment while being offline and how to orchestrate such more complex transactions - but so far not production ready. They will of course require that both parties must transact using Lightning.
So what did we end up with? We integrated Lightning payments into Surfcity booking process. Thanks to the deep link standard supported by the Bitcoin lightning wallets user is fluently redirected into his wallet to make a payment. If payment succeeds (i.e. there is a path to route the payment), experience is simply great. Payment request is generated by Surfcity lightning node that runs 24x7 and Surfcity app checks the node whether the payment has been completed and proceeds to allow access to booked parking space information.
As a result - while far from 'decentralized Uber' mantra, we are able to provide smooth and private payment experience, relying mostly on infrastructure under our and our user's control - without the need for third party processors, unwanted transaction data sharing or retyping of obsolete and insecure card number.
Payment with Bitcoin Lightning wallet
Regarding fees - lightning payments might or might not include fees, depending on if there is a direct payment channel between payer and payee. Setup or closing of payment channels is standard Bitcoin on-chain transaction. Direct payment channels are truly point-to-point and payments are after initial setup virtually free until there is enough liquidity in direction of payment. However opening direct payment channels and making sure, that there is sufficient liquidity is not a job to be done by the user. Lightning wallet providers and payment routers that provide channel and liquidity management for fluent payments do that for a fee. Those fees are now minimal but it is yet to be seen where will be the equilibrium price needed to provide reliable payments.
Final question remains: Is there enough demand for payments for parking space (or any other service) using Bitcoin Lightning? Lightning payments adoption faces many headwinds. One of the major ones is: if Bitcoin's promise is to be money with far better properties to fiat currency why would one spend it on parking? Gresham's law says that if a rational individual faces such a situation, he/she decides to spend lower quality money first, and save the better for future. If someone gets income in fiat currency and buys Bitcoin as a store of value asset, he is unlikely to spend it on non-critical service - when there is fiat payment option available.
This is serious argument, nevertheless we think it won't be valid forever. In case Bitcoin and Lightning payment adoption grows over time, there will be more and more people that will see fit to hold some daily cash in their Lightning wallet - either for superior payment experience, micropayments, better privacy or just to stand out. As well when another Bitcoin bear market cycle comes, there will be many Bitcoin hodlers that will see spending some Bitcoin as a rational choice. So better be prepared.
Payouts to parking space owners
Let's see the other side of the service - what can we do to accommodate the needs of parking space owners regarding their payouts? Once again we decided to investigate and implement multiple payout choices based on classic payments rails and compare them to the possibilities of current Bitcoin ecosystem.
Bitcoin Lightning withdrawal
Rates for parking
Space owners can setup thir own rates for each space they offer. Rates are defined per hour and per day. Rate per day applies for all bookings longer then 24 hours. When registering new space, rates are set to reasonable defaults in payout currency set in your settings. Space owners can change their rates and payout currency anytime. Payouts are calculated based on those rates - Surfcity margin that is described further down is added to the rates published to users making a booking and covers all related transation fees.
Similar to payments, Surfcity supports the following currencies and payout methods:
|Payout method||Minimal payout||Payout freq|
To make a payout to another account, situation is much more simple than to make an online payment - we can just use SEPA payment supported by all European and UK banks. Price for such payments is usually bundled in the banking account fee, so we can process payouts efficiently on monthly (or on weekly) basis as per completed bookings. The payout process is as follows:
- Parking space owner registers his IBAN account number in the Surfcity app
- Account number is digitally signed on his device by his secret signing key, so we are sure about its authenticity
- We use this account number alongside with space owner name provided in parking space registration to send payout from our bank
SEPA payments usually take a day to be credited to account. However with ongoing instant payments' rollout across Europe this will not be an issue in near future.
Actually, our card payments processor collects payments on internal account and disburse them to Surfcity banking account on weekly basis itself. What can go wrong?
Indeed, from business continuity perspective, almost everything... let's pick up just few scenarios:
- There is no way to service users outside Single European Payments Area (SEPA). Any other cross-border payment is prohibitively expensive for our low-margin use case
- Card payment processor may stop disbursement of collected money for some reason or block us from using their card payment service
- Cross-border SEPA payment might be blocked by sending or receiving bank for some reason
Second and third risk might seem a little exaggerated for our low amount payments but if they'd materialize, they would have thrown us out of business and into secondary insolvency within days. In current rapidly changing and tougher regulatory environments, banks as well as payments processors are required to implement more and more strict behavioural and other checks on accounts and payments. Regulation is never exact specification and combination with some sort of AI-assisted decision-making can lead to account blocking even without any illegal intent from client side. Appeal would be perhaps successful, but would take months.
Another issue is that as a space owner you need to wait for Surfcity to send you the money we owe you. Within standard payments there is no way for space owner as a physical person to draw money collected by Surfcity at will anytime after completed booking (e.g. as registered utility companies can do so through SEPA direct debit). There is as well no standard and simple way to easily automate immediate payouts on Surfcity side - such solutions exist with some banks however usually involve costly integration. That's why majority of small companies remains with periodic and manual bulk transfers imported into internet banking.
Once again, considering our use case and amounts involved, this is not a huge issue. Nevertheless let's see if we can make payout scenario fly better for both Surfcity and space owners - using Bitcoin.
As an alternative to SEPA payouts in fiat currencies, Sufcity supports combination of two different ways how to get paid in Bitcoin. Parking space owners make an agreement with Surfcity on how they want to get paid for the bookings, independently of how the user paid for it. Let's look at payouts using standard Bitcoin payments first.
|Payout method||Minimal payout||Payout freq|
|BTC on-chain payment||BTC 0.001
Logical option for Bitcoin payouts, similar to payouts in fiat currencies are standard Bitcoin (on-chain) payments. They work in a similar 'push' way, - parking user registers and digitally signs his Bitcoin address and Surfcity sends collected payouts to this address on monthly (or weekly) basis. Small difference is, that Bitcoin address is not equivalent to a bank account number. For privacy reasons it should be unique for each payment, generated by user's wallet. That's why Surfcity allows registering new Bitcoin address for each payout.
Limitation of standard Bitcoin payouts are that related fees can not be known ahead of time. Fees are paid by Surfcity when making payouts and can not be set arbitrarily low to make sure that transactions will be accepted by some miner. That's why we've setup a minimal limit for Bitcoin payout. If monthly payout is not above the limit, we will send the combined payout next month. However as much as Bitcoin payouts are an easy and attractive way to get on-boarded to Bitcoin, those limitations are far from ideal. The limits and costs involved are much worse than for fiat alternative - and we knew we should do better.
Bitcoin Lightning withdrawals
How could we make sure that collected money for bookings were immediately available to space owners to withdraw. This would provide great experience for the space owners as well as help Surfcity to reduce its liabilities. Fortunately, such standard is once again provided as a part of Lightning payment extended specification, called LN-URL. We can generate a unique withdrawal link, that is than accepted by user's Bitcoin Lightning wallet. This wallet then asks Surfcity node to pay payout amount encoded in the withdrawal link.
|Payout method||Minimal payout||Payout frequency|
|BTC Lightning withdrawal||1 satoshi||anytime|
Bitcoin Lightning withdrawal
That way, parking space owner can anytime request a payout that is sent to his wallet in realtime. Lightning withdrawal as well addresses the fact, that his wallet needs to be online in order to receive payment - it is, because user accepts the payment from the wallet itself. If user has no Lightning wallet app installed on the same device as the Surfcity app, he still can scan withdrawal link from Surfcity app with the wallet on another device in the form of QR code.
We can as well efficiently address some of the issues involving liquidity required to make Lightning payments work. As we can assume most users will try to withdraw to mostly used lightning wallets, we can keep opened direct channels with enough liquidity to the nodes operated by those wallet providers to make sure payments will route directly. For payouts to other destinations, we keep small reserve for routing fees that can be subsequently withdrawn if the payment did not involve fees equal to reserved amount.
As a starting point we will manage direct channel to Breez routing node that routes payments to each user's wallet node so it stays non-custodial. We still need to keep in mind, that Lightning payments routing may fail for some reason. That's why Surfcity will always process not withdrawn amounts through standard on-chain Bitcoin payouts as a fallback.
Future improvement could include to make such a payout immediately in 'push' style, cutting Surfcity service margin along the way. As we said in payments section, such solution will be likely feasible on Lightning in the future, even without the payee being always online, but it is not yet the case.
With all that in mind, we consider Surcifty payouts model as an attractive on-boarding into Bitcoin Lightning payments / payouts. Users do not need to have any prior Bitcoin knowledge, nor open crypto exchange trading accounts. They as well do not need to risk any of their existing savings if they are not comfortable investing in Bitcoin. Nevertheless they still can get their first Bitcoin with very little risk and hassle: put their parking space at disposal for other people and get paid for bookings in Bitcoin. Users renting their parking space can still pay in traditional currency if they prefer - what might be rational choice according to Gresham's law, at least for now.
So, if you want to quickly try it out - and get some Bitcoin to your Lightning wallet on the way, here is how to do it in minutes: Download (iOS or Android) Surfcity app, register your parking space, make yourself a booking you pay e.g. with Apple pay and withdraw into your Lightning wallet. Neat, isn't it?
How do we cover costs of the service?
We described above some of the services provided by Surfcity to parking users and space owners. In order to provide such service, the following needs to be in place and working:
- Mobile application itself and related IT infrastructure
- Card payments outsourced to our card gateway processor
- Bitcoin Lightning payments processing
- Processing payouts, pay related fees and provide necessary liquidity
- Clearing for payments and payouts in different currencies
- Managing exchange rates risks
- Fraud prevention
- User support
When we checked similar existing traditional services, we found that they operate on 30% margin added on top of prices set by space owners. As we said in the beginning, we did not plan our service with commercial targets in mind. We consider it as our part of the job to introduce people or other businesses to potential brought to us by new financial ecosystem.
That's why we set up the margins for the service as follows:
|Transaction type||Margin added to booking|
|Booking and payout in same currency||5%|
|Booking in fiat currency and payout in BTC||5%|
|Booking and payout in different currencies (except BTC)||10%|
We hope this will in the long term cover the costs of the service.
In the beginning we discussed aspiration of some businesses to become 'fully digital' and 'decentralized'. We outlined fundamental issue with this approach in case the service depends on external information / realities and how to ensure that this information can be trusted without creating single points of failure. In our case the obvious challenges would be:
- How to ensure, that offered parking spaces actually exist and offered by actual space owners?
- How to protect against some forms of spam?
- How to ensure that parking space owners and parking spaces follow some terms and conditions?
Our service depends on quite a lot of external aspects - parking spaces are quite physical, after all so our service simply can not just levitate in cyberspace. Surfcity is therefore architected as a centralized service backed by company incorporated in European union (Slovakia).
Parking space owner then enters into two distinct contractual relationships. One is a lease contract with parking user that defines rights and obligations of both parties when renting owner's parking space. Another one is with Surfcity operator and it authorizes Surfcity to provide set of services on behalf of space owner. As a part of the service, owner assigns all claims for parking fees to Surfcity to be collected from parking users in Surfcity own name in any currency Surfcity might agree with the parking user. Surfcity is then liable to pay owner the respective fee in the currency owner have chosen as payout currency in agreed time frame (or immediate withdrawal through Lightning to owner's own wallet). That way, Surfcity does not provide currency exchange service to any of involved parties, nor any kind of custodial wallet services.
Surfcity badges - ownership verification by community
In order to keep quality of the service, Surfcity defines standard Terms and conditions that specify contractual relationship and criteria for parking space to be listed. What remains is how to make sure that spam or fraudulent offers is minimized. What looks as direct attack vector is that fraudulent user would offer parking spaces owned by someone else under his name. How can such a fraud be minimized without costly paper work?
We think the fraud prevention measures need to be in line with value at risk. As far as we do not intermediate any high value transactions we decided to implement a community driven ownership verification combined with reasonable limits.
Getting Surfcity badge from another space owner
Listed spaces can obtain a badge - that is digitally signed verification from other space owners from within the same community. Verification is done in person, by scanning in-app generated QR code by another space owner. This creates trust based on verifiable digital signatures. Obtained badges are then visible when making a booking and increase confidence of parking users, that the offer is indeed trustful. We believe that within communities of neighbours this collective proof of ownership model could be highly consistent with reality. Our assumption is that parking space offers will be considered as community service, where neighbours do not treat each other as tough competitors.
We let to offer first parking space without a badge, however if user would like to add second one, Surfcity requires obtaining badge for already listed space. Only as a second line of defence we rely on more traditional verifications as outlined in Terms and on simple reputation system using 'likes' by parking users.
Is this perfect and bullet proof system? Although space owners provide minimal personal data (full name and email) to be able to close legal agreement with Surfcity, those could be fake and having identities bound only to keys on devices means one could create fake identities using multiple devices. For sure, it is not bulletproof, however it efficiently prevents to spam the system. Spam or fraud at scale would require significant manual effort. Any larger scale attempts can still be quite easily identified by basic behavioural data analysis.
We therefore believe that community-driven ownership verification using digital signatures might be an inspiration for another similar (low value at risk) situations.
As a last part of our journey we will summarize our choices regarding how do we protect users data. We believe current state of internet / mobile app services stands on business models built around compromising user privacy. Surfcity aims to do better.
We make sure we collect absolute minimum of information necessary to make Surfcity work. There are no user logins, passwords nor social networks accounts necessary to use the app. Identity is represented by secret key generated and stored solely on user device and only public keys are stored on our servers.
From parking user perspective, information about his or her car to be parked is encrypted using elliptic curve Diffie-Hellman key exchange so that only space owner can decrypt this information. Nobody else gets access to it, not even us. In case parking user pays using credit or debit card, all card and personal information are only made available to our card processor and never stored on our servers. In case of Lightning payments, privacy is guaranteed by Lightning fundamental design.
We provide backup service so that users can recover their data in case they switch to another device. Backup of user keys are encrypted on user device with a chosen password. They are then stored on our servers and can be restored on new device via recovery function.
We do believe that Surfcity will become one of many ways to onboard people to exciting new means to transact and store their wealth. And, that some of our research and decisions will serve as an inspiration for other businesses to adopt Bitcoin and reasonable user privacy into their business models.
In the next part we will look at how to implement Bitcoin Lightning payments as a part of your IT architecture, what is the maturity of available software components and what can be done to achieve performing, stable and secure operations.