Closed: BNT-6 - Point-of-Sale Payment Dapp


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


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:

  1. 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.
  2. 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].


  • 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.


[1] See the IC-Mailer project.


Great to see new bounties coming up!

@domwoe seems like the last link is broken.


Thanks, @Seb. Updated the link.

1 Like

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!


cool task!
I have some questions:
A single canister should handle all these tasks for all users or a separate canister for each user?

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:

  1. Accepts transfer
  2. Sends notification
  3. 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.

Since I’ve already built most of this between the invoice canister and the icrc1 payment flow, can I get priority?

I’d also make it compatible with any ICRC1, just use ckbtc as the default.

Post your work here. Let the community check out the design. Also open source the code.

That’s up to you. I’d keep it simple, but I can see the merit of a canister per merchant architecture.

There are two types of notifications in the requirements:

  1. 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

  2. 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.

1 Like

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:

  1. Buyer wants to pay for something at the farmers market
  2. Buyer scans merchant QR code, a web page opens
  • Merchant logo etc
  • “Enter amount to transfer” (calculator layout)
  1. Buyer enters amount to transfer
  2. Webpage initiates transfer, buyer signs with wallet
  3. Spinner, “transfer in progress”
  4. 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.

1 Like

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 :slight_smile:

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.

This is also a reasonable approach but depends on a wallet standard that we don’t have in place yet (See: Assigned: RFP-7: Wallet Standard Reference Implementation). Hence, I wouldn’t want to go that route here.

1 Like


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



The UX looks way too complex.

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.


@domwoe Is the API available for testnet as well?

It seems that the ckTESTBTC ledger is currently not tracked in the dashboard :frowning:
Canister IDs of the ckTESTBTC system can be found [here].(ic/rs/bitcoin/ckbtc/testnet/canister_ids.json at master · dfinity/ic · GitHub).


I’ve talked to the dashboard team and we might be able to provide the API for ckTESTBTC by next week.