Status: Closed
Project Type: Cooperative/Contest - Multiple workers can submit work, and the bounty is shared
Time Commitment: Days
Experience Level: Beginner/Intermediate
Size: USD 7’500 in ICP (at time of distribution)
Deadline: July 16th 11:59pm UTC
Description
Digital payments in physical environments, e.g. shops, street markets etc., are getting increasingly common. With this bounty, we want to showcase the power of the Internet Computer to quickly set up a Point-of-Sale payment solution accepting ckBTC by just opening a website, and putting up a static QR code.
The solution should work like this:
Usage without any account: The merchant enters an existing ckBTC address, and the (open) application monitors the address and notifies the merchant about a payment. The application also allows viewing the transaction history of the ckBTC address.
Usage with an account: The merchant can create an account and can either enter an existing ckBTC address or create a new address tied to this account. The merchant can also set up additional notification channels to get notified about a payment by a text message. In this scenario, a backend canister needs to monitor the ckBTC account and trigger a notification, e.g. via HTTPS outcalls to courier/Twilio [1].
Requirements
The application allows setting a ckBTC account to monitor. Whenever the account receives a payment it will play a sound and show a notification.
The application allows showing a QR code that encodes the ckBTC account, such that a payer can scan the QR code, e.g. with the NNS wallet dapp.
The application allows setting up an account using Internet Identity or a related authentication method in order to set up a new ckBTC wallet.
In authenticated mode, the application allows transferring ckBTC to another account.
In authenticated mode, the application allows setting up payment notifications by SMS/text message.
The application allows to review past transactions of the associated accounts (You can use the dashboard API to fetch the necessary data.
Nice to have: The application allows to print out the QR code encoding the ckBTC address.
Acceptance Criteria
The dapp must be optimized for mobile/tablets.
The code must be open source with an MIT license.
Evaluation Criteria
Design/UX
Functionality
Code quality
How to participate?
Post your submission in this thread.
Please be aware that Terms and Conditions of the DFINITY Developer Grants Program apply.
Sounds like a fun thing to build, I might be able to take it on. Last time I built for Dfinity I built The Wall – a crossover Ethereum/Internet Computer demo app where users use Metamask to login to IC. Then, they can post messages to the wall!
Requirements look straight forward with the exception of the background notifications. It would be possible to use a timer and monitor/poll all ckBTC ledger transfers on a regular basis. That would work fine in a scenario with relative low volume of transactions. But when ckBTC picks up speed that becomes increasingly unsustainable. There is also the issue with paying for cycles for the monitoring. We don’t want to introduce some kind of centralised actor in all this just to pay for cycles.
A sustainable setup would be to build a payment gateway canister that:
Accepts transfer
Sends notification
Forwards transfer to final destination.
But from what I have read about ckBTC so far that is not technically doable, right?
using timers is not a good idea.
according to your idea, receiver will have to wait for a certain period to get notification of payments, till that time you gonna make payer wait.
It’s doable.
There are two types of notifications in the requirements:
If you have the website open you should get a notification when you receive a payment. So, not really background. This should be handled by polling from the frontend from my perspective. I’d just poll the balance in this scenario
Background notifications for signed-up users. I gave text message notifications as an example, because we think this could be used globally, but push notifications could also be added.
We deliberately don’t use the invoice/subaccount design here as used in the invoice canister. There you’d watch unique subaccounts per invoice. However, this requires a QR code per invoice, and we want to have a static QR code in this scenario. Remember, this is an offline scenario where you don’t have multiple people paying at the same time.
This is a cooperative/contest type bounty. We won’t select applicants upfront. Everyone can participate and submit a solution. We’ll then evaluate the submissions according to the mentioned criteria and distribute the bounty accordingly.
Got it. The “background notification” is tricky still if I am not missing something.
I am assuming this:
Buyer uses any wallet capable of doing a ckBTC transfer. This means we have no control over that part of the flow.
Buyer interacts with a QR code representing the seller account. That means we cannot trigger anything from the frontend at transaction time. The buyer don’t interact with a frontend at all, they just … transfer.
That leaves us with reacting at the backend. Which means reacting to events or if there are no events, use timers/polling.
Would it be acceptable to let the seller QR code not represent the seller address but instead a url to the seller frontend page? Then the notification can be solved easily:
Buyer wants to pay for something at the farmers market
Buyer scans merchant QR code, a web page opens
Merchant logo etc
“Enter amount to transfer” (calculator layout)
Buyer enters amount to transfer
Webpage initiates transfer, buyer signs with wallet
Spinner, “transfer in progress”
Transfer complete, webpage interacts with notification canister that sends text
Ideally, transfer and notification would be packaged together at step 4, the buyer also paying for the little amount of cycles needed for the notification.
Got it. I agree, and think the idea of a payment gateway would be a good approach if you’d want to commercialize and make it scalable. You can apply for a grant afterwards
For a demonstrator, I think the timer approach would be sufficient as well, and we could let the merchant switch it off/on or even make the interval customizable as an advanced setting.
I have been working on a project, the payment system, which could be a potential fit for the requirements mentioned in this bounty. The payment is built on top of the B3Wallet, a decentralized multi-chain, and multi-owner wallet.
Here are some key features:
Multi-chain transactions: The system can handle transactions across a variety of blockchains, including but not limited to Bitcoin, Ethereum, and the Internet Computer.
Support for multiple owners: It is designed to accommodate transactions from single owners, multiple owners, and even transactions requiring multi-signature approvals.
Integration with B3 Wallet: The payment system seamlessly integrates with the B3Wallet without needing login credentials or any other form of registration, providing users with a holistic solution for their crypto transaction needs.
You can take a look at the basic example here: Payment Github
I also have a demo video that walks through the process: Demo
Thank you for your feedback. This is indeed a demo created within the constraints of the hackathon timeframe, primarily to demonstrate functionality. I’m aware of the current UX complexities and am already in the process of refining it. The upcoming improvements include a more user-friendly UI and simpler interactions, such as QR code scanning among others.
